Что проверяет инструмент MX
Инструмент читает MX-записи домена и перечисляет каждый почтовый сервер с его приоритетом. Если имена хостов совпадают с шаблоном известного провайдера, он называет вероятного провайдера. Затем он получает политику SPF из TXT-записей домена и политику DMARC из _dmarc внутри домена, разбирает обе и сообщает о замечаниях.
Всё здесь читается из публичного DNS. Инструмент не подключается к вашему почтовому серверу, не отправляет тестовые письма и не заглядывает в почтовые ящики.
Как читать MX-записи
Отправляющие серверы сначала пробуют MX-хост с наименьшим значением приоритета и переходят к большим числам только при неудаче. Равные числа делят нагрузку. Целью MX должно быть имя хоста, которое разрешается в адрес; это не может быть IP-адрес и не может быть CNAME. Если у домена вообще нет MX-записи, отправители обращаются к записи A или AAAA домена, а этого редко кто хочет.
Домен, который никогда не должен принимать почту, может опубликовать null MX: единственную запись с приоритетом 0 и целью в виде одной точки. Она сообщает отправителям, что нужно сразу вернуть ошибку, а не повторять попытки несколько дней.
SPF: кто может отправлять почту от имени домена
SPF — это TXT-запись, начинающаяся с v=spf1, в которой перечислены серверы, имеющие право использовать домен в адресе отправителя конверта. Замечания ищут ошибки, которые ломают SPF на практике: больше одной SPF-записи, из-за чего проверка сразу завершается ошибкой; механизмы, требующие более десяти DNS-запросов с учётом вложенных include; устаревший механизм ptr; окончание +all, которое разрешает отправку всему интернету.
Политика, заканчивающаяся на ~all, просит получателей относиться к остальным источникам с подозрением, а -all — отклонять их. Оба варианта разумны в сочетании с DMARC. Запись с ?all или без механизма all почти не даёт защиты.
DMARC: политика и отчёты
DMARC привязывает SPF и DKIM к адресу, который люди действительно видят в заголовке From. Письмо проходит проверку, когда проходит SPF или DKIM и аутентифицированный домен согласован с доменом из From. Запись указывает, что получателям делать с письмами, не прошедшими проверку (none, quarantine или reject), и куда отправлять агрегированные отчёты.
p=none — правильная отправная точка, потому что позволяет собирать отчёты, не влияя на доставку. Но это не конечная цель. Домен, который остаётся на p=none бессрочно, видит картину, но не защищён от подделки. Инструмент показывает политику, политику для поддоменов, если она задана, значение pct и адреса для отчётов.
Почему для DKIM нужен селектор
Открытые ключи DKIM публикуются по имени selector._domainkey.example.com, а селектор — произвольная метка, выбранная отправляющей системой. У домена может быть много селекторов, и DNS не даёт способа их перечислить, поэтому ни один инструмент не может найти ключ DKIM по одному лишь имени домена. Селектор можно найти в заголовке DKIM-Signature письма, отправленного с домена, в теге s=, и затем запросить это имя через проверку DNS.
Чего эти записи доказать не могут
Корректные записи MX, SPF, DKIM и DMARC необходимы для надёжной доставки, но не гарантируют, что письмо попадёт во «Входящие». Почтовые сервисы учитывают также репутацию отправителя, долю жалоб, содержание и реакцию получателей, а ничего из этого в DNS не видно. Точно так же чистая конфигурация не доказывает, что почта ходит. Она показывает, что опубликованная политика согласована, то есть ту часть, которую можно исправить на стороне DNS.