Почему SPF-запись не проходит проверку — и как это исправить

Что на самом деле проверяет SPF

SPF — Sender Policy Framework — это TXT-запись на вашем домене, перечисляющая серверы, которым разрешено отправлять почту от вашего имени. Принимающий сервер читает эту запись, сравнивает её с IP-адресом, который только что подключился, и решает, авторизовано ли соединение.

Две детали о том, что именно сравнивается, объясняют большую часть путаницы с SPF:

• SPF проверяет адрес из конверта, а не адрес From:, который видит получатель. Адрес конверта (MAIL FROM в SMTP-диалоге, он же return-path) в почтовом клиенте не виден. Письмо может пройти SPF, показывая при этом совершенно другой, поддельный From:, — именно поэтому SPF сам по себе не останавливает подмену.
• SPF проверяет подключающийся IP-адрес и больше ничего. Он не смотрит ни на письмо, ни на заголовки, ни на содержимое. Это один вопрос: было ли этому IP разрешено подключаться от вашего имени?

Поэтому сбой SPF почти никогда не означает, что запись составлена неправильно. Обычно он означает, что почта ушла откуда-то, чего в записи нет, либо что запись не удалось вычислить полностью. Это разные проблемы с разными решениями, и дальше в руководстве они разделены.

Как прочитать свою SPF-запись

SPF-запись — это одна строка TXT, и она вполне читаема, когда знаешь её четыре части.

Механизмы: кому разрешено

Каждый элемент добавляет разрешённых отправителей. ip4: и ip6: перечисляют адреса или диапазоны напрямую. a разрешает то, на что указывает A-запись домена. mx разрешает ваши собственные почтовые серверы. include: — самый важный на практике: он втягивает SPF-запись другого домена целиком, и именно так вы разрешаете Google, Microsoft или массового рассыльщика, не зная их адресов.

include: — это делегирование, а не копия. Другая сторона может изменить свой список в любой момент, и ваша запись последует за ним — в этом и смысл, и причина, по которой ваша запись может сломаться без вашего участия.

Квалификаторы: что происходит при совпадении

У каждого механизма может быть префикс. + — это pass и значение по умолчанию, так что одинокое mx означает +mx. - — жёсткий отказ: отклонить. ~ — мягкий отказ: принять, но помеченным. ? — нейтрально: мнения нет, что фактически равно отсутствию политики.

Завершающий all

Последний элемент почти всегда механизм all, и он решает судьбу всех отправителей, которых запись не перечислила. -all — отклонять всё остальное. ~all — принимать, но помечать. +all разрешает весь интернет и всегда является ошибкой.

Начинайте с ~all, пока ещё выясняете, кто законно отправляет за вас, и затягивайте до -all, когда отчёты DMARC станут чистыми. Пойти сразу на -all без этого подтверждения — верный способ, чтобы забытая система выставления счетов или служба поддержки перестала доходить до кого бы то ни было.

Ровно одна запись, без исключений

Домен может публиковать одну SPF-запись. Две TXT-записи, начинающиеся с v=spf1, — это permerror, а permerror означает, что проверку вообще невозможно вычислить: у строгого получателя это хуже простого отказа. Так бывает постоянно: мастер настройки нового провайдера добавляет свою запись вместо того, чтобы отредактировать вашу. Объединить их — значит получить одну запись с обоими наборами механизмов, а не две записи.

Лимит десяти запросов — тихий убийца

Это самая частая причина SPF-записи, которая выглядит идеально и всё равно не проходит.

Спецификация ограничивает вычисление SPF десятью DNS-запросами. Каждый include:, a, mx, ptr и exists: стоит одного — и запросы внутри каждой включённой записи тоже считаются. Один include:, который сам содержит три include, стоит четырёх из ваших десяти. Превышение даёт permerror: не отказ, а невычислимую запись, которую многие получатели считают неаутентифицированной.

Неприятность в том, что это невидимо и растёт само. Ваша запись проходила, когда вы её написали. Через месяцы один из провайдеров добавил include: в свою запись, ваша сумма перешла за десять, и почту начали помечать, хотя с вашей стороны ничего не менялось. ip4: и ip6: не стоят ни одного запроса — это ваш главный рычаг.

Посчитайте свои, прежде чем считать запись исправной. Запросите TXT-запись домена, затем запись каждого включённого домена и продолжайте, пока не останется, что раскрывать. Инструмент DNS-запросов делает это быстро: посмотрите TXT-запись, затем проходите по каждому include: по очереди.

Почему почта не проходит, хотя запись выглядит верной

Если запись синтаксически корректна и укладывается в лимит запросов, пройдите по списку по порядку.

• Что-то отправляет из неперечисленного сервиса. Обычные подозреваемые — CRM, система счетов или тикетов, маркетинговая платформа, система мониторинга или сервер приложения, отправляющий через локальный почтовый агент. Каждому нужен include: или его диапазон IP.
• Адрес конверта принадлежит другому домену. Платформа, отправляющая «от вашего имени», часто использует свой return-path, так что SPF проверяется против её домена и проходит, а выравнивание DMARC у вас по-прежнему не проходит. Письмо может быть одновременно аутентифицированным и невыровненным.
• Поддомен без собственной записи. SPF не наследуется. Почта с mail.example.com проверяется против этого самого имени, и без TXT-записи результат — none, а не ваша политика на апексе. Публикуйте запись для каждого отправляющего поддомена и пустую v=spf1 -all на тех, которые отправлять не должны.
• Запись изменилась, а кэши не догнали. У вашей TXT-записи есть TTL, как у любой другой, так что исправление не действует везде в момент сохранения — как работают TTL и распространение разбирает сроки.
• Устаревший include:. Провайдер, которым вы перестали пользоваться и чей домен больше не разрешается, способен дать permerror, и никому не выгодно вам об этом сообщать.

Пересылка ломает SPF по самой конструкции

Это не ваша вина и не исправляется в вашей записи, так что лучше понять заранее, чем потратить на это день.

Когда получатель пересылает ваше письмо — университетский алиас, правило .forward, рассылка — пересылающий сервер соединяется с конечным адресатом со своего IP, сохраняя ваш домен в конверте. Получатель проверяет вашу SPF-запись против IP, о котором вы никогда не слышали, и проверка не проходит. Справедливо: этот IP вами действительно не авторизован.

Есть два способа смягчить, и ни один не является изменением SPF. DKIM подписывает письмо криптографически и переживает пересылку, так что пересланное письмо, не прошедшее SPF, может пройти DKIM и, значит, DMARC — это главная причина использовать оба. SRS (Sender Rewriting Scheme) — работа пересылающей стороны: она переписывает адрес конверта на свой домен, чтобы SPF проверялся против неё. Заставить сделать это чужой пересылающий сервер вы не можете.

Практический вывод: никогда не диагностируйте SPF по пересланной копии письма и не переходите на -all, считая, что каждый видимый сбой — атака.

Пройденный SPF — это не пройденный DMARC

Результат pass в заголовках при том, что DMARC всё равно не проходит, сбивает с толку почти всех, и причина называется выравниванием.

SPF аутентифицирует адрес конверта. DMARC дополнительно требует, чтобы аутентифицированный домен совпадал с видимым доменом From:. Платформа, отправляющая со своим return-path, может дать вам безупречный SPF pass на своём домене, что ничего не даёт вашему домену From:: проверка SPF прошла, проверка выравнивания — нет, и DMARC не проходит на этом основании.

Так что SPF никогда и не был защитой от подмены: атакующий может опубликовать совершенно корректный SPF для собственного домена и всё равно поставить ваше имя в поле From:. DMARC — это то, что связывает аутентификацию с адресом, который получатель действительно видит, и это же то, что присылает вам отчёты о том, кто отправляет от вашего имени. Руководство по SPF, DKIM и DMARC объясняет, как три части работают вместе и как вводить политику.

Как починить запись, которая не проходит

В этом порядке, потому что каждый шаг убирает причины, которые следующие иначе скрыли бы.

• Убедитесь, что запись ровно одна. Запросите TXT-записи и посчитайте, сколько начинается с v=spf1. Больше одной — permerror: сначала объедините механизмы в одну запись, а уже потом исследуйте что-либо ещё.
• Посчитайте запросы, включая вложенные. Если вы на десяти или около, замените самый тяжёлый include: диапазонами ip4:, в которые он разрешается, и уберите include провайдеров, которыми больше не пользуетесь. Снятие одного заброшенного include часто возвращает всё под лимит.
• Соберите список тех, кто действительно отправляет за вас. Сводные отчёты DMARC здесь — единственный надёжный источник: они перечисляют каждый IP, отправляющий от имени вашего домена, включая системы, о которых никто не помнит. Догадки дают неполную запись.
• Полностью откажитесь от ptr. Он устарел, медленный, ненадёжный, и часть получателей игнорирует записи, которые его используют.
• Держитесь ~all, пока отчёты не станут чистыми, и только потом переходите на -all. Жёсткий отказ при неполной записи отбивает вашу же почту.
• Понизьте TTL перед правкой и проверяйте извне. Смотрите живую TXT-запись инструментом DNS-запросов, а не панелью своего DNS, и проверьте снова после истечения старого TTL.

Частые ошибки

• Две SPF-записи, потому что мастер провайдера добавил свою. Permerror, и это хуже отказа.
• Превысить десять запросов и никогда об этом не узнать, потому что сбой — это permerror в чужих логах.
• Прыгнуть на -all, не зная всех законных отправителей. Забытая система обычно та, что выставляет счета вашим клиентам.
• Ждать, что поддомены унаследуют политику. Не унаследуют. Публикуйте запись для каждого отправляющего поддомена.
• Использовать ptr или +all, который разрешает всем.
• Диагностировать по пересланному письму. Пересылка законно не проходит SPF и ничего не говорит о вашей записи.
• Считать, что SPF pass означает прохождение DMARC. Без выравнивания с видимым доменом From: не означает.
• Отредактировать запись и сразу тестировать. Старая TXT-запись ещё лежит в кэше весь свой TTL.

Коротко

SPF сравнивает подключающийся IP с одной TXT-записью и проверяет невидимый адрес конверта, а не адрес From:, который читает получатель. Публикуйте ровно одну запись, держите общее число DNS-запросов — вместе с вложенными внутрь каждого include: — на десяти или меньше, перечислите каждый сервис, законно отправляющий за вас, дайте каждому отправляющему поддомену свою запись и оставайтесь на ~all, пока отчёты DMARC не докажут, что список полон. Пересланная почта не пройдёт SPF, что бы вы ни делали, — именно поэтому рядом существуют DKIM и DMARC. Прочитайте живую TXT-запись любого домена, раскройте каждый include: и посмотрите остаток TTL бесплатным инструментом DNS-поиска.

Связанные инструменты и руководства:

• Поиск DNS — Запрашивайте записи A, AAAA, MX, TXT, NS и другие со значениями и TTL, а также обратный DNS.
• Как читать отчёт DMARC и не утонуть в XML — Что содержит сводный отчёт DMARC

Частые вопросы