Кратко

  • DMARC pass подтверждает только разрешённое применение Author Domain, но не истинность, безопасность, намерение или ценность письма.
  • p=reject выражает предпочтение Domain Owner; RFC 9989 оставляет финальную обработку и обоснование исключения у Mail Receiver.

Письмо из разрешённой инфраструктуры может пройти DMARC и содержать злоупотребление. Законное письмо после пересылки или списка может получить fail. Система, переводящая pass как «безопасно», а fail как «мошенничество», ошибается дважды.

RFC 9989 опубликован в мае 2026 года в Standards Track IETF и заменяет RFC 7489 и 9091. Карточка, Datatracker и errata подтверждают документ, но не внедрение.

SPF связывает SMTP-источник с авторизованной идентичностью, DKIM проверяет доменную подпись. DMARC требует совпадения хотя бы одного Authenticated Identifier с видимым Author Domain. Совпавший успех даёт pass, отсутствие — fail.

RFC сразу ограничивает вывод. Pass означает лишь разрешённое использование домена и не содержит оценки сообщения. Получатель вправе его отклонить. Fail также не доказывает подделку: RFC 7960 показывает, как пересылка, псевдонимы и списки нарушают аутентификацию или alignment законной почты.

Реестр IANA DMARC содержит none, quarantine и reject. Это ценная оценка владельца домена, но в ней нет локальной репутации, контекста адресата и последствий ошибки.

Разделы 5.3.6 и 5.4 подчиняют обработку локальной политике. Получатель может принять fail при p=reject или остановить pass по другим данным. RFC советует не отклонять только из-за опубликованного reject, чтобы не ломать законные косвенные потоки. Но исключение способно впустить злоупотребление, поэтому ему нужна собственная причина.

Ошибка DNS — не fail. Если нужные запросы не завершены, результата pass/fail нет и доменная политика неприменима. Отсрочка или другая обработка становятся отдельным локальным решением при неизвестном состоянии.

RFC 9990 предоставляет PolicyOverride для факта и причины отклонения от предпочтения; RFC 8601 сохраняет Authentication-Results. Подробный отчёт RFC 9991 — отдельное необязательное раскрытие, не право распоряжаться письмом.

Минимальная исходная спецификация Heng Lu координирует, не отнимая локальное решение. Слои реальности не позволяют символу стать исполнительной властью; приоритет работающего кода требует показать, что получатель применил фактически.

Точная запись звучит так: эти данные дали такое alignment, домен заявил такое предпочтение, а получатель по этим причинам выбрал такое действие.