Проверка spf записи домена: как убедиться, что настройка защищает от подделки писем

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

Из чего состоит запись и как её читать

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

Механизмы разрешения

• include — ссылка на SPF-политику стороннего сервиса, которому разрешено отправлять почту от имени домена;

• ip4 и ip6 — прямое указание конкретных IP-адресов;

• a и mx — разрешение отправки с серверов, указанных в A- и MX-записях самого домена.

Квалификаторы результата

Перед каждым механизмом может стоять один из символов, определяющий, что делать с письмом, не прошедшим проверку: + разрешает отправку, ~ помечает письмо как подозрительное, но не блокирует, — предписывает жёсткий отказ, а ? оставляет решение на усмотрение принимающего сервера. Финальный квалификатор в конце строки задаёт политику по умолчанию для всех источников, не перечисленных явно.

Типичные ошибки конфигурации

Превышение лимита DNS-запросов

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

Несколько записей на одном домене

Стандарт допускает только одну SPF-запись на домен. Если по ошибке публикуются две — например, при миграции между сервисами без удаления старой записи, — почтовые серверы могут интерпретировать это как признак некорректной настройки и трактовать результат проверки как отрицательный.

Устаревшие include-записи

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

Что стоит регулярно контролировать

1. Соответствует ли список разрешённых источников реально используемым сервисам отправки.

2. Не превышено ли количество вложенных DNS-запросов при разрешении записи.

3. Существует ли только одна SPF-запись на домен и на каждом используемом поддомене.

4. Соответствует ли финальный квалификатор фактической строгости политики, которую компания готова применять.

Как ошибки сказываются на доставляемости

Некорректно настроенная запись редко приводит к мгновенной и заметной поломке — чаще эффект проявляется постепенно, через снижение процента писем, попадающих во «Входящие», и рост доли сообщений, помечаемых как подозрительные. Поскольку SPF является лишь одним из компонентов комплексной проверки подлинности отправителя, ошибка в этой записи снижает общий уровень доверия к домену даже при правильной настройке остальных механизмов аутентификации.

Что делать после обнаружения расхождений

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