Бесплатный инструмент
Читаем SPF-политику домена, разворачиваем каждый include за ней и считаем, во сколько DNS-запросов обходится всё вместе — при лимите в десять. Это число и есть ответ: запись может быть безупречной и всё равно не проходить ни у одного получателя.
SPF — это список серверов, которым разрешено отправлять почту от имени вашего домена, опубликованный одной TXT-записью на самом домене. Принимающий сервер берёт адрес, с которого пришло письмо, и спрашивает вашу запись, разрешён ли он.
Списком в явном виде это бывает редко. На практике это набор элементов include: — по одному на каждый сервис, через который вы отправляете, — и каждый ведёт на запись, которую поддерживает этот провайдер. То есть ваша политика собирается в момент доставки из записей, которыми вы не управляете.
Десять запросов кажутся запасом, пока не посчитаешь обычную компанию: почтовый провайдер, CRM, служба поддержки, сервис счетов и рассыльщик — это уже пять include, и некоторые из них сами по себе стоят два-три запроса, потому что внутри включают другие записи.
Никакого предупреждения не будет. Запись по-прежнему разбирается, зона выглядит правильной, письма идут — пока проверка не перевалит за десять. После этого каждый получатель, следующий стандарту, возвращает permerror и считает вашу почту неаутентифицированной. Шкала выше — это тот самый счётчик, а список под ней показывает, какой элемент его израсходовал и из чьей записи он пришёл.
+all, ?all, отсутствие all, элементы после него и устаревший механизм ptr. SPF авторизует сервер; о самом письме он не говорит ничего и не переживает большинство пересылок. Это одна из трёх составляющих DMARC наряду с DKIM, и домен, у которого есть только SPF, находится в одной пересланной рассылке от сбоя, о котором он никогда не узнает.
RFC 7208 отводит на всю проверку SPF десять DNS-запросов. Каждый include, a, mx, ptr, exists и redirect стоит один — включая те, что находятся внутри записей ваших провайдеров, которые вы не писали и не видите. За пределом лимита получатель возвращает permerror, и SPF не проходит ни для одного письма, даже если отправляющий сервер в списке есть.
Уберите include сервисов, с которых вы больше не отправляете, — почти всегда найдётся хотя бы один. Замените свой собственный include на диапазоны ip4, которые не стоят ничего. Вынесите отдельный сервис на поддомен с собственной SPF-записью. «Разворачивание» чужого include работает и тихо ломается в день, когда провайдер сменит адреса.
Нет. На одном имени допускается ровно одна запись v=spf1; две — это постоянная ошибка, и получатели не выбирают из них, а проваливают проверку. Если вы отправляете через несколько сервисов, все include идут в одну запись.
~all (softfail) — безопасный вариант по умолчанию, пока вы не уверены, что перечислили всех отправителей. -all (hardfail) говорит получателям отвергать всё остальное; на него стоит перейти, когда отчёты DMARC покажут, что ничего легитимного не падает. +all разрешает отправку всему интернету и всегда является ошибкой.
Часто нет: пересылающий сервер отправляет письмо со своих адресов, которых в вашей записи нет. Именно для этого существует DKIM и именно поэтому DMARC засчитывает любую из двух проверок — настройка только с SPF ломается на списках рассылки и правилах пересылки.