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

SPF-запись — это упорядоченное выражение политики

RFC 7208 определяет SPF-запись как строку DNS TXT, первый термин которой — v=spf1. Остальные термины, разделённые пробелами, — это механизмы, которые могут совпасть, и модификаторы, которые меняют обработку. Проверка идёт слева направо и останавливается на первом совпавшем механизме, поэтому порядок выражает политику. Типичная запись может авторизовать два фиксированных диапазона адресов, включить одну политику провайдера и завершиться -all. Не копируйте этот шаблон без изменений: правильная запись зависит от точных идентификаторов SMTP MAIL FROM или HELO и реальных источников отправки. Сначала составьте список провайдеров приложения, почтовых серверов, инструментов поддержки, платформ идентификации, маркетинговых систем, путей пересылки и резервных отправителей для аварийного восстановления. Публикуйте политику на проверяемом домене, а не автоматически на видимом домене From. Синтаксически корректная запись всё равно может авторизовать не те источники, упустить продакшен-поток или превысить лимиты DNS-проверки.

Квалификаторы превращают совпадение механизма в результат SPF

Механизм может начинаться с квалификатора: + для pass, - для fail, ~ для softfail или ? для neutral. Если квалификатора нет, подразумевается +. Квалификатор применяется только при совпадении механизма. Он не влияет на то, будут ли проверяться последующие термины, если механизм не совпал. Команды часто сосредотачиваются на итоговом all, но каждый предшествующий механизм include, адресный, a, mx или exists тоже имеет квалификатор и может завершить проверку. Проводите явное ревью, а не считайте, что ~all означает тестовый режим, а -all доказывает, что все источники известны. Результат fail — это свидетельство для получателя о проверенном SMTP-идентификаторе и IP-адресе, а не универсальная команда удалить письмо. Получатели применяют локальную политику. Neutral и softfail — не авторизация. Зафиксируйте ожидаемый результат для авторизованных, неавторизованных и временно неразрешённых источников и проверьте его на контролируемых наборах IP-адресов и идентификаторов.

Адресные механизмы прямолинейны, но требуют владения

Механизмы ip4 и ip6 авторизуют совпадающие сетевые диапазоны, записанные в синтаксисе своего протокола с необязательной длиной префикса. Они не требуют дополнительных запросов адресов при проверке, но могут устаревать при изменении исходящих сетей. Используйте публичные адреса отправки, никогда — частные адреса среды выполнения, и держите диапазоны настолько узкими, насколько позволяет резервирование. У каждого диапазона должны быть владелец, система-источник, окружение, процедура изменения и дата пересмотра. Механизм a разрешает DNS-имя в A- или AAAA-запись; по умолчанию используется текущий SPF-домен, если не указан другой domain-spec. Механизм mx разрешает MX-хосты и их адреса. Эти механизмы добавляют работу DNS и могут авторизовать инфраструктуру, которая меняется вне релизов приложения. Не используйте a или mx как упрощение, если только все разрешённые адреса не должны намеренно отправлять письма с этим точным SMTP-идентификатором. Отслеживайте изменения и тестируйте пути как для IPv4, так и для IPv6.

Include проверяет другую политику, а не вставляет фрагмент текста

Механизм include проверяет SPF-политику указанного домена и совпадает, если эта вложенная проверка вернула pass. Он не вставляет термины механически в текущую строку, а другие результаты вложенной проверки имеют определённые последствия. Используйте include, только если организация, на которую вы ссылаетесь, явно документирует этот домен для ваших отношений по отправке. Домен сайта провайдера, его MX-домен или видимый домен From не являются автоматически его SPF-include. Include создаёт операционные зависимости: изменение записи провайдера может поменять авторизацию, добавить вложенные DNS-запросы или вызвать временные и постоянные ошибки. Зафиксируйте вендора, сервис, точный домен для include, источник договорённости, владельца и план удаления. Протестируйте итоговую политику с фактического IP-адреса отправки провайдера и вашего домена в конверте. Никогда не «разворачивайте» include провайдеров в скопированные списки IP, если вы не готовы взять на себя отслеживание каждого изменения адресов провайдера и сохранение исходной семантики.

All, redirect и exp выполняют разные роли

Механизм all совпадает всегда и обычно ставится последним; термины после него не влияют на проверку. Его квалификатор определяет результат для источников, не совпавших ранее. Модификатор redirect указывает SPF использовать политику другого домена, если в текущей записи не совпал ни один механизм. Redirect — не то же самое, что include: include — это один механизм в общем порядке, а redirect заменяет итоговое решение политики при определённых условиях. В записи не должно быть нескольких модификаторов redirect. Модификатор exp может ссылаться на пояснение к результату fail, но он не авторизует почту и добавляет операционные соображения и вопросы приватности. Делайте пояснения общими и не включайте в них данные отправителя или получателя. Выбирайте redirect, когда домены намеренно используют общую политику целиком и их владельцы действуют согласованно. Выбирайте include, когда добавляете авторизованные источники одного провайдера в более широкую локальную политику. Тестируйте несовпадающие пути, а не только ожидаемые pass.

Избегайте ptr, а exists и макросы считайте продвинутыми инструментами

В RFC 7208 сказано, что механизм ptr не следует использовать, потому что он медленный, ненадёжный и создаёт нагрузку. Не добавляйте ptr, чтобы незнакомый IP прошёл проверку. Механизм exists может выполнять DNS-проверку существования с использованием domain-spec, а макросы SPF могут подставлять компоненты идентификатора и соединения в поддерживаемые поля. Эти инструменты позволяют выражать делегированную авторизацию или авторизацию для каждого клиента, но увеличивают сложность, работу DNS, раскрытие данных и число сценариев сбоев. Синтаксис макросов — не произвольный строковый шаблонизатор: допустимы только определённые буквы, трансформеры, разделители и контексты. Никогда не помещайте полные адреса получателей, секреты или неограниченный ввод тенантов в DNS-запросы. Если политику можно выразить простым набором собственных диапазонов IP и задокументированных include провайдеров, выбирайте этот вариант. Для продвинутых политик до выхода в продакшен подготовьте детерминированные тестовые наборы для нескольких доменов, отправителей, семейств IP, пустых обратных путей (null reverse-path), экранирования макросов, NXDOMAIN, тайм-аутов и неожиданных ответов DNS.

Соблюдайте лимит в десять терминов с DNS-запросами

RFC 7208 ограничивает реализации SPF десятью терминами, вызывающими DNS-запросы за одну проверку, включая обработку include, a, mx, ptr, exists и redirect. Вложенные include тоже учитываются. Спецификация также рекомендует ограничивать пустые запросы (void lookups), когда DNS возвращает пустой ответ или ошибку имени, двумя. Превышение лимитов обработки может дать постоянную ошибку вместо pass. Считайте развёрнутый граф проверки, а не только термины, видимые в строке TXT верхнего уровня. Один include провайдера может тянуть за собой несколько вложенных зависимостей, а механизм mx может вызвать запросы адресов для нескольких хостов. Используйте проверяющий инструмент, учитывающий стандарт, с зафиксированными DNS-ответами, но и сами изучайте дерево зависимостей. Удалите неиспользуемых провайдеров и избыточные механизмы. Избегайте небезопасного «разворачивания», при котором обновления провайдера незаметно теряются. Отслеживайте изменения политики и оставляйте запас по запросам на развитие провайдеров, а не разворачивайте запись ровно на максимуме.

Публикуйте ровно одну SPF-политику на домен

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

Связывайте синтаксис SPF с DMARC, не смешивая их

SPF обычно проверяет домен MAIL FROM или идентификатор HELO по правилам протокола. DMARC использует видимый домен From по RFC 5322 и принимает SPF как один из путей только тогда, когда аутентифицированный SPF-домен выровнен с этим видимым доменом. Поэтому return path провайдера может проходить SPF, оставаясь невыровненным для DMARC. И наоборот, выровненный DKIM с результатом pass может удовлетворить DMARC, когда SPF не проходит или не выровнен. Записывайте результат SPF, проверенный домен, подключающийся IP, видимый From, результаты DKIM, выравнивание и итог DMARC раздельно. Пересылка обычно меняет подключающийся IP и может ломать SPF, даже если исходный отправитель был авторизован. Не расширяйте SPF, включая в него произвольные пересылающие серверы. Используйте DKIM и, где уместно, механизмы аутентифицированной цепочки и данные получателей. Прохождение SPF не доказывает целостность письма, безопасность содержимого, согласие получателя, приём сервером или попадание во «Входящие».

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

Перед правкой DNS экспортируйте текущую запись и перечислите каждый механизм или модификатор с владельцем и назначением. Разберите кандидата по грамматике RFC 7208, разверните DNS-зависимости из контролируемых снимков, посчитайте термины, вызывающие запросы, и протестируйте авторизованные и неавторизованные наборы IPv4 и IPv6. Проверьте поведение вложенных include при результатах pass, fail, neutral, softfail, временной и постоянной ошибке. Протестируйте обработку пустого обратного пути через HELO, поддомены, return path провайдеров и источник, который должен дойти до all. Публикуйте через обычный процесс контроля изменений, запросите авторитетный и рекурсивный DNS, затем отправьте контрольные письма через каждый реальный поток. Сохраняйте исходные Authentication-Results от доверенных получателей и сравнивайте их с ожидаемыми идентификаторами. Откатывайте изменения при пропаже продакшен-источников, выборе нескольких записей, ошибках лимита запросов, массовых temperror или непреднамеренной авторизации. Никогда не тестируйте, отправляя нежелательные письма.

Настройте SPF с SendHQ

SendHQ создаёт политику SPF TXT при настройке адреса отправителя. При конфликтующих политиках SPF настройка останавливается, а вместо молчаливой перезаписи несвязанной политики сообщается рекомендуемое объединённое значение SPF. Сохраняйте ровно одну выбираемую политику SPF; подробности настройки и исправления смотрите в документации Domains and DNS.

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

Источники

• RFC 7208: инфраструктура политики отправителя (SPF) — RFC Editor
• RFC 7489: аутентификация сообщений, отчётность и соответствие на уровне домена (DMARC) — RFC Editor
• RFC 5321: простой протокол передачи почты (SMTP) — RFC Editor