Defaults.Exposed › Исправления › Guides

DMARC не проходит, а SPF и DKIM проходят? Исправление выравнивания (2026)

Опубликовано 2026-07-08

Показатели по состоянию на 2026-06-29 · методология v7. Агрегированные данные переписи по 261 млн оценённых доменов. См. как мы выставляем оценки.

DMARC нужно больше, чем прохождение: домен, прошедший SPF или DKIM, должен совпадать с вашим доменом From. Большинство писем «SPF pass, DMARC fail» прошли SPF на bounce-домене вендора, а не на вашем. Лишь 7,4% из 261 086 232 оценённых доменов проходят SPF с выравниванием при принудительной политике DMARC — по данным переписи Defaults.Exposed (2026-06-29).

Исправление быстрее, чем предполагает путаница. Прочитайте заголовок Authentication-Results, чтобы увидеть, какая опора — SPF или DKIM — проходит на чужом домене; затем либо включите у отправляющего сервиса DKIM-подписывание собственным доменом (обычно несколько CNAME — исправление, переживающее пересылку), либо настройте его пользовательский обратный адрес, чтобы SPF проходил на вашем домене. DMARC достаточно одной выровненной опоры.

Как DMARC может не проходить, когда SPF и DKIM оба проходят?

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

Каждая проверка аутентифицирует свой домен:

Вот как всё обычно идёт не так: ваша платформа рассылок или CRM отправляет с Return-Path вида [email protected], SPF проверяется по vendor.com и проходит, DKIM проходит с d=vendor.com — а DMARC не проходит, потому что ни один прошедший домен не совпадает с yourcompany.com. Каждая проверка сказала правду; ни одна не аутентифицировала вас. Правка вашей собственной SPF-записи этого не исправит — к ней вообще никто не обращался. Это та же ловушка, что разобрана в руководстве SPF не проходит у ваших SaaS-инструментов.

Перепись показывает, как мало отправителей доводят этот последний шаг до конца: у 27 640 987 из 261 086 232 оценённых доменов (10,59%) вообще есть принудительная политика DMARC, и лишь 7,4% проходят SPF с выравниванием при такой политике. Среди 77,5 млн доменов, чей SPF оканчивается на softfail (~all), лишь 9,2% находятся под принудительной политикой DMARC; среди публикующих hardfail (-all) у 12 142 351 политика принудительная, а у 42 514 532 — нет. Большинство доменов останавливаются на «SPF проходит» — что без DMARC, действующего на его основе, не защищает почти ничего.

Как прочитать Authentication-Results и увидеть, какая опора не выровнена?

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

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Читайте его как три сравнения:

• Опора SPF: оканчивается ли smtp.mailfrom= вашим доменом? Здесь это bounces.espmail.net — не выровнено.
• Опора DKIM: оканчивается ли header.d= вашим доменом? Здесь это espmail.net — не выровнено.
• Вердикт DMARC: header.from= — домен, который защищает DMARC. Ни одна опора с ним не совпала, поэтому dmarc=fail — хотя обе отдельные проверки говорят pass.

Чинить нужно ту опору, которая уже задействует ваш собственный домен (или может быть на него переведена). Достаточно одной.

В чём разница между нестрогим и строгим выравниванием?

DMARC предлагает два режима сопоставления, задаваемые тегами aspf (SPF) и adkim (DKIM) в вашей записи DMARC:

• Нестрогий (r, по умолчанию): два домена должны иметь один и тот же организационный домен — регистрируемый домен по Public Suffix List. bounce.yourcompany.com выравнивается с yourcompany.com; как и DKIM с d=mail.yourcompany.com. Именно поэтому работают пользовательские обратные адреса вендоров и пользовательский DKIM, живущие на поддоменах.
• Строгий (s): домены должны совпадать в точности, символ в символ. bounce.yourcompany.com больше не выравнивается с yourcompany.com.

Если в вашей записи нет aspf или adkim, вы в нестрогом режиме — и почти наверняка вам стоит в нём и остаться. Строгий режим не добавляет большинству отправителей осмысленной безопасности и молча ломает каждого легитимного отправителя на поддомене, которого вы настроили. Если DMARC не проходит и в вашей записи есть aspf=s или adkim=s, одного этого может быть достаточно для бага.

Как исправить выравнивание DMARC?

1. Запустите бесплатное сканирование на defaults.exposed, прежде чем трогать DNS. Оно показывает вашу запись DMARC и политику, настроены ли ваши SPF и DKIM на выравнивание и что ещё сломано — чтобы вы сначала чинили нужную опору.
2. Протестируйте каждый отправляющий сервис и прочитайте его Authentication-Results (как выше). Перечислите все источники — почтовый провайдер, сервис рассылок, CRM, приложение для выставления счетов — и по каждому отметьте, чьи домены в smtp.mailfrom и header.d — ваши или вендора.
3. Включите у каждого вендора DKIM-подписывание собственным доменом — исправление, которое остаётся надолго. Каждый серьёзный отправляющий сервис предлагает «аутентификацию домена»: несколько CNAME-записей, позволяющих ему подписывать как d=yourcompany.com (или поддомен, который выравнивается в нестрогом режиме). Выровненный DKIM обычно проще в настройке и единственный переживает пересылку, потому что пересылка ломает SPF по самой своей природе.
4. Для выравнивания SPF включите пользовательский обратный адрес вендора (часто называется пользовательским bounce-доменом) — как правило, один CNAME вида bounce.yourcompany.com, указывающий на вендора. Тогда SPF проходит на вашем организационном домене и выравнивается. Делайте это там, где предлагается, но рассматривайте как вторую опору, а не замену выровненному DKIM.
5. Оставьте выравнивание в нестрогом режиме, если у вас нет конкретной, осознанной причины для aspf=s/adkim=s.
6. Пересканируйте, подтвердите обе опоры и двигайтесь к принудительному применению. Политика DMARC p=none отчитывается, но ничего не блокирует; когда ваши реальные отправители выровнены, полный путь к политике, которая вас защищает, — на странице исправить DMARC, а пошаговые руководства для провайдеров вроде DMARC на IONOS разбирают клики в DNS-панели.

Что чинить — выравнивание SPF или выравнивание DKIM?

Вам нужна одна выровненная опора на каждый источник отправки. Если можно сделать только одно, выбор очевиден:

Особый случай, о котором стоит знать: Google Workspace и Microsoft 365 по умолчанию подписывают вашу почту DKIM своими резервными доменами (gappssmtp.com, onmicrosoft.com) — так что DKIM показывает pass, а DMARC всё равно не проходит. Это самый распространённый конкретный частный случай всей этой проблемы, и у него есть собственное руководство: DKIM проходит, а DMARC всё равно нет: ловушка подписи по умолчанию.

Часто задаваемые вопросы

Должны ли и SPF, и DKIM выравниваться, чтобы DMARC прошёл? Нет — достаточно одного выровненного прохождения. Лучшая практика — всё же выровнять оба, чтобы когда пересылка сломает опору SPF, опора DKIM всё равно обеспечила прохождение DMARC. Из 261 086 232 доменов, оценённых в переписи 2026-06-29, лишь 3,87% имеют полную триаду SPF + DMARC + DKIM.

Панель моего ESP говорит, что SPF и DKIM «verified» — почему DMARC всё равно не проходит? «Verified» обычно означает, что собственная отправка вендора проходит на доменах вендора. Пока вы не выполнили их шаги для собственного домена (DKIM CNAME, пользовательский return-path), почта аутентифицируется как вендор, а не как вы — а DMARC сравнивает с вашим доменом From.

Достаточно ли строгой SPF-записи -all без выравнивания? Нет. Строгий квалификатор усиливает вердикт SPF по домену Return-Path, но DMARC всё равно требует, чтобы этот домен был вашим. По данным переписи 2026-06-29, лишь 12 142 351 доменов, публикующих -all, находятся под принудительной политикой DMARC — у остальных 42 514 532 строгая запись, на которую не действует никакая политика.

Стоит ли перейти на строгое выравнивание (aspf=s/adkim=s) для большей безопасности? Почти никогда. Нестрогое выравнивание уже требует того же регистрируемого домена, которым спуфер не управляет. Строгий режим в основном ломает ваших собственных отправителей на поддоменах — проверяйте его всякий раз, когда выравнивание неожиданно перестаёт работать.

DMARC не проходит только на письмах, которые получатели пересылают, — то же исправление? Это опора SPF гибнет в пути: сервер пересыльщика не значится ни в чьей SPF-записи для вашего return-path. Починить SPF для пересланной почты нельзя; ответ — выровненный DKIM, поскольку подпись переживает пересылку нетронутой. Подробности в руководстве пересланная почта не проходит SPF.

Отправьте владельцу отчёт

Если вы исправляете это для клиента или работодателя, завершите работу доказательством. Когда CNAME заработают, повторно запустите бесплатное сканирование и перешлите владельцу бизнеса отчёт с оценкой: датированный, написанный простым языком, показывающий, что SPF, DKIM и DMARC выровнены и проходят. Это документ, который понадобится ему для продления киберстраховки и следующей анкеты безопасности от поставщика, — доказательство работающей конфигурации, а не просто «я добавил какие-то DNS-записи».

Проверьте свой домен → · DKIM проходит, а DMARC всё равно нет → · Исправить DMARC → · Как мы выставляем оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.