Проверить записи домена: семь проверок за один запрос

Письма не доходят: с чего начать проверку

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

Симптом звучит одинаково у всех почтовиков. На яндекс почту не доходят письма от одного отправителя, на mail не доходят письма от него же, а сам отправитель видит у себя «отправлено» и больше ничего. Иногда прилетает отбойник с формулировкой, что электронное письмо не дошло до адресата, и в нём стоит код ответа сервера. Чаще не прилетает ничего.

Порядок разбора такой. Сначала проверка MX-записи. Нет её или она указывает на несуществующий хост, значит домен физически не принимает почту. Дальше SPF и DMARC, они лежат в TXT-записях, поэтому проверить TXT-запись стоит даже когда с MX всё в порядке. Последним идёт DKIM. Каждый шаг отчёт отмечает отдельно и пишет, что именно менять.

Отдельный случай, когда письма доходят, но ложатся в папку «Спам». DNS тут бывает безупречным, а причина сидит в репутации домена и качестве базы. Этот случай разобран в статье почему письма попадают в спам.

Что проверяется

• MX — принимает ли домен почту, есть ли резервный сервер, резолвятся ли имена серверов.
• SPF — кому разрешено отправлять от вашего имени, укладывается ли запись в лимит десяти DNS-запросов.
• DKIM — опубликован ли открытый ключ, какой длины, не отозван ли.
• DMARC — какая политика применяется к письмам, не прошедшим проверку, и приходят ли отчёты.
• MTA-STS — защищено ли соединение от понижения до открытого текста.
• TLS-RPT — получаете ли вы отчёты о проблемах с шифрованием.
• BIMI — показывается ли логотип рядом с письмом.

С чего начинать, если оценка низкая

Порядок задан весами: сначала MX, потом SPF, потом DMARC. Без MX домен не принимает почту, и остальное обсуждать рано. SPF настраивается за десять минут и закрывает базовый случай подделки. DMARC ставится в режиме наблюдения (p=none) сразу, а ужесточается через две-четыре недели, когда накопятся отчёты.

DKIM обычно включается одной галочкой в панели почтового сервиса, и он сам публикует запись или даёт готовое значение для DNS. MTA-STS, TLS-RPT и BIMI имеет смысл трогать последними: они дают меньший эффект и требуют больше возни, а BIMI ещё и денег на сертификат.

Что эта проверка не покажет

Всё, что находится за пределами DNS. Репутацию домена и IP-адресов, историю жалоб, долю отказов, попадание в чёрные списки, качество содержания писем. Домен с идеальными записями отлично уходит в спам, если с него полгода рассылали по купленной базе.

Проверка также не подтверждает, что подпись DKIM корректна на конкретном письме: снаружи видно только опубликованный ключ. Чтобы проверить саму подпись, нужен исходный текст письма с заголовками.

В каком порядке чинить

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

1. MX. Без них домен не принимает почту, и всё остальное бессмысленно. Проверьте заодно, что не остались записи прежнего провайдера.
2. SPF. Одна запись, укладывающаяся в десять DNS-запросов, с ~all или -all в конце. Две записи v=spf1 на домене дают ошибку, при которой проверка не проходит ни для кого.
3. DKIM. Свой селектор у каждого сервиса, который отправляет от вашего имени. Ключ 2048 бит.
4. DMARC. Сначала p=none с адресом для отчётов, именно отчёты показывают, кого вы забыли на шагах 2 и 3.
5. MTA-STS и TLS-RPT. Защита канала. Ставятся после того, как аутентификация работает.
6. BIMI. Логотип, требующий DMARC на quarantine или reject. Всегда последним.

Почему 100 из 100 не гарантируют инбокс

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

Отсюда две типичные ситуации. Первая: все записи идеальны, а письма в спаме: почти всегда это репутация, испорченная рассылкой по грязной базе. Вторая: записи с ошибками, а письма доходят. Домен старый, с хорошей историей, и провайдеры дают ему кредит доверия. Настройка это необходимое условие, а не достаточное.

Что проверка видит и чего не видит

Все семь проверок делаются снаружи, по публичным DNS-записям. Этого достаточно, чтобы найти большинство поломок: отсутствующие записи, синтаксические ошибки, переполненный лимит SPF, слабый ключ DKIM, политику DMARC, которая ничего не делает.

Но есть вещи, которые снаружи не видны в принципе. Подписывается ли конкретное письмо, видно только по его заголовкам. Совпадает ли домен подписи с полем From — то же самое. Не отправляет ли от вашего имени забытый сервис — это показывают исключительно отчёты DMARC. Поэтому проверка домена и отчёты дополняют друг друга, а не заменяют.

Частый случай: записи в порядке, письма в спаме

Если оценка высокая, а письма всё равно не доходят, дело почти всегда в репутации, а не в DNS. Проверьте три вещи по порядку: как собрана база (покупка и парсинг убивают домен за одну рассылку), какая доля отказов в последних отправках, и не попал ли домен или IP в чёрные списки.

Мёртвые адреса бьют по репутации сильнее всего: провайдер видит высокий процент отказов и делает вывод, что отправитель рассылает по списку, который не поддерживает. Поэтому чистка базы даёт эффект быстрее, чем любая доработка записей.

Какие DNS-записи отвечают за почту

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

TXT-запись

Самый универсальный тип. Обычная текстовая строка, привязанная к имени. Почта использует её постоянно, потому что SPF, DKIM, DMARC, BIMI и TLS-RPT это всё TXT-записи, просто с разным содержимым и на разных именах.

Отсюда и путаница. Вопрос «есть ли у домена TXT-запись» почти всегда означает «настроен ли SPF» или «опубликован ли DKIM», и проверка выше отвечает на него по каждому механизму отдельно. Голых TXT-записей без назначения на домене обычно тоже хватает: там лежат подтверждения прав для поисковиков и сервисов, к доставке они отношения не имеют.

Одно ограничение стоит помнить. Запись v=spf1 на домене может быть только одна. Две такие записи дают permerror, при котором SPF отваливается целиком.

MX-запись

Указывает, какие серверы принимают почту для домена, и в каком порядке к ним обращаться. Число перед именем это приоритет. Меньшее значение опрашивается первым.

Отсутствие MX означает, что домен почту не принимает. Для сервисов валидации это первый и самый дешёвый фильтр: если у домена нет MX, адрес на нём заведомо нерабочий, и дальше проверять нечего.

PTR-запись и обратная зона

PTR отвечает на обратный вопрос. Какому имени принадлежит IP-адрес. Для почты она важна потому, что получатели сверяют три вещи: адрес соединения, имя из PTR и имя, которым сервер представился в приветствии. Расхождение выглядит подозрительно, и часть получателей отклоняет соединение до всякой аутентификации.

Важная особенность: PTR живёт не в зоне вашего домена, а у владельца IP-адреса, то есть у хостера или провайдера. Через панель управления доменом её не поправить, нужно обращаться туда, где выделен адрес.

Здесь PTR не проверяется, потому что она относится к отправляющему серверу, а не к домену. Её показывает проверка SMTP-сервера вместе с именем из приветствия.

A-запись и CNAME

A-запись связывает имя с IP-адресом. CNAME делает имя псевдонимом другого имени. К приёму почты напрямую они не относятся, но в настройке встречаются часто.

CNAME обычно приходит вместе с подключением сервиса рассылок: почти все просят опубликовать псевдоним на своём поддомене, чтобы подписывать письма DKIM вашего домена. Без этого DKIM будет принадлежать сервису, и DMARC его не засчитает.

Одна ошибка встречается регулярно: имя в MX-записи не должно быть CNAME. Формально это запрещено RFC 2181, Google и Microsoft такое обрабатывают, а более строгие серверы нет, и потери выглядят случайными.