Популярные инструменты

Тема

Проверка DMARC

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

Источники: TXT-записи _dmarc домена и его родителей через Google Public DNS (за ним Cloudflare 1.1.1.1) · обход дерева по RFC 9989 · разрешение на отчёты по RFC 9990 · SPF и DKIM из наших собственных проверок · о вас ничего не сохраняется

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

Введите домен выше: проверка запрашивает у DNS TXT-запись у _dmarc. плюс домен, поднимается к организационному домену, если записи нет (RFC 9989 §4.10), и показывает, что принимающий сервер делает с письмами, не прошедшими проверку.

Вручную спросите то же имя: dig +short TXT _dmarc.paypal.com или nslookup -type=TXT _dmarc.paypal.com в Windows. Один ответ, начинающийся с v=DMARC1, — это запись; два ответа означают, что получатели не используют ни один (RFC 9989 §4.10).

dig на этом останавливается. Он не поднимается от поддомена вверх, не проверяет, принимают ли адреса для отчётов эти отчёты, и не говорит, какому RFC следует получатель. Это и добавляет проверка.

dig +short TXT _dmarc.example.com

Все ответы у этого имени. Одна запись, начинающаяся с v=DMARC1, и есть DMARC.

Что показывает dig, а что нет

терминал

$ dig +short TXT _dmarc.paypal.com 1

"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"

$ dig TXT _dmarc.mail.google.com | grep status 4

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

  1. 1Имя — это _dmarc. плюс доменНе сам домен: TXT у paypal.com — место для SPF.
  2. 2Одна запись, v=DMARC1 первойДве записи под одним именем: получатели отбрасывают обе (RFC 9989 §4.10).
  3. 3Теги, разделённые ;p — политика; rua и ruf говорят, куда идут отчёты.
  4. 4Здесь пусто? Идите выше_dmarc.mail.google.com — это NXDOMAIN: действует запись google.com.
Запись paypal.com в том виде, как Google Public DNS вернул её 24 октября 2026 г.; у mail.google.com собственной записи нет.

Как читать результат: взгляд получателя

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

Баллов нет: политика none — это этап, а не провал, а лестница под путём говорит, что нужно для следующего шага.

Проверка DMARC для paypal.com: отклоняет письма, не прошедшие DMARC, взгляд получателя и лестница применения политикиПроверка DMARC для paypal.com: отклоняет письма, не прошедшие DMARC, взгляд получателя и лестница применения политикиВердиктОдно предложение о том, что получатели делают с письмами, не прошедшими проверку, и политика, SPF и DKIM с первого взгляда.ЗаписьКаждый тег подсвечен поверх своих символов: наведите курсор или коснитесь, чтобы узнать, что он делает. Под записью — значения по умолчанию.Взгляд получателяКаждый запрос DNS, который принимающий сервер задаёт для домена, по порядку, с ответом.Письма, не прошедшие DMARCЧто получатели делают для домена, его существующих поддоменов и несуществующих имён.Лестница примененияГде домен находится между none и reject и что нужно для следующего шага.
Проверка DMARC для paypal.com: вердикт, запись, разобранная на теги, взгляд получателя со всеми запросами DNS и тем, что происходит с письмами, не прошедшими проверку, и лестница применения политики. Выберите номер, чтобы увидеть, что показывает каждая часть.

Для чего нужен DMARC?

DMARC говорит принимающим почтовым серверам, что делать с письмами, где в строке From: указан ваш домен, но которые не могут доказать, что пришли от вас, и куда присылать отчёты о них (RFC 9989 §4.7).

Доказательство — это SPF или DKIM, выровненные с доменом From:: SPF проходит для домена возврата в той же организации или подпись DKIM содержит d= с вашим доменом. Одного выровненного прохождения достаточно (RFC 9989 §5.3.5); всё остальное не проходит DMARC, и решает политика записи: доставить, отправить в спам или отклонить.

Отчёты — вторая половина. Получатели, которые учитывают rua, присылают ежедневную сводку о каждом сервере, отправлявшем почту от имени вашего домена; так вы находите законных отправителей, о которых забыли, прежде чем включите применение политики.

Два письма, одна строка From:

From: billing@example.comp=reject · rua=mailto:dmarc@example.com

Ваш счёт, отправленный через почтовый сервисчерез сервис с настроенным собственным DKIM, поэтому он подписывает с d=example.com

  1. SPFpass · bounces.esp.example (не выровнен)
  2. DKIMpass · d=example.com (выровнен)
  3. DMARCpass: достаточно одного выровненного результата
Доставлено

Поддельный счёт с 203.0.113.9сервер, которому example.com ничего не разрешал

  1. SPFfail · 203.0.113.9 нет в списке
  2. DKIMнет · подписи нет
  3. DMARCfail → p=reject
Отклонено

550 5.7.1 Email rejected per DMARC policy for example.com

Завтрашний агрегированный отчёт для dmarc@example.com: 1 письмо с 203.0.113.9, SPF fail, DKIM нет, действие reject.

Прохождение не обещает доставку (решают ещё и фильтры получателя), а fail при p=reject — это просьба, а не приказ (RFC 9989 §5.4, §7.4). Адреса из RFC 5737; текст ответа — собственный пример из RFC 9989.

Теги записи DMARC: объяснение

Запись DMARC — это список пар тег=значение в TXT-записи у _dmarc. плюс домен: сначала v=DMARC1, затем теги политики, выравнивания и отчётов в любом порядке (RFC 9989 §4.7).

RFC 9989 (май 2026 года) заменил RFC 7489. Он добавил np, psd и t и убрал pct, rf и ri: современные получатели их игнорируют, а получатели, всё ещё работающие по RFC 7489, их читают, поэтому запись с pct=25 означает для разных получателей разное.

Теги, которые вы не публикуете, принимают значения по умолчанию, и проверка показывает и их: если sp нет, поддомены получают p.

Все теги по тому, что они делают

v=DMARC1; p=reject; sp=quarantine; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1
ВерсияПолитикаТест и суффиксВыравниваниеОтчётыУбран
ТегЧто задаётПо умолчаниюСтатусВстречается
vВерсияDMARC1обязателен, первымRFC 9989192
pПолитика для доменаnone · quarantine · rejectnone, если нет, а rua корректенRFC 9989192
spПолитика для существующих поддоменовnone · quarantine · rejectpRFC 998939
npПолитика для несуществующих имёнnone · quarantine · rejectsp, затем pновое в RFC 99892
tТестовый режим: на шаг ниже политикиy · nnновое в RFC 99890
psdПубличный суффикс (y) или организационный домен (n)y · n · uuновое в RFC 99891
adkimВыравнивание DKIMr · srRFC 998920
aspfВыравнивание SPFr · srRFC 998924
ruaКуда идут агрегированные отчётыmailto:…нет отчётовRFC 9989186
rufКуда идут отчёты о сбояхmailto:…нет отчётовRFC 9989120
foКогда присылать отчёты о сбоях0 · 1 · d · s0RFC 998996
pctДоля писем, не прошедших проверку, к которой применяется политика0–100–убран70
rfФормат отчёта о сбоеafrf–убран9
riИнтервал отчётов, секунды86400–убран14
Встречается: у скольких из 192 записей DMARC, опубликованных 196 известными доменами, есть этот тег (прочитано 24 октября 2026 г.; в 69 из 70 тегов pct указано pct=100). Значения по умолчанию и статус по RFC 9989 §4.7 и приложению C.

Политика DMARC: p=none, quarantine или reject

p=none просит получателей доставлять письма, не прошедшие проверку, как обычно и только сообщать о них; quarantine — считать их подозрительными, обычно отправлять в спам; reject — отказать в приёме прямо во время SMTP-диалога.

None — это этап, а не провал: RFC 9989 §7.4 советует провести на нём минимум месяц с работающими отчётами и ещё столько же на quarantine, прежде чем переходить к reject. Домены, чьи сотрудники пишут в рассылки, стоит остановить на quarantine.

Крупные почтовые провайдеры тоже разделяют политику: gmail.com и outlook.com публикуют p=none для самого домена и sp=quarantine для поддоменов, а google.com, yahoo.com и microsoft.com публикуют reject.

Куда попадает поддельное письмо

Доставленоp=none

apache.orggmail.comsamsung.com

23 из 192

Папка «Спам»p=quarantine

github.comapple.comamazon.com

30 из 192

Отклоненоp=reject

google.compaypal.commicrosoft.com

139 из 192

none 23quarantine 30reject 139из 192 записей, 196 известных доменов, 24 октября 2026 г.

В итоге решают получатели: они могут доставить письмо, не прошедшее проверку при p=reject, и не должны отклонять его только из-за политики (RFC 9989 §5.4, §7.4). Исследование одного из вендоров показывает, насколько отстаёт остальной интернет: среди 1,8 миллиона крупнейших доменов в начале 2026 года EasyDMARC насчитал 29,2 % на p=none и 22,9 % на quarantine или reject.

Нужен ли DMARC на самом деле?

Да, если вы массово отправляете почту на Gmail, Yahoo или Outlook.com: все три требуют запись DMARC, и p=none достаточно для выполнения правила. Применение политики (quarantine или reject) мешает посторонним отправлять почту от имени вашего домена, и логотипам BIMI оно тоже нужно.

Gmail требует её (начало: 1 февраля 2024 г.) от отправителей, шлющих больше 5 000 писем в сутки на аккаунты Gmail; Yahoo (начало: февраль 2024 г.) требует её, не называя объёма; Outlook.com (начало: 5 мая 2025 г.) требует её при объёме больше 5 000 в сутки. Без записи Gmail отвечает 4.7.31 (и 4.7.32, если From: не выровнен), а Outlook.com отклоняет письма с 550 5.7.515.

Для домена, который ничего не отправляет, DMARC — самая дешёвая защита: p=reject, null MX и v=spf1 -all, как публикует example.com (M3AAWG).

Чего каждый почтовый провайдер требует от массовых отправителей

Gmail1 февр. 2024 г.5 000+ в сутки на аккаунты Gmail4.7.31 · 4.7.32
Yahooфевр. 2024 г.порог не опубликованDMARC должен проходить
Outlook.com5 мая 2025 г.5 000+ в сутки550 5.7.515
Доставленоp=noneвыполняет правило всех трёх провайдеров
Папка «Спам»quarantineостанавливает большую часть подделок · возможны логотипы BIMI
Отклоненоrejectостанавливает подделки на входе · BIMI

✓Обязательно: запись, p=none или строжеiЗащита: quarantine или reject

По страницам самих провайдеров для отправителей, прочитано 24 октября 2026 г.. Доля спама меньше 0,3 % и отписка в один клик — тоже правила, но DNS их показать не может; вкладка «Требования» в проверке говорит, что из этого она способна доказать.

Как исправить сбои DMARC: пересылка, рассылки, собственный домен сервиса

Найдите источник сбоев в агрегированных отчётах и исправьте его у отправителя: подпишите его DKIM для вашего собственного домена или перенесите на домен возврата внутри вашей организации. Большинство сбоев объясняют три причины.

Пересылка сохраняет подпись DKIM, но ломает SPF, поэтому прохождение обеспечивает DKIM. Рассылки, которые изменяют письмо, ломают оба. А почтовый сервис, подписывающий своим доменом, проходит DKIM для себя, а не для вас: включите его собственный DKIM для вашего домена (обычно это CNAME вроде s1._domainkey) и собственный домен возврата.

Три сбоя, что показывает отчёт и как их исправить

Пересылка

  • SPF192.0.2.80 нет в SPF у example.com
  • DKIMподпись цела

Отчёт показываетspf=fail dkim=pass → pass

Подписывайте всё через DKIM: DKIM переживает пересылку. ARC (RFC 8617) помогает пересылающим серверам поручиться за письмо.

Рассылка

  • SPFотправляет сервер рассылки
  • DKIMтело изменено: хеш не сходится

Отчёт показываетspf=fail dkim=fail → fail

Рассылки, которые переписывают From:, решают проблему; домены, чьи сотрудники пишут в рассылки, остаются на quarantine (RFC 9989 §7.4).

Собственный домен сервиса

  • SPFpass для bounces.esp.example: не выровнен
  • DKIMpass для esp.example: не выровнен

Отчёт показываетdkim=pass(esp.example) → fail

Включите собственный DKIM сервиса: s1 и s2 у paypal.com — это CNAME на SendGrid, который подписывает как paypal.com.

Адреса из RFC 5737; esp.example — заглушка. CNAME на SendGrid — настоящие селекторы paypal.com (24 октября 2026 г.).

DMARC для поддоменов: sp и np

Поддомен без собственной записи получает политику своего организационного домена: sp для существующих поддоменов, np для несуществующих имён, и оба при отсутствии берут p (RFC 9989 §4.7).

Поддомен, публикующий собственную запись, использует её для себя. Но запись между именем и его организационным доменом для этого имени никогда не используется: это видно на дереве berkeley.edu, где sp=none у eecs.berkeley.edu не доходит до www.eecs.berkeley.edu (RFC 9989 §4.10.1).

np — самая дешёвая победа: несуществующие имена не отправляют настоящей почты, поэтому np=reject блокирует подделки с них, даже пока p ещё на none. Получатели на RFC 7489 про np не знают и используют sp.

Дерево berkeley.edu глазами получателя

berkeley.edup=reject; np=reject; psd=n; rua=…собственная запись · psd=n: организационный доменОтклонено
www.berkeley.eduнет записисуществует → sp, нет → pОтклонено
eecs.berkeley.edup=reject; sp=none; rua=…собственная запись → pОтклонено
www.eecs.berkeley.eduнет записиобход: запись eecs.berkeley.edu пропускается (это не организационный домен) → p у berkeley.eduОтклонено
nosuch-x7.berkeley.eduNXDOMAINне существует → npОтклонено

sp=none у eecs.berkeley.edu никогда не применяется: запись между именем и его организационным доменом для него не используется (RFC 9989 §4.10.1). Проверка помечает её как неиспользуемую запись.

Прочитано 24 октября 2026 г. через Google Public DNS. nosuch-x7.berkeley.edu — выдуманное имя; его NXDOMAIN настоящий.

Как читать отчёты DMARC (rua)

Агрегированный отчёт — это ежедневный XML-файл от каждого получателя, где перечислены все серверы, отправлявшие почту от имени вашего домена, сколько писем и прошли ли SPF, DKIM и DMARC (RFC 9990).

Читайте его по источникам: ваши собственные серверы и сервисы должны показывать выровненное прохождение; известный сервис с ошибкой требует собственного DKIM; неизвестный адрес с ошибкой при p=reject — это подделка, которую остановили. Сервис отчётов (dmarcian, Valimail, EasyDMARC, Postmark и другие) превращает тысячи файлов в такой список.

Отчёты на адрес в другом домене приходят, только если этот домен согласен: он публикует yourdomain._report._dmarc.its-host со значением v=DMARC1 (RFC 9990 §4). Проверка спрашивает за вас и даёт точную запись, если её нет.

Один отчёт, строка за строкой

<org_name>google.com</org_name>1

<date_range>23 окт., 00:00 UTC – 24 окт., 00:00 UTC</date_range>

<policy_published>example.com · p=reject</policy_published>2

<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3

<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4

  1. 1Кто прислал отчётОдин файл от получателя в сутки (RFC 9990: минимум каждые 24 часа).
  2. 2Политика, которую он нашёлЧто он прочитал у _dmarc.example.com.
  3. 3Пересланное письмо, спасённое DKIMSPF не прошёл у пересылающего сервера; выровненная подпись прошла DMARC.
  4. 4Подделка, которую остановилиНеизвестный сервер, ничего не выровнено, отказано.
paypal.comrua=mailto:d@rua.agari.comrua.agari.compaypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ разрешено: отчёты идут

Сервисы отчётов, которые узнаёт проверкаdmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+ещё 6

XML сокращён и придуман (адреса для документации, RFC 5737); запись-разрешение — настоящая запись paypal.com, прочитана 24 октября 2026 г..

Проверка DMARC: частые вопросы

Что такое DMARC?

DMARC — это запись DNS, которая говорит принимающим почтовым серверам, что делать с письмами, где в строке From: указан ваш домен, но которые не прошли выравнивание SPF и DKIM: доставить, поместить в карантин или отклонить. Она также указывает, куда получатели присылают отчёты о таких письмах. Публикуется как TXT-запись у _dmarc плюс ваш домен и определена в RFC 9989, который в мае 2026 года заменил RFC 7489.

Что показывает проверка записи DMARC?

Она читает TXT-запись у _dmarc плюс домен, а если её нет — родительских доменов, как это делает получатель. Эта проверка показывает запись по тегам со значениями по умолчанию, политику для домена, его поддоменов и несуществующих имён, принимают ли адреса для отчётов эти отчёты, а также запись SPF и ключи DKIM домена, без баллов.

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

Проверьте домен выше: опубликованная политика — это то, что в DMARC-тесте может ответить DNS. Чтобы увидеть, проходит ли настоящее письмо, отправьте его на ящик, которым вы управляете, и прочитайте заголовок Authentication-Results или вставьте заголовки в анализ заголовков Email. Валидатор DMARC проверяет синтаксис записи; выровнены ли SPF или DKIM, покажет только письмо.

С какой политики DMARC начать?

Начните с p=none и адреса rua: получатели будут присылать ежедневные отчёты, не меняя доставку. Исправьте каждого законного отправителя, который не проходит, обычно включив его собственный DKIM, затем перейдите на quarantine и, наконец, на reject. RFC 9989 советует минимум месяц на p=none и ещё столько же на quarantine. Домен, который не отправляет почту, может сразу перейти на p=reject.

Защищает ли p=none мой домен?

Нет. p=none просит получателей обрабатывать письма, не прошедшие проверку, как обычно, поэтому поддельное письмо оценивают только их собственные спам-фильтры. Зато вы получаете отчёты, и это выполняет правило Gmail, Yahoo и Outlook.com для массовых отправителей. Считайте его этапом мониторинга: защита начинается с quarantine, а reject останавливает поддельную почту до того, как она кого-то достигнет.

Что значит t=y в записи DMARC?

t=y — это тестовый режим RFC 9989: получатели применяют уровень на шаг ниже опубликованной политики, поэтому p=reject действует как quarantine, а p=quarantine как none. На p=none он не влияет и отчётов не меняет. Получатели, всё ещё работающие по RFC 7489, этот тег не знают и применяют политику как написана. Уберите t=y, когда отчёты покажут, что выровнены все законные отправители.

Используется ли ещё тег pct?

RFC 9989 убрал pct вместе с rf и ri, потому что значения, отличные от 0 и 100, применялись непоследовательно. Современные получатели его игнорируют и применяют политику ко всем письмам, не прошедшим проверку. Получатели на RFC 7489 выбирают долю: pct=25 при quarantine отправляет четверть таких писем в спам, а остальные доставляет. pct=100 безвреден; для тестового периода используйте t=y.

Почему мой адрес rua «не разрешён»?

Когда отчёты идут на ящик в другом организационном домене, этот домен должен согласиться, опубликовав TXT-запись с именем yourdomain._report._dmarc.its-host и значением v=DMARC1 (RFC 9990 §4). Без неё получатели, которые это проверяют, пропускают адрес. Запись нужна в DNS получателя отчётов, а не вашем: сервисы отчётов публикуют подстановочную запись для всех клиентов, так что обычно дело в опечатке или в ящике партнёра.

Нужна ли каждому поддомену собственная запись DMARC?

Обычно нет. Поддомен без записи получает политику своего организационного домена: sp для существующих поддоменов, np для несуществующих имён, оба при отсутствии берут p. Публикуйте запись на поддомене, только когда ему нужна другая политика. Запись на промежуточном имени, например team.example.com для www.team.example.com, для более глубокого имени не используется.

Что будет, если домен опубликует две записи DMARC?

Получатели отбрасывают обе, поэтому никакая политика DMARC не действует и отчёты не присылаются, даже если в одной из двух написано reject (RFC 9989 §4.10). Обычно так происходит, когда новую запись добавляют, не удалив старую, или когда DNS-хостинг добавляет запись по умолчанию. Оставьте одну запись у _dmarc, а другую удалите; проверка показывает, какая похожа на задуманную.

Почему DMARC не проходит, хотя SPF проходит?

DMARC требует, чтобы SPF проходил для домена, выровненного с адресом From:. Большинство почтовых сервисов отправляют с собственным доменом возврата, поэтому SPF проходит для них, а не для вас, и не засчитывается. То же верно для DKIM, подписанного доменом сервиса. Настройте собственный DKIM или собственный домен возврата сервиса, чтобы проходящим доменом был ваш.

Проверка показывает, что записи нет, но я её только что добавил. Почему?

Сначала проверьте поле хоста: в большинстве панелей DNS нужно только _dmarc, а ввод _dmarc.example.com создаёт _dmarc.example.com.example.com. Затем дождитесь, пока истечёт старый ответ: если имя уже запрашивали, резолверы хранят его NXDOMAIN в течение отрицательного TTL зоны, часто от 5 минут до часа. SERVFAIL или тайм-аут показывается как «не удалось проверить», а не как отсутствие записи.

Другие инструменты для почты и DNS