Как найти причину спама: проверяем почтовые DNS-записи

Письмо может попасть в спам и при исправных DNS-записях: решение принимает получатель с учетом разных сигналов. Я покажу, как проверить PTR, SPF, DKIM и DMARC на условном примере студии «Дельта-Профиль-Мед», а затем отделить ошибку аутентификации от проблем с доставкой.

Сначала выясняю, где ломается доставка

Разберу условный случай студии «Дельта-Профиль-Мед»: счета уходят с корпоративного домена, но часть адресатов сообщает о папке «Спам» или об отказе. Из этого ещё нельзя заключить, что виноваты DNS, сервер или принимающая сторона. Письмо может пройти SPF и DKIM, но всё равно получить нежелательную оценку у конкретного сервиса; возможна и обратная ситуация — у одного адресата доставка нормальная, у другого SPF заканчивается ошибкой. Я не обещаю починить такую историю за час и не называю одну запись волшебной кнопкой. Сначала фиксирую, кому, откуда и через какой сервис отправлено письмо, а также точный текст ответа или результат проверки у получателя.

Я начинаю с исходного сообщения, заголовков и журналов отправки, а не с угадывания в панели DNS. В заголовках полезны Authentication-Results, Return-Path и DKIM-Signature: первый показывает результаты проверок конкретного принимающего сервера, Return-Path помогает увидеть домен SPF, а параметры d= и s= в DKIM-Signature указывают домен и селектор подписи. Сверяю их с адресом в From: и с фактическим сервисом, который отправил письмо. Затем сопоставляю данные с ответом SMTP или сообщением о недоставке. Иначе можно чинить запись домена, через который письмо вообще не отправлялось. Логи здесь скучнее догадок, зато обычно полезнее. Отдельно различаю SMTP-отказ, помещение в спам и ситуацию, когда получатель принял сообщение, но сотрудник не может его найти: это разные результаты и разные журналы. Сохраняю полный текст ответа или заголовки, чтобы сравнивать факты, а не пересказ «не дошло».

• Сохраните исходное письмо вместе с заголовками.
• Запишите отправляющий сервис и домен адреса From:.
• Сверьте результат аутентификации у получателя.

PTR: обратное имя должно возвращаться к адресу отправки

PTR — запись обратного DNS: по адресу отправляющего узла она возвращает имя хоста. Для почтовой отправки полезно проверить не только наличие PTR, но и обратное соответствие: имя из PTR должно разрешаться вперёд в адрес отправки. Google прямо указывает это требование для исходящих подключений к Gmail; другие получатели применяют собственные правила, поэтому отсутствие PTR не означает автоматический отказ всей почты или одинаковый штраф у всех. Важно и другое: имя хоста в PTR не обязано совпадать с доменом в видимом поле From:. Например, у сервера может быть отдельное техническое имя, тогда как сотрудники отправляют письма от имени основного домена компании. Требовать буквального равенства этих имён — неверная диагностика.

Настройку PTR обычно выполняет владелец адресного пространства — хостинг-провайдер или оператор площадки, а не администратор обычной DNS-зоны домена. Я проверяю, какой узел действительно отправляет сообщения: выделенный сервер, исходящий шлюз или инфраструктура облачной почты. Для собственного сервера прошу провайдера назначить PTR на выбранное имя хоста, а затем проверяю, что обычная запись A или AAAA этого имени возвращает адрес отправки. Если отправка идёт через облачный сервис, PTR его общей инфраструктуры находится под контролем поставщика; менять его в своей зоне нельзя. При общей платформе сначала смотрю её инструкцию и результаты Authentication-Results, а не советую менять площадку по одному отсутствующему PTR. Я также уточняю, не отправляет ли сервис письма с нескольких площадок: PTR должен соответствовать фактическому исходящему узлу, а не просто главному серверу, который указан в документации. Для облачной или общей платформы граница ответственности важна: её собственные обратные записи настраивает оператор, а администратор домена сверяет полученные сведения и доменную аутентификацию.

• Установите фактический адрес исходящего узла.
• Проверьте PTR и прямой ответ для его имени.
• Уточните у провайдера, кто управляет PTR.

SPF: одна запись и полный список отправителей

SPF описывает, каким узлам разрешено отправлять почту с определённой доменной идентичностью; проверка связана прежде всего с MAIL FROM или HELO, а не сама по себе с видимым адресом From:. Запись публикуют в TXT. Для одного имени домена должна быть одна SPF-запись с маркером v=spf1: две отдельные записи не складываются в общий список и могут дать результат permerror. При этом TXT-записей у домена может быть много для других задач — правило относится именно к SPF-записям. Перед объединением я собираю все законные источники отправки: корпоративный сервер, CRM, сайт, систему счетов, уведомления и рассылки, если они действительно используются. Пропущенный отправитель сломает собственную почту, а лишнее разрешение ослабит контроль.

После инвентаризации свожу разрешения в одну строку и проверяю каждый include у его поставщика. В RFC 7208 ограничены десять механизмов и модификаторов, которые инициируют DNS-поиск при одной проверке; превышение даёт permerror. Это не просто число слов в TXT: часть механизмов, включая include, a, mx и redirect, запускают поиск, а ip4, ip6 и all — нет. Окончания тоже означают разное: -all сообщает, что остальные узлы не разрешены, а ~all — мягкий fail. Жёсткий вариант не добавляет «доверия» автоматически. Его выбирают только после проверки всех отправителей и понимания, где именно оценивается SPF; затем отправляют тесты с каждого сервиса и убеждаются, что результат ожидаемый. Копировать строку провайдера поверх имеющейся — короткий путь к конфликту. Для каждого include записываю, кто отвечает за него и какой сервис использует это разрешение. При запуске нового отправителя или отключении старого список нужно пересмотреть и повторно пройти тесты, иначе запись постепенно перестаёт соответствовать реальному потоку почты. Это обычная инвентаризация, а не повод добавлять в SPF все найденные в интернете адреса.

• Оставьте одну SPF-запись для имени домена.
• Добавьте все законные источники отправки.
• Проверьте десять DNS-поисков при SPF-оценке.
• Выберите -all или ~all после инвентаризации.

DKIM: проверяю селектор и пару ключей

DKIM добавляет к письму подпись, которую получатель проверяет открытым ключом из DNS. В заголовке DKIM-Signature есть домен подписанта d= и селектор s=; по ним принимающая сторона ищет публичный ключ в TXT-записи. Подпись подтверждает, что проверяемые заголовки и содержимое соответствуют подписанным данным, но это не удостоверение личности человека и не обещание доставки во «Входящие». Если между подписанием и проверкой изменились подписанные части письма, проверка может не пройти. Поэтому я сверяю имя селектора из реального письма с записью в зоне и проверяю результат DKIM у получателя. Наличие любой строки с именем _domainkey ещё ничего не доказывает: важна запись именно того селектора, которым подписал отправитель. DKIM не шифрует письмо и не скрывает его содержимое: получатель сверяет подпись открытым ключом, а не расшифровывает сообщение. Если подпись не проходит, сначала выясняю, какой именно селектор запрошен и какой домен его опубликовал, а не создаю новый ключ поверх рабочей конфигурации.

При переносе почты старый ключ не становится негодным только из-за смены сервера. Нужно выяснить, продолжает ли новый отправляющий сервис использовать прежнюю пару ключей, или он создал собственный селектор и ключ. Затем публикую предоставленную им TXT-запись, дожидаюсь её появления в ответах DNS и отправляю контрольное письмо с каждого источника. Проверяю, что заголовок показывает ожидаемые d= и s=, а DKIM результат — pass. Если провайдер меняет ключ, старую запись удаляют только после перехода всех отправителей; иначе параллельно работающий старый сервис потеряет проверку. Для личных адресов Gmail нужен ключ не короче 1024 бит, Google рекомендует 2048 бит, если поставщик это поддерживает. Это конкретная рекомендация, а не повод объявлять каждую 1024-битную подпись подозрительной.

• Возьмите d= и s= из реального заголовка.
• Сверьте DNS-запись именно этого селектора.
• Проверьте письма от каждого отправителя после переноса.

DMARC: выравнивание, отчёты и аккуратная политика

DMARC связывает домен в From: с результатом SPF или DKIM. Для pass достаточно, чтобы прошёл хотя бы один механизм и его домен был выровнен с видимым доменом отправителя по выбранному режиму выравнивания. Поэтому фраза «SPF и DKIM должны оба пройти» неверна: два результата полезно смотреть отдельно, но DMARC может пройти за счёт одного из них. Политика p=none не просит получателя применять к провалившим DMARC письмам особую обработку; она нужна для наблюдения и запроса агрегированных отчётов через rua. Отчёты помогают увидеть использующие домен потоки, если принимающий сервис их отправляет. Это не полный журнал всех писем: конкретный получатель может не формировать отчёт или не отправлять его на ваш адрес. Проверяю и точные идентификаторы из заголовков: успешный SPF для одного домена ещё не означает DMARC pass, если он не выровнен с доменом From:. Такая разница часто объясняет, почему отдельная проверка показывает pass, а итоговая DMARC-оценка — fail. Смотреть нужно на итог конкретного получателя, а не только на зелёную отметку одного SPF-валидатора.

Для перехода к карантину или отказу сначала проверяю отчёты и легальные источники, включая редкие письма сайта, CRM и сканеров. Только после этого можно выставлять p=quarantine или p=reject, понимая, какие сообщения могут пострадать. Политика DMARC касается писем, которые не прошли выравнивание; она не гарантирует, что получатель положит прошедшее проверку письмо во «Входящие», и не отменяет его собственные фильтры. Актуальное описание механизма опубликовано в RFC 9989; агрегированные отчёты отдельно описывает RFC 9990. В документах нет обещания универсального срока перехода для каждой организации: масштаб отправки и качество учёта источников у всех разные. Начать с p=none проще, чем потом объяснять бухгалтерии, почему уведомления исчезли после слишком раннего p=reject.

• Опубликуйте адрес для агрегированных DMARC-отчётов.
• Сопоставьте SPF/DKIM с доменом From:.
• Включайте карантин или отказ после проверки источников.

После DNS-проверок ищу другие причины спама

После исправлений я проверяю записи у авторитетного DNS-сервера и через внешние резолверы, затем отправляю новые письма с каждого законного источника. Сохраняю полные заголовки и смотрю SPF, DKIM и DMARC именно на стороне того почтового сервиса, где возникла проблема. Если изменение ещё не видно, проверяю TTL и повторяю запрос позднее; заранее назначать универсальный срок распространения записей нельзя. Если тест проходит, а письмо всё ещё попадает в спам, DNS-аутентификация уже не единственная рабочая гипотеза. Нужно читать объяснение получателя, если оно есть, и отдельно разбирать репутацию отправляющего узла, характер отправки, отказы и содержимое письма. Один зелёный чекер не может проверить всю политику чужого почтового сервера. Если почтовая система вернула отказ, сопоставляю его с очередью отправки и журналом получателя; если сообщение приняли, но оно оказалось в спаме, беру его полные заголовки из папки назначения. Эта простая развилка помогает не исправлять DNS в ответ на проблему, которая возникла уже после проверки домена.

В условной ситуации студии «Дельта-Профиль-Мед» я бы зафиксировал результаты до и после: какой сервис отправил тест, что показал Authentication-Results, какой был ответ принимающего сервера и куда пришло письмо. Так видно, помогло ли исправление конкретной записи или причина осталась на другом участке. Повторную проверку разумно делать после смены почтовой платформы, добавления рассыльщика, переноса сайта или изменения исходящего шлюза; регулярность выбирают по темпу изменений, а не по выдуманному обязательному квартальному расписанию. Если бизнесу некому сопоставить эти данные, мы можем провести аудит и настроить аутентификацию почты. Но честный результат такой работы — корректная конфигурация и понятная диагностика, а не гарантия поведения каждого внешнего фильтра.

• Сохраните заголовки и результаты теста.
• Проверьте каждую систему, которая отправляет почту.
• Если DNS исправен, изучите ответ и репутацию отправителя.

Частые вопросы