Короткий ответ

В тенанте contoso.onmicrosoft.com DMARC смотрит на домен заголовка From и требует, чтобы SPF или DKIM выровнялись с ним. Политика _dmarc.contoso.example с p=reject заставляет принимающую сторону отбрасывать fail. Легитимная почта падает, когда есть отправитель, которого не внесли в SPF и не подписали DKIM на d=contoso.example: веб-форма, МФУ, старый ISP, партнёрская рассылка, «PHP mail» на хостинге. Exchange Online при правильных SPF+DKIM здесь ни при чём.

Не откатывайте сразу на p=none в панике, если не понимаете, какой поток режется. Снимите NDR/заголовки и rua. Потом либо включите отправителя в контур, либо смените его From на другой домен, либо временно p=quarantine/pct=. Не ставьте p=reject в день первой публикации записи.

Симптомы и как отличить

  • Обычная переписка ivan.petrov@contoso.example из Outlook жива; «заявка с сайта» и «скан на e-mail» мертвы.
  • У получателя NDR с отсылкой к DMARC / 5.7.26.
  • В заголовке dmarc=fail при spf=pass на return-path другого домена и dkim=none (или d= не ваш).
  • Отчёты rua (XML) показывают disposition=reject для IP хостинга.
ПотокТипичный failЛечение
Outlook / OWAредко, если SPF+DKIM EOне трогать p=
CRM ESPнет alignmentDKIM ESP + include
МФУ прямой SMTPнет ни SPF ни DKIMrelay в EO или ip4+DKIM
Сайт sendmailFrom компании, IP хостингаSPF ip4 или другой From

Это не спам-классификация при p=none: reject — детерминированный отказ, не Junk. Не путайте с неверной MX: там письма не входят к вам.

Возможные причины

  1. Перешли на p=reject, не закрыв инвентарь отправителей.
  2. aspf=s / adkim=s (strict) при поддоменах: шлёте с notify.contoso.example, политика strict к apex.
  3. sp=reject на apex убивает поддомены без своих записей.
  4. Пересылка (forward) ломает SPF, DKIM не выровнен — получатель с жёстким DMARC режет. Это чужая пересылка, не ваш сканер.
  5. Envelope aligned, From — отображаемое имя с другим доменом (редко в корпоративной почте, часто в «красивых» рассылках).
  6. Два _dmarc TXT — permerror политики.
  7. Запись повешена не на _dmarc.contoso.example, а на _dmarc.www по ошибке GUI.

Диагностика

1. Что опубликовано

Resolve-DnsName _dmarc.contoso.example -Type TXT
nslookup -type=TXT _dmarc.contoso.example

Ожидайте один TXT вида v=DMARC1; p=...; rua=mailto:dmarc@contoso.example. Разобрать: p, sp, adkim, aspf, pct, fo.

2. Заголовки одного отклонённого письма

Нужен образец (NDR часто цитирует). Смотрите From:, Return-Path:, Authentication-Results. Fail DMARC при SPF pass на невыровненном домене — классика ESP.

3. rua, не «ощущения»

Почта на dmarc@contoso.example (или внешний агрегатор). В aggregate report: source IP, header_from, spf/dkim aligned (pass/fail), disposition. Сгруппируйте IP: Microsoft, ESP, хостинг, офисный NAT. Офисный NAT + From компании = сканер/скрипт.

4. Сверка SPF/DKIM

Параллельно: SPF, DKIM, комплект. Без pass+alignment p=reject будет резать.

5. Message Trace

Connect-ExchangeOnline -UserPrincipalName admin@contoso.example
Get-MessageTrace -SenderAddress ivan.petrov@contoso.example `
  -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) |
  Where-Object Status -eq 'Failed'

Исходящие EO в трейсе могут быть Delivered, а отказ случится уже на MX получателя — тогда трейс не покажет их DMARC. Источник правды для исходящих — NDR и rua, не только EO.

Решение

Сценарий A. Нашли неучтённый отправитель

Варианты, от предпочтительных:

  1. Отправлять через Exchange Online (сокет, коннектор, ящик устройства).
  2. DKIM-селектор ESP + include в SPF, From остаётся @contoso.example.
  3. Сменить From на noreply@notify.contoso.example с своим SPF/DKIM/DMARC на поддомене.
  4. Запретить поток, если это теневой IT.

Не добавляйте +all, чтобы «легализовать всех».

Сценарий B. Политика слишком строгая для переходного периода

Временно p=quarantine или p=reject; pct=10, оставьте rua. Это управляемый откат, не удаление _dmarc.

Сценарий C. Strict alignment и поддомены

Для смешанных потоков на старте adkim=r; aspf=r (relaxed, это и так default). Strict включайте, когда все From только apex и подписи на apex.

Сценарий D. Легитимный форвард ломается

Пересылка списков часто fail SPF. Лечится ARC у пересыльщика или тем, что списки не используют ваш From. Не отключайте DMARC из-за одной рассылки-форвардера.

Как проверить, что проблема устранена

  1. Контрольные письма: Outlook, сайт, сканер — у каждого dmarc=pass на тестовом получателе, который показывает заголовки.
  2. rua за сутки: нет unexpected reject по вашим IP.
  3. Бизнес-поток (счета) дошёл не в карантин.
  4. Политика возвращена к целевой (p=quarantine затем reject), когда rua чистый.

Если не помогло

  • rua пустой: получатели не шлют aggregate (многие мелкие MX). Полагайтесь на собственные контрольные ящики.
  • Reject только у Yahoo/Gmail: они жёстче исполняют p=. Значит fail реальный.
  • Подделка с вашего домена тоже начала доходить после p=none — ожидаемо; не живите на none месяцами без плана.
  • Внутренние письма в тенанте не ходят через публичный DMARC — по ним политику не судят.

Профилактика

  • Порядок: SPF → DKIM → p=none+rua → закрыть отправителей → quarantine → reject. Чеклист: подготовка домена.
  • Запрет From компании на хостинге без договора.
  • Алерт на появление нового source IP в rua.
  • Не копировать _dmarc с p=reject «как у крупной фирмы» в день миграции.

FAQ

Можно ли исключить один IP из DMARC?

Нет такого механизма в записи. Либо IP проходит SPF/DKIM alignment, либо From не ваш домен.

rua на внешний сервис безопасен?

Отчёты содержат объёмы и IP, не тела писем. Используйте ящик, к которому ограничен доступ, или проверенный агрегатор. Не публикуйте rua на общую группу «всем сотрудникам».

Зачем fo=1?

Просит forensic (failure) отчёты. Многие получатели их не шлют или шлют редко. Не стройте процесс только на ruf.

Outlook не пострадал, значит DMARC ок?

Нет. Пострадал неучтённый канал. Именно его и ищут до reject.

p=reject защищает входящие к нам?

DMARC в вашей зоне влияет на то, как чужие MX обрабатывают письма как будто от вас. Входящий антиспуфинг Microsoft — отдельные политики Defender, не эта TXT.