DMARC после RFC 9989: изменения стандарта в 2026 году

В мае 2026 года опубликован RFC 9989 — новая основная спецификация Domain-Based Message Authentication, Reporting, and Conformance (DMARC). Документ заменил RFC 7489 и экспериментальный RFC 9091, переведя протокол из категории Informational в Standards Track со статусом Proposed Standard.

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

Для владельца обычного домена переход не обязательно требует немедленной замены существующей записи. Основные значения p=none, p=quarantine и p=reject, адреса агрегированных отчётов и режимы alignment сохранились. Главный практический вопрос — одинаково ли старые и новые реализации определят применимую политику, особенно при сложной иерархии поддоменов.

Что именно стандартизирует RFC 9989

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

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

DMARC добавляет требование alignment — организационной или точной связи между доменом автора и доменом, успешно проверенным через SPF либо DKIM. В результате протокол решает четыре связанные задачи:

• определяет домен, использование которого требуется проверить;
• находит применимую политику DMARC;
• сопоставляет домен автора с прошедшими SPF и DKIM идентификаторами;
• передаёт получателю предпочтение владельца домена и при необходимости формирует данные для отчётности.

RFC 9989 подчёркивает границы этой модели. Успешный DMARC не означает, что письмо безопасно, полезно или действительно написано конкретным сотрудником. Он подтверждает только то, что использование домена From авторизовано его владельцем. Поэтому результат DMARC остаётся одним из сигналов для антиспам-системы, а не самостоятельным сертификатом доверия к содержимому.

Базовая модель проверки сохранилась

Письмо получает результат DMARC pass, если хотя бы один поддерживаемый механизм аутентификации одновременно успешно проверен и выровнен с доменом автора. Иными словами, используется логическое «или»:

• SPF завершился успешно для домена MAIL FROM, и этот домен имеет alignment с доменом From;
• либо проверена хотя бы одна DKIM-подпись, домен d= которой имеет alignment с доменом From.

Успешное прохождение обоих механизмов не является формальным условием DMARC pass, хотя RFC рекомендует владельцам доменов по возможности обеспечивать оба выровненных идентификатора. Это повышает устойчивость доставки: например, пересылка часто разрушает SPF, тогда как сохранившаяся DKIM-подпись может продолжить подтверждать домен.

В части SPF стандарт рассматривает только идентификатор MAIL FROM. Результат проверки домена HELO или EHLO сам по себе не обеспечивает прохождение DMARC. При пустом обратном пути, характерном для уведомлений о недоставке, SPF определяет соответствующий идентификатор по собственным правилам, но общая логика alignment не меняется.

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

Строгий и ослабленный alignment

Стандарт сохраняет два режима сопоставления идентификаторов. При strict alignment домены должны полностью совпадать. Например, mail.example.com и example.com считаются разными.

При relaxed alignment достаточно, чтобы оба имени относились к одному Organizational Domain. Поэтому news.example.com и bounce.example.com могут быть выровнены, если алгоритм DMARC определяет для них общий организационный домен example.com. Сравнение доменных имён выполняется без учёта регистра.

Именно определение Organizational Domain стало одной из наиболее заметных частей обновления. В прежней модели оно было связано со списком публичных суффиксов, а RFC 9989 заменил этот подход поиском по дереву DNS.

DNS Tree Walk вместо зависимости от Public Suffix List

RFC 7489 предлагал определять организационный домен с помощью Public Suffix List (PSL). Такой список помогает отличить регистрируемый домен от публичного суффикса: например, понять, где проходит административная граница в именах под .com или .co.uk.

Проблема заключалась в том, что стандарт не устанавливал единый обязательный PSL и порядок его обновления. Два почтовых получателя могли использовать разные версии списка и получить разные Organizational Domain, а следовательно, по-разному оценить relaxed alignment или найти разные политики.

RFC 9989 вводит DNS Tree Walk — последовательный поиск записей DMARC вверх по иерархии доменного имени. Сначала получатель всегда проверяет политику непосредственно для Author Domain. Если там нет подходящей записи, поиск продолжается на родительских уровнях, чтобы обнаружить организационный домен или политику публичного суффикса.

Приоритет найденных политик сформулирован однозначно:

1. политика непосредственно Author Domain;
2. политика Organizational Domain;
3. политика Public Suffix Domain.

Такой подход позволяет определять административные границы средствами самой DNS и размещать политики на нескольких уровнях пространства имён. Это особенно важно для крупных организаций с делегированным управлением поддоменами: отдельное подразделение может обозначить свой узел как самостоятельный Organizational Domain и использовать собственные параметры политики и отчётности.

Ограничение числа запросов

Последовательный обход DNS потенциально создаёт нагрузку. Злоумышленник мог бы отправлять сообщения с искусственно глубокими доменными именами, вынуждая получателей выполнять десятки или сотни запросов для каждого письма. Поэтому RFC 9989 ограничивает Tree Walk восемью DNS-запросами независимо от числа меток в имени.

Для обычных доменов это ограничение незаметно. Оно становится существенным в глубоко вложенных корпоративных пространствах имён. Политика на промежуточном уровне может не попасть в окно из восьми запросов, если Author Domain содержит слишком много компонентов. В таком случае стандарт требует учитывать прямую запись для Author Domain: она проверяется до начала обхода и потому не теряется из-за лимита.

Для почтового администратора вывод состоит не в необходимости немедленно менять DNS, а в пересмотре предположений о наследовании. Если почта отправляется от очень глубоких поддоменов, нельзя автоматически считать, что все новые получатели обнаружат промежуточную политику так же, как её находили реализации на основе PSL.

Новые теги np, psd и t

RFC 9989 добавил три тега, отражающие новую модель поиска политики и накопленный опыт эксплуатации DMARC.

Политика для несуществующих поддоменов np

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

Существование домена определяется ответом DNS, а не наличием у него MX, A или AAAA. Ответ NXDOMAIN означает, что имени нет. Ответ NODATA означает, что запрошенной записи определённого типа нет, но само доменное имя существует. Это различие важно: np предназначен именно для несуществующих имён и не заменяет политику существующих поддоменов.

Если np отсутствует, для несуществующего поддомена наследуется sp, а при отсутствии sp — основная политика p. Таким образом, новый тег даёт более точный контроль, но не является обязательным условием защиты таких имён.

Обозначение публичного или организационного домена через psd

Тег psd участвует в определении административной границы во время Tree Walk. Значение psd=y указывает, что запись опубликована оператором Public Suffix Domain. Домен уровнем ниже такого суффикса рассматривается как Organizational Domain.

Значение psd=n позволяет явно сообщить, что узел не является публичным суффиксом и представляет собой организационный домен для себя и своих поддоменов. Это полезно при делегированном управлении внутри большой организации, а также как защита от неверной интерпретации вышестоящей записи.

По умолчанию используется неопределённое состояние: запись не объявляет домен публичным суффиксом, но и не подтверждает, что это окончательная организационная граница. Тогда получатель продолжает применять алгоритм Tree Walk.

Механизм заменяет экспериментальный подход RFC 9091. Отдельный реестр PSD DMARC больше не нужен: обнаружение политики публичного суффикса встроено в общий обход DNS. По этой причине RFC 9989 одновременно отменяет RFC 7489 и RFC 9091.

Тестовый режим t

Тег t служит сигналом тестового режима. Он позволяет владельцу домена сообщить, следует ли фактически применять объявленную политику для сообщений, не прошедших DMARC. При этом тег не отключает формирование отчётов и не меняет смысл политики none.

Новый механизм заменяет часть сценариев, для которых ранее неформально использовали pct=0. Важно учитывать, что окончательная обработка всё равно определяется локальными правилами принимающей системы: публикация любого DMARC-тега выражает предпочтение владельца домена, но не является безусловной командой чужому почтовому серверу.

Почему удалён тег pct

В RFC 7489 тег pct предназначался для постепенного применения политики к указанному проценту сообщений. Предполагалось, что владелец сможет последовательно переводить трафик от наблюдения к карантину и отклонению, ограничивая долю писем, к которой применяется более строгий режим.

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

В RFC 9989 pct удалён. Совместимая с новым стандартом система не должна использовать его для выборочного enforcement. Если старая запись содержит действующую политику и pct, новый получатель проигнорирует неизвестный или исключённый тег, но продолжит обрабатывать остальные корректные параметры. Практическое следствие очевидно: рассчитывать на pct=10 как на ограничение действия p=reject после перехода экосистемы на RFC 9989 нельзя.

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

Что изменилось в отчётности

RFC 9989 сохраняет отчётность как одну из основных функций DMARC, но её подробное описание вынесено в отдельные спецификации. Агрегированные отчёты определяются RFC 9990, а отчёты о конкретных сбоях — RFC 9991 и связанными документами для SPF и DKIM.

В основной записи остались знакомые назначения:

• rua запрашивает агрегированные отчёты;
• ruf запрашивает отчёты о конкретных случаях отказа;
• fo описывает условия, при которых запрашивается отчёт о сбое.

Если rua не указан, получатель не должен формировать агрегированные отчёты для домена. Аналогично отсутствие ruf означает, что отчёты об отдельных сбоях отправлять не следует. При наличии нескольких адресов стандарт рекомендует отправлять отчёт по каждому указанному URI, хотя получатель сохраняет возможность применять собственные ресурсные и защитные ограничения.

Из набора тегов удалены ri, задававший желаемый интервал агрегированной отчётности, и rf, задававший запрашиваемый формат отчёта о сбое. Также исключена возможность указывать максимальный размер отчёта в URI.

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

Отчёты об отдельных сообщениях остаются необязательными. Они полезны при диагностике, но потенциально содержат чувствительные данные. Поэтому многие операторы либо сильно сокращают их содержимое, либо не отправляют вовсе. Владельцу домена не следует строить мониторинг так, будто ruf обеспечивает полный поток событий. Основным источником общей картины остаются агрегированные данные. Подробнее о разборе таких данных читайте в материале как читать агрегированные DMARC XML-отчёты.

Политика домена не является приказом получателю

RFC 9989 использует более точный термин Domain Owner Assessment Policy — предпочтение владельца домена по оценке писем, которые не прошли DMARC. Значения политики сохранились:

• none — владелец не выражает предпочтения по специальной обработке;
• quarantine — письмо следует считать подозрительным;
• reject — владелец считает использование домена неавторизованным.

Если тег p отсутствует в синтаксически корректной записи, она трактуется как p=none. Однако итоговое решение всегда остаётся за Mail Receiver. Получатель может пропустить письмо с DMARC fail вопреки p=reject либо, наоборот, заблокировать письмо с DMARC pass по результатам антиспам-проверок, репутационного анализа или проверки содержимого.

Стандарт отдельно рекомендует не отклонять сообщения только на основании DMARC fail и опубликованного p=reject. Получателю следует учитывать контекст, сведения о маршруте и известные особенности непрямой доставки. Это не обесценивает строгую политику: она остаётся сильным сигналом, но больше не описывается как достаточная причина для автоматического решения во всех ситуациях.

Ошибки DNS также не следует превращать в DMARC fail. Если обязательные запросы не завершились из-за временной или постоянной ошибки и политику нельзя надёжно получить, сообщение не считается ни прошедшим, ни провалившим проверку DMARC. Политика владельца в такой ситуации неприменима, а дальнейшая обработка определяется получателем.

Непрямая доставка: пересылка и почтовые рассылки

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

Обычная пересылка

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

DKIM в таком сценарии устойчивее: если посредник не изменил подписанные заголовки и тело, исходная подпись остаётся валидной и может обеспечить DMARC pass. Поэтому домены с p=reject, согласно RFC 9989, не должны полагаться только на SPF и обязаны использовать корректные DKIM-подписи для своих сообщений.

Списки рассылки

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

Списки применяют разные меры совместимости: меняют поле From, подписывают сообщение своим доменом, используют собственный обратный путь или передают сведения о предыдущих проверках. Каждая мера имеет компромиссы. Например, изменение From помогает доставке, но меняет видимое авторство и может влиять на ответы пользователя.

ARC способен сохранить заверенную цепочку результатов аутентификации через посредников. Однако ARC не превращает формальный DMARC fail в pass. Он даёт конечному получателю дополнительный сигнал, на основании которого тот может осознанно отступить от опубликованного p=reject.

Более строгая рекомендация для доменов общего назначения

RFC 9989 прямо предупреждает: домены, пользователи которых отправляют обычную почту и участвуют в интернет-рассылках, не должны публиковать p=reject без оценки последствий. Строгая политика лучше подходит доменам с контролируемыми потоками, где заранее известны все отправители, а участие адресов в произвольных списках рассылки не предполагается.

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

Переходный период между старыми и новыми реализациями

Самая вероятная практическая сложность после публикации RFC 9989 — одновременная работа получателей на разных версиях DMARC. Старый сервер может продолжать использовать PSL по правилам RFC 7489, а новый — выполнять DNS Tree Walk. В нетипичной иерархии они способны определить разные Organizational Domain, по-разному оценить relaxed alignment или выбрать разные унаследованные политики.

Риск выше в следующих случаях:

• почта отправляется от глубоко вложенных поддоменов;
• управление DNS делегировано нескольким подразделениям;
• политика рассчитывает на сложное наследование от родительского домена;
• административная граница не совпадает с границей, ожидаемой старым PSL;
• используются удалённые теги pct, ri или rf.

Наиболее однозначный вариант для важных почтовых потоков — явная политика на каждом реально используемом Author Domain. Она проверяется до Tree Walk и снижает зависимость от способа определения организационной границы. Strict alignment также устраняет часть расхождений, поскольку требует точного совпадения доменов, но может оказаться слишком жёстким для инфраструктуры с отдельными поддоменами возвратов и DKIM-подписей.

Что владельцу домена стоит проверить в 2026 году

RFC 9989 не требует бездумно переписывать каждую DMARC-запись. Проверка должна начинаться с архитектуры почтовых потоков и ожиданий, которые были заложены в прежнюю конфигурацию.

• Удалённые теги. Если управление риском опирается на pct, следует считать, что новые реализации его игнорируют. ri больше не управляет периодичностью, а rf — форматом отчёта.
• Иерархия доменов. Нужно определить, где политики находятся относительно реальных доменов From и будут ли они обнаружены в пределах Tree Walk.
• Смысл Organizational Domain. Для сложных делегированных зон следует проверить, одинаково ли предполагаемую границу поймут реализации RFC 7489 и RFC 9989.
• Несуществующие поддомены. Стоит решить, достаточно ли наследования p или sp, либо требуется отдельное предпочтение np.
• Отчётность. Системы обработки должны принимать отсутствие части отчётов как нормальное состояние и не ожидать соблюдения ранее заданного ri.
• Непрямая доставка. Перед строгой политикой необходимо оценить пересылки, рассылки и внешние сервисы, а не только прямые отправки организации.
• Дублирование SPF и DKIM. Для устойчивости желательно, чтобы хотя бы один выровненный DKIM-идентификатор сохранялся там, где пересылка нарушает SPF.

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

Главный итог RFC 9989

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

DNS Tree Walk устраняет нормативную зависимость от внешнего Public Suffix List и объединяет обычное и PSD-обнаружение политики. Теги np, psd и t отражают новую модель, а pct, ri и rf исключены как непоследовательно реализованные или перенесённые за пределы основной спецификации. Отчётность остаётся критически важной, но теперь описывается отдельными RFC и не гарантируется каждым получателем.

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