Проверка SPF записи: работает ли ваша SPF?
Письма попадают в спам или сервис сообщает, что ваша запись SPF недействительна? Введите домен ниже. Инструмент получит запись SPF, пройдёт по каждому include, сравнит число DNS-запросов с лимитом 10 и простым языком перечислит, что нужно исправить.
Как принимающий сервер использует вашу запись SPF
Когда приходит письмо, принимающий сервер смотрит на домен в адресе отправителя конверта (envelope sender) и получает SPF-запись этого домена: запись TXT, начинающуюся с v=spf1. Затем он проверяет, есть ли в списке IP-адрес только что подключившегося сервера. Результат — pass, fail, softfail или neutral, и получатель учитывает его вместе с другими сигналами, решая, куда отправить письмо: во «Входящие» или в спам.
SPF проверяет адрес отправителя конверта, а не адрес в поле From, который люди видят в почтовой программе. Закрыть этот разрыв — задача DMARC.
Элементы SPF вкратце
| Элемент | Что делает |
|---|---|
| ip4:192.0.2.0/24 | Разрешает адрес или диапазон IPv4 |
| ip6:2001:db8::/32 | Разрешает адрес или диапазон IPv6 |
| a | Разрешает адреса из собственных записей A и AAAA домена |
| mx | Разрешает адреса почтовых серверов домена |
| include:_spf.example.net | Дополнительно разрешает всё, что разрешает SPF-запись того домена |
| exists:name | Разрешает, если DNS-запрос имени возвращает адрес |
| ptr | Устарел. Сопоставляет по обратному DNS, и использовать его не следует |
| all | Соответствует всему, поэтому стоит последним и задаёт результат по умолчанию |
Квалификатор перед элементом задаёт результат при совпадении: + pass (по умолчанию), - fail, ~ softfail, ? neutral. Обычно запись заканчивают на ~all, который помечает неуказанных отправителей как подозрительных, или на -all, который просит получателей их отклонять.
Почему SPF ломается, когда добавляешь ещё один сервис
SPF допускает не более 10 элементов, вызывающих DNS-запрос при обработке записи. Считаются include, a, mx, ptr и exists, а также модификатор redirect. ip4, ip6 и all не считаются. Запросы внутри подключённой записи входят в тот же общий счёт.
Так исправная запись выходит из строя: вы добавляете сервис рассылок, helpdesk, CRM и биллинг, у каждого свой include, а в некоторых из них есть собственные include. Если превысить 10, SPF возвращает постоянную ошибку. Получатели могут тогда считать, что у домена вообще нет SPF, и никто вас об этом не предупредит.
- Удалите include для сервисов, которыми больше не пользуетесь.
- Заменяйте include диапазонами ip4 и ip6, если адреса провайдера стабильны.
- Никогда не используйте ptr.
- По возможности выделяйте каждому отправляющему сервису собственный поддомен. У каждого имени свой лимит в 10.
- Если вы разворачиваете include в адреса, помните, что провайдеры меняют свои диапазоны, поэтому такую запись нужно регулярно обновлять.
Как безопасно настроить политику SPF
- Публикуйте ровно одну запись SPF на имя. Две записи — это постоянная ошибка.
- Начните с ~all, пока проверяете, что все законные отправители перечислены, а когда убедитесь, переходите на -all.
- Помните, что SPF не наследуется. Поддомену, который отправляет почту, нужна собственная запись, а поддомен, который почту не отправляет, может опубликовать v=spf1 -all.
- Используйте SPF вместе с DKIM и политикой DMARC. Каждый из них компенсирует слабые места остальных.