Письма попадают в спам: чек-лист проверки DNS

Когда легитимные письма попадают в спам, причина одна из двух: аутентификация (получатель не может убедиться, что почта действительно идёт от вашего домена) или репутация (убедиться может, и увиденное ему не нравится). DNS исправляет первое. Второе он не исправит, но пока не в порядке первое, всё остальное, что вы делаете, не засчитывается.

Этот чек-лист проходит по DNS-части в том порядке, в каком проблемы находятся быстрее всего. Сами понятия объяснены в статье MX, SPF, DKIM и DMARC: как они работают вместе; здесь только практика.

Шаг 0. Прочитайте заголовки письма, которое попало в спам

Не гадайте. Отправьте письмо на свой ящик у того провайдера, где возникает проблема, откройте его и выберите «показать оригинал» или «исходный текст». Найдите заголовок Authentication-Results, который добавил получатель:

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=bounces.mailer.example;
   dkim=pass header.d=mailer.example header.s=s1;
   dmarc=fail (p=NONE) header.from=example.com

Одна эта строка сообщает почти всё, что нужно:

Поле	На какой вопрос отвечает
`spf=` и `smtp.mailfrom=`	Подошёл ли IP отправителя под SPF-запись домена конверта и какой это был домен?
`dkim=` и `header.d=`	Была ли действительная подпись и для какого домена?
`dmarc=` и `header.from=`	Прошёл ли SPF или DKIM для того домена, который видит получатель?

В примере всё «проходит», а DMARC всё равно провален: SPF и DKIM пройдены для доменов сервиса рассылок, а не для example.com. Это самая частая находка, и ей посвящён шаг 4.

Заодно запишите IP-адрес отправителя из самой верхней строки Received:, добавленной получателем: он понадобится на шаге 5.

Шаг 1. Перечислите всё, что отправляет почту от имени вашего домена

Чаще всего аутентификация не проходит у отправителя, о котором никто не вспомнил: почтовый провайдер, сервис рассылок, CRM, система выставления счетов, служба поддержки, форма обратной связи на сайте, офисный сканер, оповещения мониторинга. Запишите их. Каждый должен быть охвачен SPF или DKIM, а лучше и тем и другим.

Шаг 2. SPF

$ dig +short example.com TXT | grep spf1
"v=spf1 include:_spf.mailprovider.example include:spf.mailer.example -all"

Проверьте:

Ровно одна запись, начинающаяся с v=spf1. Две записи — это постоянная ошибка (permerror), и результат такой же, как если бы записи не было.
Каждый отправитель из шага 1 охвачен через include:, ip4: или ip6:.
Всего не больше 10 DNS-запросов. Считаются include, a, mx, exists и redirect, причём include вкладываются друг в друга. Превышение лимита — тоже permerror. Прежде чем хвататься за «уплощение SPF» (flattening), уберите сервисы, которыми больше не пользуетесь.
В конце стоит ~all или -all. +all разрешает отправку всему интернету; ?all не говорит ничего.
Нет механизма ptr. Он медленный, ненадёжный, и сама спецификация SPF не рекомендует его использовать.
У поддоменов, с которых уходит почта (news.example.com), есть собственная SPF-запись. SPF не наследуется.

Помните, что именно проверяет SPF: отправителя конверта (Return-Path), а не заголовок From. Если сервис использует собственный домен для возвратов, SPF проходит для его домена и вашему результату DMARC не помогает, пока вы не настроите собственный return-path.

Шаг 3. DKIM

Возьмите селектор (s=) и домен (d=) из заголовка DKIM-Signature настоящего письма и запросите ключ:

$ dig +short s1._domainkey.example.com TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Запись существует и содержит значение p=. Пустое p= означает, что ключ отозван.
Длинные ключи разбиты на несколько строк в кавычках, без случайных пробелов и переводов строки, которые вставила панель управления.
Длина ключа — 2048 бит, если провайдер это позволяет; 1024 — минимум, который принимают получатели.
Если провайдер просил записи CNAME вместо TXT, они на месте и ваш DNS-провайдер их не «уплощает» и не проксирует.
В d= стоит ваш домен, а не домен провайдера. Большинство сервисов подписывают собственным доменом, пока вы не пройдёте у них настройку «подтвердите свой домен». Только после этого DKIM засчитывается для DMARC.
У каждого отправляющего сервиса свой селектор.

Перечислить DKIM-селекторы домена снаружи невозможно. Их находят в заголовках писем или в настройках провайдера.

Шаг 4. DMARC и выравнивание

$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Одна запись на имени _dmarc.example.com, начинается с v=DMARC1, значение p= допустимое.
Адрес в rua=, который кто-то или что-то действительно читает. Если он находится на другом домене, этот домен должен опубликовать разрешающую запись.
У каждого отправителя хотя бы одна из проверок, SPF или DKIM, проходит с доменом, совпадающим с доменом From (в нестрогом режиме по умолчанию достаточно одного и того же организационного домена).

С февраля 2024 года Gmail и Yahoo требуют SPF, DKIM и запись DMARC (хотя бы p=none) с выравниванием от всех, кто отправляет их пользователям примерно 5000 и более писем в день, а кроме того отписку в один клик для маркетинговых писем и низкую долю жалоб. Другие крупные провайдеры объявили о похожих правилах. Небольшим отправителям нужен как минимум SPF или DKIM, а на практике их оценивают по тем же меркам.

p=none даёт отчёты и закрывает минимальное требование. От подделки домен он не защищает. Переходите на quarantine и reject, как только отчёты покажут, что у всех легитимных источников есть выравнивание.

Шаг 5. Отправляющий сервер: обратный DNS и HELO

Имеет смысл, только если почтовый сервер вы держите сами. С IP-адресом из шага 0:

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com
192.0.2.25

PTR-запись существует, и это не типовое имя, выданное провайдером по умолчанию.
Имя разрешается обратно в тот же IP.
Сервер представляется тем же именем в EHLO.
Если у сервера есть IPv6, то же верно и для этого адреса, либо исходящая почта ограничена IPv4.

Подробности в глоссарии: обратный DNS.

Шаг 6. MX и сам домен

У домена есть рабочие записи MX, указывающие на имена хостов (не на IP и не на CNAME), которые принимают почту. Получатели не доверяют отправителям, неспособным принять возвраты и ответы.
Письма на postmaster@ и abuse@ доходят до человека.
Домены, с которых почта не уходит никогда, прямо об этом говорят: v=spf1 -all, null MX (0 .) и v=DMARC1; p=reject. Припаркованные домены — излюбленная мишень для подделки.

Шаг 7. TLS

Исходящая почта использует STARTTLS. Gmail помечает незашифрованные письма красным замком, а правила для массовых отправителей требуют TLS.
Ваш собственный MX предлагает STARTTLS с сертификатом, срок действия которого не истёк:

$ openssl s_client -connect mail.example.com:25 -starttls smtp </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate

Шаг 8. Чёрные списки и репутация

Проверьте отправляющий IP и домен на собственных страницах проверки крупных операторов чёрных списков. Попадание в малоизвестный список редко что-то значит, в широко используемый — значит. Сначала устраните причину (взломанная учётная запись, открытая форма, купленная база адресов) и только потом просите об исключении.
Зарегистрируйте домен в постмастер-сервисах, которые предлагают крупные почтовые провайдеры. Они показывают, каким эти провайдеры видят ваш домен: доля жалоб на спам, результаты аутентификации, репутация.

Когда DNS в порядке, а письма всё равно уходят в спам

Тогда дело в репутации или содержании, и никакая запись не поможет:

новый домен или новый IP, с которых с первого дня идёт большой объём без прогрева;
получатели, которые писем не просили и жалуются;
старые базы с множеством мёртвых адресов;
сокращатели ссылок, ссылки на домены с плохой репутацией, письма из одной картинки;
домен в From, который отличается от домена в ссылках и от домена в подписи;
на общих IP-адресах — поведение других клиентов.

DNS добивается того, чтобы вас оценивали как вас самих. Что будет дальше, зависит от того, что вы отправляете.

Частые ошибки

Добавить для нового сервиса вторую SPF-запись, вместо того чтобы дополнить существующую.
Увидеть spf=pass и dkim=pass и на этом остановиться, не проверив, для какого домена они пройдены.
Перескочить на p=reject, не читая отчётов, и потерять счета, которые отправляла забытая система.
Тестировать только со своего ящика на свой же ящик у того же провайдера.
Ждать, что изменения подействуют мгновенно: записи SPF и DMARC кэшируются на время своего TTL.

Проверьте в OrbitProbe

Проверка MX-записей в OrbitProbe показывает MX-хосты домена и их приоритеты, вероятного почтового провайдера, а также записи SPF и DMARC с замечаниями о типичных ошибках настройки. Перечислить DKIM-селекторы она не может, потому что снаружи этого не может никто: проверяйте их по заголовку письма, как описано в шаге 3. Запускайте проверку именно для того домена, который стоит у вас в адресе From, и ещё раз для каждого поддомена, с которого уходит почта. Общие правила для MX и TXT собраны в статье типы DNS-записей.