SPF, DKIM и DMARC проходят, но письмо в спаме

Почему PASS не гарантирует входящие

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

Сначала убедитесь, какой результат вы видите

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

Текст заголовка сам по себе не доказывает достоверность записи: такое поле может подделать и отправитель (RFC 8601, раздел 7.1). Опирайтесь на поле, которое добавил принимающий сервер получателя, и учитывайте фактический путь сообщения по полям Received.

Отделите четыре наблюдения

Это порядок диагностики, а не четыре готовых диагноза. Один и тот же домен может иметь несколько независимых проблем.

Сопоставьте отправляющие домены

Зафиксируйте видимый From, домен DKIM из d= и возвратный домен (Return-Path). Успешную SPF- или DKIM-проверку нужно читать в правильном контексте: SPF проверяет возвратный домен, DKIM подтверждает подпись домена из d=, и оба могут отличаться от видимого отправителя.

Для DMARC важна связь аутентифицированного домена с видимым отправителем. DMARC засчитывает SPF или DKIM, только если их домен выровнен с доменом в From: совпадает с ним полностью при строгом выравнивании или относится к тому же организационному домену при мягком (RFC 9989, заменивший RFC 7489).

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

Восстановите последовательность изменений

Сравните периоды до и после появления симптома. Менялись ли платформа, домен подписи, источник аудитории, частота или состав сообщений? Проблема затронула один поток, одного провайдера или разные типы писем?

Полезнее проверить одно обоснованное предположение, чем одновременно заменить домен, шаблон и транспорт. При одновременных изменениях трудно понять причину результата.

Используйте показатели с их исходным смыслом

Для Google рассматривайте доступную статистику и соответствие требованиям отправителя, а не категорию репутации: в Postmaster Tools v2 и его API репутации домена и IP нет. Для Mail.ru показатель репутации из кабинета означает средний процент жалоб за последние 30 дней. Меньшее значение лучше.

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

Что делать после проверки

Зафиксируйте подтвержденные наблюдения, возможные причины и недостающие данные. Изменения DNS согласуйте с ответственным за все источники отправки.

Успешное тестовое письмо или высокая оценка тестового сервиса говорят о результате конкретной проверки, а не о восстановлении доставки всей аудитории.