Как проверить мои записи MX, SPF, DKIM и DMARC?

Как проверить MX-запись?

Выполните dig MX с вашим доменом и +short и сравните приоритеты и имена хостов со значениями, которые дал ваш провайдер. Ответ выводит по одной строке на запись: приоритет, пробел и хост. Для Proton Mail ожидается 10 mail.protonmail.ch. и 20 mailsec.protonmail.ch.; для Fastmail 10 in1-smtp.messagingengine.com. и 20 in2-smtp.messagingengine.com.; для Mailbox.org четыре хоста mxext.

Здесь проявляются две проблемы. Запись прежнего провайдера, оставшаяся в списке, делает доставку непредсказуемой, поэтому удалите её. А пустой ответ означает отсутствие MX: тогда отправители обращаются к адресной записи домена, как описывает RFC 5321. Что означает каждая строка, объясняется в разделе что такое MX-запись.

Как проверить запись SPF?

Запросите TXT-записи в корне домена и убедитесь, что ровно одна строка начинается с v=spf1. В корне есть и другие TXT-записи, например подтверждение владения вашего почтового провайдера, поэтому прочитайте весь список. Две строки, начинающиеся с v=spf1, — это ошибка: RFC 7208 возвращает постоянную ошибку, если у домена больше одной записи SPF.

Затем посчитайте запросы. Каждый include, a, mx, ptr и exists, а также модификатор redirect учитываются в лимите 10, причём include учитывает и всё, что вложено в него. Запись, превышающая лимит, не срабатывает для всех отправителей. Создание записи подробно описано в разделе как создать запись SPF.

Как проверить DKIM, если я не знаю селектор?

Используйте селектор вашего провайдера: перечислить селекторы из DNS нельзя, поэтому возьмите их на экране DKIM у провайдера. DNS не позволяет получить список имён под _domainkey. Селекторы: protonmail, protonmail2 и protonmail3 у Proton Mail, fm1, fm2 и fm3 у Fastmail, а также MBO0001–MBO0004 у Mailbox.org.

Имя для запроса — selector._domainkey.yourdomain. Провайдер, использующий CNAME-записи, как эти три, отвечает CNAME на свой хост. Провайдер, публикующий ключ напрямую, отвечает TXT-записью, содержащей v=DKIM1 и p= с открытым ключом. Пустое p= означает, что ключ отозван. Самый надёжный тест — настоящее письмо, потому что существующая запись может не использоваться: отправьте письмо другому провайдеру и найдите dkim=pass в полных заголовках.

Как проверить запись DMARC?

Запросите TXT-запись на _dmarc.yourdomain и убедитесь, что есть одна строка, которая начинается с v=DMARC1 и содержит политику p=. Если p отсутствует, получатели считают политику равной none. Если в строке нет rua, агрегированные отчёты не создаются, и этап наблюдения в развёртывании DMARC ничего вам не скажет. Записи, написанные в старом стиле, могут всё ещё содержать тег pct, который RFC 9989 удалил.

Поддомен без собственной записи подпадает под политику родителя через обход дерева DNS, не более чем за восемь запросов. Запрос имени, для которого записи нет, ничего не возвращает, что равносильно отсутствию DMARC.

Почему мой запрос всё ещё показывает старое значение?

Кэш хранит старый ответ, пока не истечёт его TTL, и отсутствующая запись тоже может быть закэширована. Время распространения изменения примерно равно старому TTL записи на момент, когда вы её изменили. По рекомендациям вендоров обычное изменение MX занимает от одного до четырёх часов, а в худшем случае — до 24–48 часов. RFC 2308 добавляет, что отрицательные ответы кэшируются с TTL из SOA-записи зоны, поэтому только что созданная запись может казаться отсутствующей у некоторых резолверов.

Чтобы обойти кэши, спросите авторитетный сервер имён: найдите его через dig NS, затем повторите запрос с @ и его именем, как в блоке кода выше. Если авторитетный сервер показывает новое значение, а ваш резолвер нет, подождите. Если не показывают оба, запись не сохранена или имя хоста неверно, чаще всего потому, что DNS-редактор добавил домен второй раз.

Если после того, как записи выглядят правильно, почта всё равно не приходит, перейдите к разделу почему почта не приходит на собственный домен.

Какие онлайн-инструменты могут проверять почтовые записи?

Любой онлайн-запрос DNS или проверка почтовой аутентификации, обращающаяся к публичному DNS, даёт тот же ответ, что и dig, с более удобным отображением. Используйте тот, который показывает исходный текст записи, чтобы сравнить его посимвольно со значением вашего провайдера. Не вставляйте в него приватные данные: ему нужно только имя домена.

По подсчёту Postelva от 12 ноября 2026, полная настройка Proton Mail требует 8 записей (1 TXT для подтверждения, 2 MX, 1 SPF, 3 DKIM, 1 DMARC) и 6 запросов, потому что две MX-записи используют один запрос, а записи подтверждения и SPF — общий запрос корневых TXT. Сохраните шесть команд один раз и повторяйте их после каждого изменения. Те же записи сравниваются в разделе SPF, DKIM и DMARC: в чём разница.

Правило, которое можно процитировать: после каждого изменения DNS запрашивайте четыре типа записей и отправляйте тестовое письмо; запись верна только тогда, когда запрос и письмо согласуются.