термин · проверка SPF-записи

Как проверить SPF-запись для писем приложения?

Проверяйте SPF для домена, используемого в SMTP-адресе MAIL FROM, а не автоматически для видимого домена From. Запросите TXT, выберите единственную запись, начинающуюся с v=spf1, проверьте каждый термин, вычислите механизмы слева направо относительно IP-адреса отправки и проследите include или redirect, считая термины DNS-запросов. Затем подтвердите результат SPF у получателя и выравнивается ли аутентифицированный домен для DMARC. Успешный SPF разрешает клиенту отправки использовать SMTP-идентификатор; он не доказывает DKIM, DMARC, доставку или попадание во «Входящие».

Начните с идентификатора, который на самом деле проверяет SPF

Для проверки SPF нужны три входных параметра: IP-адрес SMTP-клиента, домен, политика авторизации которого вычисляется, и идентификатор отправителя. Для обычных писем приложения этот домен берётся из адреса SMTP MAIL FROM, который также называют отправителем конверта или обратным путём (return path). Он может отличаться от адреса, который люди видят в заголовке From. Если MAIL FROM пуст — как обычно бывает в уведомлениях о статусе доставки, — SPF использует для проверки MAIL FROM идентификатор HELO. Прежде чем смотреть DNS, зафиксируйте реальный IP-адрес подключения и идентификатор конверта из полученного тестового письма или настроек провайдера отправки. Проверка example.test только потому, что он указан в From, ничего не доказывает, если приложение на самом деле отправляет письма с адресом MAIL FROM в домене bounce.provider.test или bounces.example.test.

Запросите TXT точно для домена MAIL FROM

Запросите DNS TXT точно для домена, выбранного на первом шаге. RFC 7208 требует публиковать политики SPF версии 1 как TXT-записи на том имени, к которому они относятся. Игнорируйте посторонние TXT-значения и выберите записи, раздел версии которых в точности равен v=spf1. Если подходящей записи нет, результат SPF — none. Если подходящих SPF-записей больше одной, результат — permerror; публикация отдельных записей для разных поставщиков — недопустимый способ их объединить. DNS-инструменты могут показывать одну TXT-запись разбитой на несколько строк в кавычках, но перед разбором SPF эти строки склеиваются без добавления пробелов. Сохраните полный ответ, резолвер, время запроса и TTL, чтобы повторить проверку после изменения.

Проверьте синтаксис и вычисляйте элементы слева направо

SPF-запись — это упорядоченная политика, а не неупорядоченный список провайдеров. После v=spf1 механизмы вычисляются слева направо, пока один из них не совпадёт. Результат определяет квалификатор в начале: + означает pass и используется по умолчанию, - означает fail, ~ — softfail, а ? — neutral. Механизмы ip4 и ip6 сравнивают адрес клиента с адресом или сетью. Механизмы a и mx выполняют DNS-запросы, а include вычисляет SPF-политику другого домена и совпадает только по правилам include. exists выполняет проверку на основе DNS. all совпадает всегда и обычно завершает запись. Синтаксическая ошибка в любом месте приводит к permerror ещё до обычного вычисления. Полезный инструмент проверки должен показывать, какой механизм совпал, его квалификатор и каждый раскрытый домен, а не только цветной значок.

Отслеживайте include и redirect, не считая их синонимами

Проходите по каждому include и redirect в одном и том же контексте вычисления. Include — это механизм: он проверяет, возвращает ли включённая политика pass для текущего клиента и отправителя, и если совпадения нет, вычисление продолжается в исходной записи. Redirect — это модификатор, который учитывается после того, как ни один механизм текущей записи не совпал; он передаёт вычисление другой политике, сохраняя IP-адрес клиента и отправителя. Redirect игнорируется, если в записи где-либо есть all. Эти различия важны при миграциях. Замена include:vendor.test на redirect=vendor.test может заменить всю резервную политику владельца домена, а не просто добавить поставщика. Обнаруживайте циклы, отсутствующие и некорректные цели, вложенные постоянные и временные ошибки и сохраняйте в результате цепочку зависимостей, чтобы изменение политики на стороне провайдера было заметно.

Считайте полный бюджет DNS-запросов

Считайте элементы, вызывающие DNS-запросы, по всему рекурсивному вычислению, а не только в записи верхнего уровня. RFC 7208 ограничивает число элементов include, a, mx, ptr, exists и redirect десятью за одно вычисление SPF; превышение лимита обязано давать permerror. Механизмы all, ip4 и ip6 этот бюджет не расходуют. Для обработки MX и PTR действуют дополнительные лимиты на запросы адресов. RFC также рекомендует ограничивать «пустые» запросы (void lookups) — то есть успешные пустые ответы или ошибки имени — двумя и возвращать permerror при превышении. Механизм ptr использовать не рекомендуется, потому что он медленный и ненадёжный. Запись может выглядеть короткой, но include провайдеров раскрываются в столько вложенных элементов, что лимит будет превышен, поэтому показывайте итоговое число, каждый элемент, который в него вносит вклад, пустые запросы и точную ветку, выбранную для проверяемого IP-адреса.

Интерпретируйте результат SPF, не преувеличивая его значение

Используйте стандартный набор результатов. Pass означает, что проверяемый клиент авторизован использовать проверенный SMTP-идентификатор. Fail означает, что найдено совпадение с отрицательной авторизацией. Softfail — слабое отрицательное утверждение, а neutral означает, что домен ничего не утверждает об этом клиенте. None означает, что подходящей SPF-записи нет. Temperror отражает временную проблему вычисления, обычно связанную с DNS; permerror — политику, которую невозможно корректно вычислить. Если ни один механизм не совпал и redirect не применяется, результат — neutral, что эквивалентно неявному ?all. Сообщайте результат вместе с идентификатором, IP-адресом клиента, совпавшим элементом, трассировкой DNS и временем. Не приравнивайте pass к безопасному письму, желанной почте, приёму провайдером, доставке в почтовый ящик или попаданию во «Входящие» — SPF эти результаты не определяет.

Проверяйте реальное письмо, а не только опубликованную запись

Статическая проверка записи отвечает на вопрос, можно ли найти и разобрать политику. Она не доказывает, что приложение использовало ожидаемый домен MAIL FROM или исходящий IP-адрес. Отправьте контрольное письмо по каждому реальному пути продакшена на аккаунт получателя, который вы администрируете, и изучите заголовки полученного письма. Сравните IP-адрес подключения, отправителя конверта и запись Authentication-Results у получателя с результатом вычисления по DNS. Повторите для каждого провайдера, региона, выделенного или общего пула, резервного пути и класса писем, который может изменить обратный путь. Храните заголовки в хранилище с ограниченным доступом: адреса и детали маршрутизации могут быть конфиденциальными. Если панель провайдера и полученное письмо расходятся, письмо — более сильное свидетельство того, какой путь реально сработал, но результат одного получателя всё равно не стоит обобщать до универсального поведения доставки.

Проверяйте DMARC-выравнивание отдельным шагом

SPF может давать pass для домена обратного пути, принадлежащего провайдеру, и при этом DMARC не сможет использовать этот результат. Действующие правила DMARC сравнивают домен RFC5321.MailFrom, успешно аутентифицированный через SPF, с доменом автора в видимом поле RFC5322.From. Строгое (strict) выравнивание требует совпадения DNS-домена. Мягкое (relaxed) выравнивание допускает домены, которые по правилам обнаружения DMARC сводятся к одному организационному домену. Например, bounces.example.test и example.test могут быть выровнены в мягком режиме, а bounce.provider.test и example.test — нет. Результат DMARC может опираться и на выровненную проверенную подпись DKIM, поэтому невыровненный результат SPF сам по себе не означает, что DMARC не пройден. Сообщайте об аутентификации и выравнивании отдельно и используйте актуальную процедуру обнаружения домена, а не жёстко заданное сравнение двух последних меток.

Проверяйте настройку MAIL FROM у конкретного провайдера

От настройки провайдера зависит, какой SPF-идентификатор фактически попадёт в SMTP-сессию. Например, Amazon SES документирует собственный домен MAIL FROM, которому нужны своя MX-запись и TXT-запись SPF. Если MX собственного домена настроена неправильно, SES может откатиться на домен MAIL FROM amazonses.com, зависящий от региона, или отклонить отправку — в зависимости от заданного поведения. Такой откат может изменить DMARC-выравнивание, даже если видимый адрес From не изменился. Для любого провайдера фиксируйте настроенный домен обратного пути, требуемые DNS-значения, поведение при откате, регионы отправки и владельцев. После изменения DNS или провайдера дождитесь истечения соответствующих закешированных ответов, а затем повторите вычисление по DNS и контрольные отправки. Не копируйте include поставщика в видимый домен From, если это не реальный идентификатор и полный перечень отправителей домена этого не подтверждает.

Проводите воспроизводимый аудит SPF при изменениях

Ведите по одной строке на каждый путь отправки: владелец, приложение, класс писем, видимый домен From, домен MAIL FROM, домен HELO, ожидаемые диапазоны адресов источника, зависимость от провайдера и время последнего контрольного теста. Сохраняйте каждую проверку SPF с выбранной записью, рекурсивной трассировкой, числом DNS-запросов, совпавшим механизмом, результатом, решением о выравнивании и неконфиденциальным идентификатором теста. Во время миграции держите старые и новые легитимные источники авторизованными только на необходимое переходное окно, проверьте новый путь, а затем осознанно удалите устаревшую авторизацию. Отслеживайте постоянные и временные ошибки аутентификации, а не реагируйте только на отклонения. Повторяйте аудит после смены провайдера, переноса пула IP-адресов, изменения домена, правок DNS или появления новых приложений. Такой процесс выявляет и слишком узкие политики, блокирующие легитимные пути, и слишком широкие, сохраняющие неиспользуемую авторизацию.

Проверяйте SendHQ по тем же стандартам доказательности

SendHQ документирует, что для прямой отправки нужен адрес на подтверждённом домене рабочего пространства. Это подтверждает адрес отправителя, но не заменяет проверку SPF. Для контролируемого письма SendHQ всё равно нужны описанные выше трассировка DNS, проверка полученных заголовков, результат SPF и проверка выравнивания DMARC.

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

Какой домен использовать при проверке SPF?

Для обычного письма — домен из адреса SMTP MAIL FROM. Если обратный путь пуст, используйте идентификатор HELO, как указано в RFC 7208. Не считайте, что видимый домен From — это SPF-идентификатор.

Может ли домен опубликовать две SPF-записи для двух провайдеров?

Нет. Если при выборе DNS-записей найдено больше одной записи, начинающейся с раздела версии SPF, вычисление возвращает permerror. Объедините поддерживаемые механизмы в одну политику, соблюдая ограничения синтаксиса, размера и рекурсивных DNS-запросов.

Сколько DNS-запросов может использовать SPF-запись?

За одно вычисление — не более десяти элементов include, a, mx, ptr, exists и redirect, вызывающих DNS-запросы, с учётом рекурсивной обработки. Превышение лимита даёт permerror. Прямые механизмы ip4, ip6 и all этот бюджет не расходуют.

Если SPF дал pass, значит, DMARC тоже пройден?

Не обязательно. DMARC может использовать SPF, только если успешно проверенный идентификатор MAIL FROM выровнен с видимым доменом From в заданном строгом (strict) или мягком (relaxed) режиме. Альтернативным аутентифицированным идентификатором может служить выровненная проверенная подпись DKIM.

Почему онлайн-проверка SPF расходится с полученным письмом?

Возможно, инструмент проверял видимый домен From, использовал другой IP-адрес клиента, получил другую закешированную версию DNS или пропустил вложенную ошибку. Сравните его входные данные с идентификатором конверта реального письма, путём подключения и результатом аутентификации у получателя.

Что проверить после смены почтового провайдера?

Проверьте каждый старый и новый домен MAIL FROM, рекурсивные зависимости SPF, число DNS-запросов, фактический IP-адрес источника, поведение провайдера при откате, полученный результат SPF и DMARC-выравнивание. Протестируйте каждый класс писем, прежде чем удалять старую авторизацию или увеличивать трафик.