Что проверяет SPF
SPF (Sender Policy Framework) это запись в DNS домена, в которой перечислены серверы, имеющие право отправлять почту от его имени. Принимающий сервер смотрит на IP-адрес, с которого пришло письмо, и на домен в адресе возврата (envelope-from), находит запись SPF и сверяет. Совпало значит pass, не совпало значит fail или softfail.
Результат виден в заголовках письма, обычно в строке Authentication-Results или Received-SPF. Там написано, кто проверял, какой IP и какой домен использовался. С этого и нужно начинать разбор.
Почему получается fail
Самая частая причина: письма уходят с сервера, которого нет в записи SPF. Например, домен настроен на почтовый сервис, но рассылки идут ещё и через хостинг, CRM или другой сервис, и его забыли добавить.
Вторая: в DNS две записи SPF. Должна быть одна, иначе проверка считается ошибочной. Третья: превышен лимит в десять DNS-запросов при вычислении записи из-за множества подключений include. Четвёртая: опечатка, лишний пробел, неверный механизм. Пятая: пересылка. Когда письмо перенаправляется с одного ящика на другой, IP-адрес меняется, и SPF у получателя расходится.
Отдельно нужно понимать различие: fail означает жёсткое несоответствие, softfail помечает письмо как подозрительное, но не требует отказа.
Проверка шаг за шагом: SPF fail
Откройте исходный текст полученного письма, найдите результат SPF и IP-адрес отправителя. Запросите у DNS TXT-записи домена и найдите строку, начинающуюся с v=spf1. Убедитесь, что она одна.
Сверьте, входит ли ваш IP или сервис отправки в перечисленные механизмы. Для внешних сервисов обычно нужно добавить их механизм include по их инструкции. Проверьте, сколько запросов запись порождает: механизмы include, a, mx и redirect считаются, лимит равен десяти.
Если письма пересылаются, проверьте, есть ли у вас подпись DKIM и политика DMARC: они устойчивее к пересылке, чем один SPF.
Если вы не уверены, какие сервисы вообще отправляют письма от вашего домена, проанализируйте заголовки полученных писем и отчёты DMARC за несколько недель. Забытые источники обнаруживаются именно так: например, система выставления счетов или форма на сайте.
Исправление: SPF fail
Соберите единую запись SPF, в которой перечислены все легитимные источники: собственный сервер, почтовый сервис, сервисы рассылок. Заканчивайте её механизмом, соответствующим вашей строгости: ~all (мягкий отказ) на время настройки, -all (строгий), когда вы уверены, что список полон.
Удалите дублирующие записи, сократите число вложенных подключений, если упираетесь в лимит. Изменения в DNS вступают в силу не мгновенно: подождите обновления кэша, которое может занять до нескольких часов.
После изменений отправьте тестовое письмо и убедитесь, что SPF показывает pass.
Когда не нужно менять запись
Если ошибка появляется только у одной пересланной цепочки писем, менять SPF не стоит: пересылка ломает его по природе. Проблема также не в SPF, если письмо доходит, но попадает в спам из-за содержания. Тогда смотрите репутацию и остальные проверки.
Проверяйте изменения записи не только сразу, но и через день: у разных получателей кэш DNS обновляется по-разному, и ошибка может проявляться только у части адресатов.
Типичные ошибки в записи
Частые промахи выглядят так. Запись начинается не с v=spf1. Между механизмами лишние символы либо кавычки в неправильных местах. Использован механизм ptr, который не рекомендуется из-за медленной работы. Забыт пробел перед механизмом. Записаны IP-адреса в неверном формате. Для домена без отправки почты не указано явное запрещение отправки.
Если домен вообще не рассылает письма, полезно опубликовать запись, запрещающую любую отправку: это защищает от подделки адреса. Для активных доменов при каждом добавлении нового сервиса обновляйте запись и проверяйте, что число запросов не выросло сверх допустимого.