Письма клиента уходят в спам: как ломаются SPF, DKIM и DMARC

29 сентября 2026 · 7 мин чтения

Самый неприятный сбой в поддержке сайта — тот, который не выглядит сбоем. Сайт открывается, мониторинг зелёный, форма отправляется и показывает «спасибо». А письма с заявками лежат у получателя в спаме, и узнаёте вы об этом через две недели, когда клиент спрашивает, почему в CRM пусто.

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

Три записи, от которых зависит, дойдёт ли письмо

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

SPF (v=spf1 в TXT-записи домена) отвечает на вопрос «кому вообще разрешено отправлять письма от имени этого домена». Это список серверов и сервисов.

DKIM (TXT-запись вида селектор._domainkey.домен) — криптографическая подпись. Отправляющий сервер подписывает письмо приватным ключом, получатель проверяет подпись публичным из DNS. Подпись доказывает, что письмо не подменили по дороге.

DMARC (TXT-запись _dmarc.домен) связывает первые два и говорит получателю, что делать с письмом, которое проверку не прошло: ничего (p=none), положить в спам (p=quarantine) или отвергнуть (p=reject).

Важное про доменную привязку: SPF и DKIM могут пройти, а DMARC всё равно упасть. DMARC требует, чтобы домен, прошедший проверку, совпадал с домином в поле From. Отправка «от вашего домена» через сервис, подписывающий своим, этой проверки не проходит. Это самая частая причина недоумения «но у меня же всё настроено».

Как это ломается на практике

Две записи SPF вместо одной

По стандарту RFC 7208 у домена должна быть ровно одна запись, начинающаяся с v=spf1. Если их две, результат проверки — permerror, и это не «одна из двух сработает», а «SPF не проходит вообще».

Сценарий появления банален. У домена уже есть SPF для корпоративной почты. Подключают сервис рассылок, тот в инструкции просит добавить запись — и исполнитель добавляет вторую, вместо того чтобы дописать include: в существующую. Обе записи выглядят правильными по отдельности. Почта ломается целиком.

Превышение лимита в десять DNS-запросов

Это самая коварная поломка, потому что запись остаётся синтаксически верной.

Стандарт разрешает при проверке SPF не более десяти механизмов, требующих обращения к DNS: include, a, mx, ptr, exists, redirect. И лимит считается рекурсивно: если ваш include:_spf.example.com внутри себя содержит ещё три include, вы израсходовали четыре запроса, а не один.

Выглядит это так:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mandrillapp.com
       include:_spf.crm-service.ru include:mail.hosting.ru ~all

Пять include в записи. Но внутри _spf.google.com их ещё три, внутри sendgrid.net — два. Итого одиннадцать при лимите десять, и SPF не проходит ни для одного отправителя, включая тот, что работал годами.

Механизмы ip4: и ip6: в лимит не входят — в них нет обращения к DNS. Поэтому правильный способ уместиться: заменить часть include на конкретные диапазоны адресов, если сервис их публикует.

Открытая запись +all

v=spf1 +all означает «отправлять от моего домена разрешено кому угодно». Встречается как след отладки: кто-то поставил, чтобы «просто заработало», и забыл убрать. Это прямое приглашение к подделке писем от имени домена.

Отсутствие DMARC

Формально это не поломка — домен без DMARC работал десятилетиями. Но с 2024 года Gmail и Yahoo требуют DMARC от массовых отправителей, а без политики любой может рассылать письма от имени вашего домена, и получатель не поймёт, что они поддельные.

Отдельно стоит понимать разницу между политиками. p=none — это «присылайте мне отчёты, но пропускайте всё». Такая запись есть, DMARC формально настроен, а подделку писем она не останавливает.

Пустой ключ DKIM

Запись вида v=DKIM1; p= формально существует, но публичного ключа в ней нет. По RFC 6376 пустой p= означает, что ключ отозван или не опубликован. То есть селектор виден, а подписи не будет.

Мы наткнулись на это, когда проверяли собственную реализацию: домен example.com отдаёт v=DKIM1; p= на любой запрошенный селектор. Первая версия нашей проверки честно «нашла» у него все четырнадцать типовых селекторов сразу.

Почему проверка доставки этого не видит

Логичный способ проверять почту — отправить письмо и убедиться, что оно дошло. Мы так и делаем: есть проверка, которая отправляет форму с уникальным маркером и ждёт письмо с этим маркером в контрольном ящике.

Только испорченный SPF письма не теряет. Он уводит их в спам. Письмо доходит, маркер находится, проверка доставки говорит «всё хорошо» — и она не врёт, письмо действительно дошло. В папку, куда никто не смотрит.

Отсюда вывод: сквозная проверка доставки и контроль DNS-записей — это две разные проверки, и одна другую не заменяет. Первая отвечает «дошло ли», вторая — «дойдёт ли в инбокс».

Что проверять: регламент

Проверку почтовых записей стоит делать при приёме сайта на поддержку, после любых работ с DNS и периодически — раз в сутки достаточно, записи меняются руками и редко.

Наличие MX. Нет MX-записей — домен вообще не принимает почту. Звучит очевидно, но регулярно встречается на доменах, где почту «вот-вот настроят».

Ровно одна запись SPF. Команда для быстрой проверки:

dig +short TXT example.ru | grep "v=spf1"

Вернулось две строки — это авария, даже если обе выглядят правильно.

Число DNS-запросов в SPF. Считать надо с раскрытием вложенных include. Руками это муторно, и именно поэтому поломка живёт месяцами: никто не пересчитывает лимит после добавления очередного сервиса.

Терминатор. Запись должна заканчиваться -all (жёстко отвергать) или ~all (мягко помечать). Исключение: если запись использует redirect=, терминатор берётся из целевой записи, и придираться к его отсутствию не нужно.

Наличие DMARC и политика. dig +short TXT _dmarc.example.ru. Если политика p=none, отметьте это как задачу, а не как норму.

Селекторы DKIM. Здесь есть неустранимая сложность: селектор нигде в DNS не перечислен. Узнать его снаружи можно только угадыванием по типовым именам (default, mail, google, selector1, selector2, k1, s1) либо взять из настроек почтового сервиса. Если селектор известен — проверяйте именно его, и отсутствие записи считайте поломкой.

Что изменилось в Pingvera

Мы добавили отдельный тип проверки — «Почтовые записи (SPF/DMARC/DKIM)». Она не отправляет писем и не требует доступа к почте: читает DNS домена и проверяет то, что перечислено выше.

Проверка сообщает о поломке, когда поломка объективна: нет MX, нет SPF, записей SPF больше одной, превышен лимит DNS-запросов, стоит +all, отсутствует DMARC, заданный явно селектор DKIM не найден. Лимит запросов считается с раскрытием вложенных include — то есть именно так, как его будет считать почтовый сервер получателя.

Отпечаток записей — сколько MX, сколько из десяти запросов израсходовано, какая политика DMARC, какие селекторы найдены — виден и на здоровой проверке. Это сделано намеренно: когда подрядчик поправит SPF, изменение будет видно в истории проверок, даже если новая запись не сломала лимит.

Полезный побочный эффект: первый же прогон на нашем собственном домене показал, что у pingvera.ru нет DMARC-записи. Проверка начала с того, что нашла недочёт у авторов.

Коротко

• SPF, DKIM и DMARC ломаются тихо: сайт работает, форма отправляется, письма уходят в спам.
• Две записи SPF — это permerror, а не «одна из двух сработает».
• Лимит десять DNS-запросов считается рекурсивно и превышается незаметно, при подключении очередного сервиса рассылок.
• Проверка доставки письма и контроль DNS-записей — разные проверки: испорченный SPF письма не теряет, а уводит в спам.
• Проверять стоит при приёме сайта, после любых работ с DNS и затем ежедневно.