Кратко

  • DMARC выдаёт pass, когда хотя бы один домен, аутентифицированный SPF или DKIM, выровнен с доменом RFC5322.From. Это подтверждает разрешённое использование Author Domain, но не local-part, отображаемое имя, человека или содержание.
  • fail не является обратным доказательством мошенничества. Законная пересылка или список рассылки могут разрушить SPF-выравнивание либо DKIM-подпись по пути.
  • p, sp и np — запрошенные предпочтения обработки. Получатель сохраняет локальное решение и может отклонить прошедшее письмо либо принять не прошедшее после анализа других данных.

Два владельца и один результат на границе

Владелец домена управляет своими DNS-записями, отправляющей инфраструктурой и ключами. Получатель управляет очередью, фильтрами, репутацией и последствиями доставки. DMARC переносит проверяемый сигнал через эту границу, но не переносит управление.

RFC 9989 опубликована в мае 2026 года как Standards Track и заменяет RFC 7489 и 9091. Её совместно редактировали Todd M. Herr и John Levine. Документ формулирует предел раньше подробностей: pass показывает только то, что использование Author Domain было проверено как разрешённое его владельцем. Такое разрешение не выражает оценку письма или владельца и не гарантирует, что доставка во входящие безопасна или желательна.

Это не осторожная приписка. Это контракт результата. Любая более широкая надпись требует другой доказательной цепочки.

Что именно сравнивает DMARC

SPF проверяет, разрешено ли подключившемуся узлу использовать домен в SMTP MAIL FROM или HELO; DMARC берёт домен MAIL FROM. DKIM проверяет подпись и домен d=, связанный с покрытыми частями сообщения. Оба механизма могут пройти, не имея отношения к домену в видимом From.

DMARC извлекает Author Domain из RFC5322.From. Строгое выравнивание требует полного совпадения с аутентифицированным доменом. Нестрогое требует общего Organizational Domain. Владелец выбирает режим тегами aspf и adkim; RFC 9989 отмечает, что почти всем владельцам на практике достаточно нестрогого режима.

Достаточно одного прошедшего и выровненного идентификатора. Среди нескольких DKIM-подписей одна может обеспечить pass, даже если другая недействительна. SPF пересыльщика может пройти для его домена, но не дать DMARC-выравнивания с исходным From.

Полная квитанция поэтому называет наблюдателя, время, механизм, домен и режим сравнения. В ней нет утверждения о человеке за клавиатурой.

Local-part, имя и текст остаются неподтверждёнными

В адресе, где локальная часть director соединена с доменом example.com, DMARC обрабатывает example.com. Он не подтверждает director, существование ящика, должность или контролирующего его человека. RFC 9989 прямо исключает проверку local-part.

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

Анализ содержания находится вне задачи. Захваченная легальная учётная запись способна отправить вредоносную ссылку через разрешённую систему. Атакующий может аутентифицировать собственный домен без единой ошибки. Вложение, платёжные реквизиты, смысл просьбы и её пригодность для адресата требуют репутации, проверки контента, контроля аккаунта и бизнес-подтверждения.

Если опасное письмо прошло DMARC, сам протокол мог сработать правильно. Ошибка может находиться в слое, который должен был ответить на другой вопрос.

Законный маршрут может стереть исходное доказательство

RFC 7960 разбирает непрямые потоки. Пересыльщик, сохранивший исходный MAIL FROM, подключается с IP, которого нет в SPF отправителя. Если он заменит MAIL FROM своим доменом, SPF может пройти, но выравнивание с исходным RFC5322.From пропадёт.

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

Поэтому RFC 9989 намеренно говорит, что fail не обязательно означает отсутствие связи с Author Domain. Результат описывает доступные доказательства в конечной точке, а не восстанавливает весь маршрут и не определяет намерение.

Автоматическое толкование порождает симметричные потери: прошедшее вредоносное письмо получает лишнее доверие, а законное письмо после посредника исчезает как мошенническое.

Политика в DNS заканчивается до локального действия

Поиск начинается с Author Domain, затем переходит к Organizational Domain и Public Suffix Domain. Место записи и существование поддомена определяют применение p, sp или np. Реестр IANA называет их запрошенными политиками оценки; старые pct, rf и ri отмечены как исторические.

Запрос не является командой. RFC 9989 всегда оставляет финальную обработку локальной политике Mail Receiver. Получатель вправе изолировать или отклонить pass по другим данным. Он вправе принять fail даже при p=reject, если знает законный непрямой путь. Документ рекомендует не отклонять только из-за опубликованного reject, чтобы не разрушать легальную пересылку и списки.

Ошибка DNS подчёркивает границу. Без завершённых запросов нет pass или fail, а политика владельца не применяется. Доставить, временно отказать или выбрать иной путь решает получатель.

В The Policy Mirror Heng Lu предлагает проверять, защищает ли общая норма необходимый технический инвариант или присваивает решение, за риск которого отвечает другой оператор. RFC нормативно опирается на IETF, но этот вопрос точно описывает её устройство: удалённый домен делает пожелание читаемым, не получает доступ к чужой очереди.

Запрос отчёта не создаёт полного журнала

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

URI в записи подтверждает желание получать данные. Полученный отчёт подтверждает наблюдения одного участника за период. Он не доказывает глобальное покрытие, выполнение reject или судьбу каждого письма.

Переход от наблюдения к карантину и отказу требует инвентаризации источников, тестов пересылки и списков, оценки покрытия и заранее определённого отката. DNS-строка не заменяет операционную подготовку.

Todd Herr как соавтор границы, а не владелец системы

Снимок IETF Datatracker от 1 сентября 2026 года связывает публичный профиль Todd Herr с RFC 9989 и ролью рецензента ART Area Review Team. Официальная фотография подтверждает визуальную идентичность. RFC указывает Herr из Valimail и соредактора John Levine из Standcore LLC; благодарности сохраняют вклад группы DMARC и ранней отраслевой работы.

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

Журнал без скрытого наследования

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

Авторизация домена не наследует личность. Выравнивание не наследует истинность текста. Pass не наследует безопасность. Удалённое предпочтение не наследует выполнение. SMTP-приём не наследует место во входящих, а входящие не наследуют отсутствие вреда.

В этих пределах DMARC остаётся сильным: мешает точной подделке домена, создаёт устойчивый объект репутации и возвращает сведения о потоках. Доказательство становится надёжнее, когда ему не поручают судить о том, чего оно не наблюдало.

Источники