DMARC не проходит, хотя SPF и DKIM проходят

Коротко

• DMARC проходит, только если SPF или DKIM проходит для домена из вашего адреса From. Результат pass для домена вашего провайдера не считается.
• Откройте отправленное письмо в Gmail через Show original и сравните smtp.mailfrom, header.i и header.from в заголовке Authentication-Results.
• Сначала исправьте DKIM: включите подпись собственным доменом в каждом сервисе, который отправляет письма от вашего имени. Подпись DKIM переживает пересылку, SPF нет.
• Поддомен по умолчанию считается достаточно близким. Если в вашей записи DMARC есть adkim=s или aspf=s, это уже не так.
• Прогрев не исправляет несоответствие доменов. Письма для прогрева отправляются через ваш ящик и не проходят проверку вместе с ним.

DMARC не спрашивает, прошли ли SPF и DKIM. Он спрашивает, прошла ли хотя бы одна из этих проверок для домена из вашего адреса From. Если SPF прошёл для домена возвратов вашего провайдера, а DKIM для домена подписи вашего провайдера, в обеих строках стоит «pass», а DMARC всё равно показывает «fail». Исправляется это у отправителя: пусть он подписывает письма вашим доменом или использует адрес для возвратов в вашем домене. Достаточно одного из двух.

Такое совпадение называется соответствием доменов (alignment). Это та часть DMARC, которую не видит проверка DNS. Соответствуют ли домены в ваших письмах, видно только по сообщению, которое действительно было отправлено. На этой странице показано, как такое сообщение прочитать.

С каждым письмом путешествуют три домена

Ваш домен может стоять в письме в трёх местах. Каждая проверка смотрит на своё.

SPF (RFC 7208) и DKIM (RFC 6376) отвечают каждый на свой узкий вопрос, и ни в одном из этих вопросов ваша строка From не упоминается. Сервис рассылок может пройти SPF для собственного домена возвратов и подписать письмо собственным ключом, а сообщение при этом будет утверждать, что пришло от вас. DMARC закрывает этот пробел. RFC 9989, стандарт DMARC с мая 2026 года, принимает результат, только если стоящий за ним домен соответствует домену From, и объясняет причину для DKIM одной фразой:

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

То же верно и для SPF, ведь опубликовать запись SPF для своего домена может кто угодно. Отсюда правило: DMARC проходит, если SPF проходит и его домен соответствует, или если DKIM проходит и его домен соответствует.

Найдите несовпадение в одном настоящем письме

Вам нужно одно письмо, отправленное так же, как ваша настоящая почта, и адрес Gmail, на который его можно получить.

1. Отправьте сообщение из нужного ящика или сервиса на адрес Gmail, который вы можете открыть.
2. Откройте его в Gmail на компьютере. Рядом с кнопкой Reply (Ответить) нажмите More (Ещё), затем Show original (Показать оригинал). Google описывает те же шаги в статье о том, как отследить письмо по полному заголовку.
3. Найдите заголовок Authentication-Results, в котором принимающий сервер записывает итог своих проверок (RFC 8601). Сравните три значения: домен после smtp.mailfrom=, домен после header.i=@ (некоторые получатели пишут header.d=) и домен после header.from=. Руководство как читать заголовки письма разбирает эту строку шаг за шагом.

Так выглядит письмо, которое проходит SPF и DKIM и не проходит DMARC. Заголовок сокращён, домены в нём условные:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Читайте снизу. Домен From здесь example.com. SPF прошёл, но для send.vendor-mail.example. DKIM прошёл, но подпись принадлежит vendor-mail.example. Ни тот, ни другой не равен example.com, поэтому за имя в строке From никто не ручается.

После того как сервис настроен подписывать вашим доменом, то же сообщение выглядит так:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF по-прежнему указывает на поставщика. Это нормально. DKIM теперь совпадает, а DMARC хватает одного результата pass с соответствием домена.

Какое совпадение считается достаточным: relaxed и strict

Два домена не обязаны быть одинаковыми. По умолчанию соответствие нестрогое (relaxed): достаточно, чтобы оба принадлежали одному зарегистрированному домену, который стандарт называет организационным. Строгое соответствие (strict) требует точного совпадения. Выбор задаётся тегами adkim для DKIM и aspf для SPF в вашей записи DMARC.

Стандарт отмечает, что «почти все владельцы доменов сочли нестрогое соответствие достаточным для своих нужд». Свою запись всё же проверьте. Пример записи в начале страницы Google о настройке DMARC заканчивается на adkim=s; aspf=s, так что запись, скопированная оттуда, будет строгой. Если в вашей записи есть эти два тега, а какой-то сервис отправляет с поддомена, уберите их. Google сам предупреждает на той же странице, что при строгом соответствии «сообщения со связанных поддоменов могут отклоняться или попадать в спам».

Откуда обычно берётся несовпадение

Сервис, который отправляет со своих серверов

Платформы рассылок, CRM, сервисы выставления счетов и службы поддержки отправляют вашу почту со своей инфраструктуры. Пока вы не подключите свой домен, они обычно используют адрес для возвратов в своём домене и подписывают своим ключом. Документация Amazon прямо объясняет, почему соответствие по SPF здесь редкость: Return-Path «используется для возвратов и жалоб, которые провайдер (SES) отслеживает с помощью принадлежащего ему адреса» (Amazon SES). Настройка, которая это исправляет, в каждом сервисе называется по-своему и заканчивается несколькими записями DNS на вашей стороне.

Это описания самих поставщиков по состоянию на октябрь 2026 года. Другие сервисы устроены похожим образом. Ищите в их справке «authenticate domain», «custom DKIM» или «branded sending domain».

Ваш почтовый провайдер подписывает своим доменом или не подписывает вовсе

Если ящик находится на вашем домене, Return-Path обычно совпадает с вашим адресом, поэтому SPF соответствует, как только в вашей записи SPF указан провайдер. Это видно по значению после smtp.mailfrom=. Переключатель нужен для DKIM.

• Google Workspace. Пока DKIM для вашего домена не включён, Google подписывал письма одним из собственных доменов. В прежней версии справочной страницы Google говорилось, что Gmail в этом случае подписывает «этим ключом домена DKIM по умолчанию: d=*.gappssmtp.com». Нынешняя страница домен уже не называет, поэтому проверьте свой заголовок: если header.i заканчивается на gappssmtp.com, ваш ключ не активен. Создайте его в консоли администратора в разделе Apps, Google Workspace, Gmail, Authenticate email, добавьте показанную там запись TXT и нажмите Start authentication (настройка DKIM).
• Microsoft 365. В документации Microsoft, обновлённой в августе 2026 года, сказано: «В настоящее время исходящая почта с пользовательских доменов не подписывается DKIM». Вы публикуете две записи CNAME и включаете подпись на портале Defender (как использовать DKIM для почты в собственном домене).

Запись, которую вы добавляете для ключа DKIM, всегда находится ниже _domainkey, под именем, которое выбирает провайдер. Для Google Workspace она выглядит так (ключ сокращён):

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

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

Сообщение было переслано

Когда получатель автоматически пересылает ваше письмо, оно приходит с сервера, которого нет в вашей записи SPF. SPF не проходит или проходит для домена того, кто пересылает. Подпись DKIM переживает этот путь, пока никто не меняет сообщение. Списки рассылки, которые дописывают текст в конец письма или метку в тему, ломают и подпись. Со своей стороны вы это исправить не можете. В вопросах и ответах Google для отправителей сказано, что для Gmail «соответствие DMARC не требуется для пересланных сообщений и сообщений из списков рассылки». Поэтому и нужно соответствие по DKIM, а не расчёт на один SPF.

Это не ваши письма

Если отчёты DMARC показывают непройденные проверки с серверов, которыми вы никогда не пользовались, возможно, кто-то отправляет письма с вашим адресом. Такие сообщения и не должны проходить проверку. Исправлять ничего не нужно, а позже они станут доводом в пользу более строгой политики.

Сначала исправьте DKIM, затем SPF

Любой из двух даёт результат pass. Лучше иметь DKIM, потому что он путешествует вместе с сообщением. Рекомендации M3AAWG формулируют это как правило: «Подписывайте всю исходящую почту ключом DKIM, который соответствует домену заголовка RFC5322.From». RFC 9989 рекомендует использовать оба механизма.

1. Перечислите всё, что отправляет от имени вашего домена. Почтовые ящики, сервис рассылок, CRM, счета, форма обратной связи на сайте. Отчёты DMARC назовут то, о чём вы забыли.
2. Проверьте каждый источник по заголовку, как описано выше, и запишите, какой из двух доменов не ваш.
3. Включите подпись своим доменом везде, где header.i показывает другое имя, и опубликуйте записи, которые выдаст сервис. Выберите ключ длиной 2048 бит, если ваш DNS-хостинг его принимает. Gmail требует не менее 1024 бит и рекомендует 2048.
4. Задайте собственный домен для возвратов там, где сервис это предлагает, на поддомене вроде bounce.example.com. Тогда соответствовать будет и SPF.
5. Отправьте тестовое письмо ещё раз и найдите dmarc=pass. Изменения DNS могут занять время. Google отводит до 48 часов на то, чтобы новый ключ DKIM начал работать.

А вот добавлять поставщика в собственные записи бесполезно. include: для поставщика в вашей записи SPF ничего не меняет, если Return-Path находится в домене поставщика, потому что SPF запрашивает запись того домена, а не вашего. Перечислить доверенные сторонние сервисы в записи DMARC тоже нельзя. В стандарте сказано, что для этого нет «общепринятого механизма».

Если заголовок показывает dmarc=pass, а сообщение всё равно попадает в спам, причина уже не в аутентификации. С этого места продолжает руководство SPF, DKIM и DMARC пройдены, а письмо всё равно попадает в спам.

Чего стоит непройденный DMARC, пока ваша политика p=none

С p=none вы просите получателей ничего не предпринимать при непройденной проверке, поэтому из-за вашей политики ничего не отклоняется. Против вас это всё равно работает, причём двумя способами.

• Правила для массовых отправителей. Gmail, Yahoo и Outlook.com требуют от массовых отправителей писем с соответствием доменов; для Gmail и Outlook.com это значит от 5000 сообщений в день. Вопросы и ответы Google для отправителей указывают временную ошибку 4.7.32 для писем, у которых заголовок From «не соответствует ни аутентифицированному организационному домену SPF, ни домену DKIM», и называют последствием «коды временного или постоянного сбоя либо помещение в папку спама».
• Это закрывает следующий шаг. Как только вы перейдёте на p=quarantine или p=reject, каждое ваше собственное сообщение без соответствия доменов должно будет считаться спамом или отклоняться. В Gmail текст возврата такой: «Unauthenticated email from domain-name is not accepted due to domain's DMARC policy», ошибка 5.7.26 (устранение проблем с DMARC).

Если записи DMARC у вас нет совсем, начните с записи, которую нужно добавить. Она же включает отчёты, которые показывают соответствие сразу по всем вашим отправителям.

Что здесь может прогрев и чего не может

Прогрев не исправляет несоответствие доменов. WarmupBay подключается к вашему ящику и отправляет с него, поэтому его письма для прогрева отправляет и подписывает ваш провайдер точно так же, как письма, которые вы пишете сами. Если ваш ящик не проходит DMARC, они не проходят вместе с ним. Сначала исправьте записи.

WarmupBay помогает с тем, что до этого, и с тем, что после. Когда вы подключаете ящик, он проверяет SPF, DKIM и DMARC домена и останавливает прогрев, если через 72 часа записей всё ещё нет. Когда они на месте, ваш ящик каждый день обменивается несколькими письмами с другими ящиками общего пула, а панель показывает, куда они попали: во входящие, на вкладку Gmail или в спам, отдельно для Google и для других провайдеров. Письма из вашего сервиса рассылок или CRM он не проверяет, потому что они не проходят через ваш ящик, и пока не может подключать ящики Microsoft 365 и Outlook.com. 10 писем для прогрева в день бесплатны. Подключите ящик, когда заголовок покажет dmarc=pass.

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

SPF проходит и соответствует домену, а DKIM не соответствует. Этого достаточно?

Для DMARC да. Достаточно одного результата pass с соответствием домена. Этого перестаёт хватать, когда получатель пересылает ваше письмо, потому что SPF тогда уже не совпадает. Кроме того, Google пишет в вопросах и ответах для отправителей, что соответствие и по SPF, и по DKIM, вероятно, станет требованием, поэтому настройте DKIM для своего домена в любом случае.

Почему у одних получателей DMARC не проходит, а у других проходит?

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

Участвует ли адрес Reply-To в проверке DMARC?

Нет. DMARC использует только домен из заголовка From. Адрес Reply-To, отображаемое имя и заголовок Sender в проверку не входят.

Как увидеть проблемы с соответствием доменов, не открывая заголовки?

В сводных отчётах DMARC. В каждой записи есть блок policy_evaluated с результатами dkim и spf: это результаты после проверки соответствия. Блок auth_results под ним показывает исходные результаты и домены, к которым они относятся. Исходный pass рядом с итоговым fail и есть случай с этой страницы. Чтобы получать отчёты, добавьте адрес rua в свою запись DMARC.

В заголовке стоит dkim=fail или dkim=neutral. Это та же проблема?

Нет. В этом случае не прошла проверку сама подпись, а это другая неисправность. Если в тексте стоит body hash did not verify, страница Google по устранению неполадок называет причину: сообщение изменили после подписания, например шлюз дописал текст в конец письма. Соответствие же касается подписи, которая действительна, но принадлежит другому домену.

Нужен ли отдельный ключ DKIM для каждого сервиса, который отправляет письма от моего имени?

На практике да. Каждый сервис подписывает своим ключом и публикует его под своим именем селектора ниже _domainkey в вашем домене, поэтому несколько ключей существуют рядом без конфликта. С SPF иначе: там у домена может быть только одна запись.

Источники

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. RFC 7208: Sender Policy Framework (SPF)
4. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
5. RFC 8601: Message Header Field for Indicating Message Authentication Status
6. Email sender guidelines – Gmail Help
7. Email sender guidelines FAQ – Gmail Help
8. Set up DMARC – Google Workspace Help
9. Set up DKIM – Google Workspace Help
10. Troubleshoot DMARC issues – Google Workspace Help
11. Troubleshoot DKIM issues – Google Workspace Help
12. Trace an email with its full header – Gmail Help
13. Check if your Gmail message is authenticated – Gmail Help
14. Set up DKIM to prevent email spoofing – Google Workspace Admin Help, archived version of 30 June 2021
15. How to use DKIM for email in your custom domain – Microsoft Learn
16. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
17. Sender Best Practices – Yahoo Sender Hub
18. Configure domain authentication – Twilio SendGrid Docs
19. Complying with DMARC authentication protocol in Amazon SES – AWS Documentation
20. Using a custom MAIL FROM domain – Amazon SES, AWS Documentation
21. About Email Domain Authentication – Mailchimp Help
22. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)