Как проверить запись SPF (и исправить то, что её ломает)

SPF (Sender Policy Framework) — это запись DNS, в которой перечислены серверы, имеющие право отправлять почту от имени вашего домена. Когда сообщение приходит, принимающий сервер читает запись и сравнивает её с сервером, который фактически доставил сообщение. Если отправителя нет в списке, сообщение может быть помечено как спам или отклонено полностью.

Запись невелика, но не прощает ошибок: одна ошибка форматирования может сделать недействительной всю политику, и ничто вас об этом не предупредит. Ваша почта просто начнёт не проходить проверки на чужих серверах. Поэтому обдуманная проверка, а не надеющийся взгляд на панель DNS, стоит пяти минут.

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

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

Шаг за шагом: проверка записи SPF домена

1. 1

   Откройте проверку SPF

   Воспользуйтесь проверкой SPF на этом сайте. Она читает записи TXT домена и оценивает политику SPF за вас, так что вам не придётся на глаз выискивать нужную запись в списке.

2. 2

   Введите имя домена

   Введите голое имя домена, например example.com, без https:// и без www. Как и другие инструменты поиска здесь, проверка принимает имена доменов; она не принимает IP-адрес, потому что SPF — свойство домена, а не сервера.

3. 3

   Найдите запись, которая начинается с v=spf1

   Домен часто публикует несколько записей TXT для токенов подтверждения и других служб. Только та, что начинается с v=spf1, и является политикой SPF. Если таких записей две, вы нашли самую распространённую неисправность SPF из всех, описанную ниже.

4. 4

   Читайте механизмы слева направо

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

5. 5

   Проверьте, чем заканчивается запись

   Завершающий механизм all — это вердикт для отправителей, которые не совпали ни с чем другим. То, записано там -all или ~all, решает, будет ли несанкционированная почта отклонена или просто встречена с недоверием, поэтому никогда не оставляйте его без проверки.

Как читать политику v=spf1 простыми словами

Запись SPF — это одна строка терминов, разделённых пробелами. Она выглядит пугающе, но строительных блоков всего несколько, и большинство записей используют только три или четыре из них:

example.com.  IN  TXT  "v=spf1 include:_spf.example.net ip4:203.0.113.25 mx ~all"

Символ перед механизмом — это его квалификатор. + означает пройдено и является значением по умолчанию, когда символ не записан, - означает не пройдено, ~ означает мягкий отказ, а ? означает нейтрально, без мнения в ту или иную сторону. На практике вы почти всегда увидите квалификаторы у завершающего all, а механизмы, перечисленные без них, что просто означает обычное прохождение.

Поломка номер один: две записи SPF на одном имени

Домену разрешена ровно одна запись SPF. Когда проверяющий или принимающий сервер находит две записи TXT, обе начинающиеся с v=spf1, спецификация говорит, что результат — ошибка, и политика считается непригодной. SPF в этом состоянии не работает наполовину; для целей аутентификации он просто выключен, и каждое сообщение оценивается так, как если бы вы ничего не публиковали.

Обычно это происходит невинно. Кто-то настраивает новую службу отправки, следует её инструкциям по добавлению записи SPF и создаёт вторую запись вместо того, чтобы отредактировать существующую и включить в неё новую службу. Обе записи выглядят правдоподобно, панель DNS не показывает жалоб, а сбой проявляется только позже, когда почта тихо оказывается в папках спама.

Поломка номер два: больше 10 запросов DNS

Проверка записи SPF заставляет принимающий сервер выполнять работу DNS, поэтому спецификация ограничивает эту работу: одна оценка может использовать не более 10 механизмов и модификаторов, запускающих запросы DNS. Считаются include, a, mx, ptr, exists и redirect. Простые термины ip4 и ip6 ничего не стоят, потому что ответ уже записан в записи.

Ловушка в том, что include вкладываются друг в друга. Один include может подтянуть политику, которая сама содержит ещё несколько запросов, и все они засчитываются в ваши 10. Домен, который авторизует службу рассылок, службу поддержки, CRM и собственные серверы, может превысить лимит, хотя ни одна отдельная запись не выглядит чрезмерной. Превысьте его, и оценка завершится постоянной ошибкой: SPF будет отказывать для каждого сообщения, включая законные.

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

Исправление: объединить всё в одну запись

1. 1

   Перечислите каждую службу, которая отправляет от имени домена

   Включите легко забываемые: почту контактной формы сайта, выставление счетов, рассылки, обращения в поддержку и любую службу уведомлений. Всё, что вы пропустите, не пройдёт SPF, как только объединённая запись вступит в силу.

2. 2

   Соберите одну запись, содержащую их все

   Начните с существующей записи и отредактируйте её, добавляя include для каждой дополнительной службы, вместо того чтобы публиковать что-то новое. Завершите запись -all, когда будете уверены, что список полон.

3. 3

   Опубликуйте её как одну запись TXT

   Замените старые записи объединённой в корне домена. В конце должна остаться ровно одна запись TXT, начинающаяся с v=spf1, наряду с не связанными записями TXT, которые нужны домену.

4. 4

   Запустите проверку снова

   Повторите проверку SPF и убедитесь, что объединённая политика оценивается чисто, затем отправьте тестовые сообщения через каждую службу и убедитесь, что они приходят и проходят аутентификацию на принимающей стороне.

example.com.  IN  TXT  "v=spf1 include:_spf.example.net ip4:198.51.100.40 mx -all"

После публикации дайте время TTL записи: резолверы, закэшировавшие старую политику, продолжают пользоваться ею до истечения срока, что обычно занимает от нескольких минут до нескольких часов. Если проверка всё ещё показывает старую запись, подождите и проверьте снова, а не публикуйте что-то ещё. Обратите внимание: результаты поиска на этом сайте пропускают частные, петлевые адреса и адреса документации, поэтому политика, проверенная на примерах адресов, — это то, что вы читаете, а не то, с чего вы отправляете настоящую почту.

Проверьте вердикт на сообщении, которое вы действительно получили

Всё до сих пор проверяет запись, которую вы опубликовали. Полученное сообщение говорит вам, к какому выводу пришёл настоящий получатель. Отправьте сообщение через одну из ваших служб в почтовый ящик, который вы контролируете, откройте его полные заголовки (в руководстве по отслеживанию заголовков писем показано, где каждый клиент их прячет) и найдите строку Authentication-Results, написанную принимающим сервером. Часть SPF читается как spf=pass smtp.mailfrom=example.com, и слово после spf= — это вердикт. Повторите проверку для каждой службы, потому что каждая подключается со своих серверов и получает свой собственный вердикт.

Используйте тот же заголовок, чтобы найти отсутствующего отправителя. Если легитимная служба показывает spf=fail, строка Received прямо выше показывает адрес, который подключился; выясните, какой службе он принадлежит, затем проверьте, покрывают ли includes и термины ip4 вашей записи эту службу. Исправляйте запись, а не сообщение. И доверяйте только строке Authentication-Results, написанной вашим собственным принимающим сервером, потому что отправитель может вставить поддельную в любое сообщение. Проверка одного сообщения на службу после каждого изменения записи ловит большинство ошибок, пока они ещё дёшевы.