Аутентификация проходит — почему письмо всё равно в спаме?

SPF, DKIM и DMARC помогают подтвердить отправителя, но не обещают письмо во «Входящих»: получатель отдельно оценивает соответствие доменов, PTR, репутацию и жалобы. Я покажу, как разбирать результаты по заголовкам и что исправлять первым — без замены ~all на -all вслепую.

Почему SPF, DKIM и DMARC не гарантируют «Входящие»

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

SPF проверяет IP-адрес для домена конверта SMTP, DKIM — криптографическую подпись и домен подписанта, а DMARC сопоставляет эти результаты с доменом в заголовке From. Провал одной проверки не равен автоматическому помещению в спам, как и успешный результат не гарантирует доставку во «Входящие». Окончательное решение зависит от правил принимающего сервиса; аутентификация — лишь часть этой картины. Поэтому фраза «в DNS всё зелёное» не закрывает расследование.

Я начинаю с одного конкретного письма, принятого внешним почтовым ящиком: открываю полные заголовки и смотрю результаты Authentication-Results, добавленные именно этим получателем. Важны SPF-результат и проверенный домен, статус DKIM и значение d=, результат DMARC и выравнивание с From. Нельзя верить одноимённой строке, которую добавил сам отправитель: до доверенного сервера заголовки могли подделать. В условной сети «Юнона» я бы сначала сохранил такой заголовок и время отправки, а уже потом менял DNS. Иначе через день будет непонятно, какое изменение что исправило.

SPF: что на самом деле означают ~all, -all и дубли

Механизм ~all возвращает softfail: домен сообщает, что отправитель, вероятно, не разрешён, но владелец домена не делает такого же строгого заявления, как при -all. Это разные результаты политики SPF, а не оценка «слабой» или «сильной» репутации. RFC прямо говорит, что получатель не должен отклонять письмо только из-за softfail, хотя может проверить его внимательнее. Значит, заменить тильду на минус ради «доставляемости» — не лечение, а смена смысла записи.

-all уместен, когда вы учли все источники отправки: рабочую почту, сайт, бухгалтерские уведомления, CRM и сторонние рассылки. Если забытый сервис отправляет от имени домена, он окажется за пределами списка. Это может стать причиной SPF fail, а дальше решение примет почтовая система адресата. Я сначала собираю фактические источники из журналов и отчётов, затем проверяю, каким доменом пользуется каждый поток. Только после этого выбираю квалификатор. В примере с условной «Юноной» наличие ~all само по себе не доказывает, что оно вызвало спам: нужна строка результата из заголовка и сравнение до и после.

Для одного доменного имени публикуют одну SPF-политику в одной TXT-записи. Если получатель находит несколько записей с v=spf1 для того же имени, стандарт предписывает результат permerror: сервер не выбирает «подходящую» строку за администратора. У поддомена может быть собственная политика, потому что это отдельное имя; его запись не надо склеивать с записью корневого домена. Дубликаты устраняют, сведя разрешённые источники в одну корректную запись для конкретного имени.

Есть и менее заметный предел: при одной проверке SPF учитывается не более десяти механизмов и модификаторов, которые вызывают DNS-запросы; к ним относятся include, a, mx, ptr, exists и redirect. Превышение даёт permerror даже тогда, когда запись на глаз выглядит аккуратно. Поэтому длинную цепочку include нужно считать по фактическим DNS-переходам, а не по числу слов в исходной строке. Механизм ptr для новых SPF-политик RFC отдельно не рекомендует; если подрядчик предлагает добавить его «для надёжности», попросите объяснить, какую задачу он решает.

• Проверьте, сколько записей v=spf1 опубликовано для каждого имени.
• Сверьте MAIL FROM и HELO с ожидаемым источником.
• Разберите цепочки include и лимит DNS-запросов.
• Не меняйте ~all на -all до инвентаризации отправителей.

DKIM: подпись, селектор и ротация без мифов об истечении

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

В заголовке DKIM-Signature параметр d= указывает домен подписанта, а s= — селектор, который помогает найти соответствующий публичный ключ в DNS. Поэтому проверять надо именно пару домен плюс селектор из конкретного сообщения, а не просто наличие какой-нибудь DKIM TXT-записи. Если от имени компании отправляет несколько систем, у них могут быть отдельные селекторы или подписи; главное, чтобы поток, который должен проходить DMARC, имел выровненный домен подписи.

У DKIM-ключа нет обязательного срока истечения, который администратор должен «продлить» раз в несколько месяцев. В стандарте есть необязательный срок x= для самой подписи письма, и по умолчанию срок не задан. Ротация ключей остаётся операционной мерой: новый селектор позволяет опубликовать новый ключ и переключить подпись, а старый ключ отозвать после согласованного перехода. Ротировать следует по политике безопасности, при компрометации ключа или изменении поставщика, а не потому, что календарь сам внезапно запретит DKIM.

Для условной сети «Юнона» я бы проверил каждую исходящую систему отдельно: какой селектор она использует, какой открытый ключ видит DNS и остаётся ли подпись валидной после почтовых шлюзов и пересылки. Если результат DKIM — fail, сравниваю заголовок подписи и опубликованный ключ, а не меняю DMARC на reject. Разбор отдельного симптома описан в статье DKIM не подписывает письма.

• Сверьте d= и s= в заголовке письма.
• Проверьте публичный ключ для найденного селектора.
• Подтвердите подпись после каждого пути отправки.
• Планируйте ротацию как управляемый переход.

PTR: проверьте прямое и обратное разрешение имени

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

Google, например, требует для отправляющих доменов или IP корректные прямые и обратные DNS-записи. В справке Gmail указано, что отсутствие PTR или несовпадение при обратной прямой проверке может привести к ограничению скорости либо блокировке сообщения. Это конкретное требование Gmail, а не универсальная формула для всех адресатов. Если сервер размещён у провайдера, который управляет адресным блоком, PTR обычно меняет именно он; в панели домена отправителя может просто не быть такой настройки.

Я проверяю адрес, с которого фактически установилось SMTP-соединение с внешним получателем, затем сверяю имя из PTR с прямой записью этого имени. Важен внешний маршрут после NAT или исходящего шлюза: внутренний адрес почтового сервера может не совпадать с публичным IP, который видит получатель. В условном кейсе «Юноны» запись следует запросить у владельца внешнего IP и после обновления повторить отправку на тестовый ящик. Если PTR исправен, но письмо всё равно отклоняется, не надо бесконечно переставлять DNS — пора изучить ответ сервера и соседние проверки.

Указанный адрес может принадлежать облачному почтовому поставщику, и тогда клиент не управляет его PTR. В таком случае смотрю на заголовки полученного письма и документированные требования самого поставщика, а не пытаюсь выставить чужую обратную зону самостоятельно. Это простая граница ответственности, но она экономит часы переписки с DNS-панелью.

DMARC: выравнивание и реальный смысл p=none

DMARC проверяет не просто наличие SPF и DKIM. Для результата DMARC pass хотя бы один механизм должен успешно пройти аутентификацию и быть выровнен с доменом в видимом заголовке From. SPF pass для другого домена или валидная DKIM-подпись с чужим d= сами по себе такого результата не дают. В этом месте часто скрыта причина: по отдельности проверки зелёные, а домены отправителя и подписи не совпали. Именно поэтому я смотрю Authentication-Results целиком, а не на три значка в онлайн-проверке.

Политика p=none не просит получателя менять обращение с письмом на основании DMARC. Но это не отключает сами проверки SPF и DKIM и не означает, что письмо обязательно примут: другие фильтры продолжают работать. Для полезной диагностики укажите rua с адресом для агрегированных отчётов и убедитесь, что отчёты действительно приходят. Без rua вы не получите агрегированную картину отправляющих систем через этот механизм; одна запись p=none не создаёт волшебную панель мониторинга.

В актуальном RFC 9989 для первоначального сбора данных обычно предлагается начать с p=none и rua, чтобы обнаружить пропущенные серверы и сторонние отправки. Я сначала раскладываю отчёты по источнику, домену SPF, домену DKIM и выравниванию, затем связываю неизвестный поток с ответственным сервисом. Только когда легитимные отправители понятны и исправлены, обсуждаю с владельцем домена p=quarantine или p=reject. Переход — управленческое решение о том, что получатель должен делать с письмами, которые не проходят DMARC; это не кнопка «доставлять лучше».

В отчёте DMARC могут быть полезные сведения о результатах и количестве сообщений по источникам. Я не называю каждый неизвестный источник атакой: это может быть старый сайт, забытая рассылка или неправильно настроенная переадресация. Отчёт помогает составить список для разбора, но сам по себе не доказывает намерение отправителя. Отдельно о проблеме, когда жёсткая политика влияет на легитимную почту, — в статье почему p=reject мешает доставке.

• Сверьте домен From с SPF и d= подписи DKIM.
• Настройте rua и проверьте получение агрегированных отчётов.
• Разберите каждый легитимный источник до усиления политики.
• Согласуйте карантин или отклонение после наблюдения.

Если все проверки прошли, исследуйте репутацию и поток

Когда SPF, DKIM и DMARC проходят, а письмо остаётся в спаме, я переключаюсь с DNS на факторы отправки: жалобы получателей, внезапный рост объёма, качество адресной базы и репутацию IP и домена. В правилах Gmail для отправителей указано держать долю жалоб на спам, видимую в Postmaster Tools, ниже 0,3 %. Это порог из рекомендаций Google для его получателей, а не универсальная граница, после которой любой другой почтовый сервис обязан принять письмо.

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

Порядок действий у меня такой: зафиксировать письмо, его время и адресата; проверить SPF, DKIM, DMARC и PTR именно для фактического исходящего пути; сопоставить результаты с SMTP-ответом; затем проверить репутационные сигналы и историю отправок. Если найден конкретный отказ SPF или DKIM, исправляю соответствующий источник. Если все аутентификационные результаты и выравнивание корректны, не придумываю DNS-ошибку — уточняю правила получателя, частоту отправки и жалобы. Так появляется проверяемая причина, а не очередной круг замен ~all на -all.

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

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