DMARC стал интернет-стандартом. Что RFC 9989 на самом деле меняет в вашем DNS

Большинство компаний настраивают запись DMARC один раз, обычно потому что этого потребовала маркетинговая платформа, и больше к ней не возвращаются. В мае 2026 года IETF опубликовал RFC 9989, который заменил исходную спецификацию DMARC 2015 года. В тот день в вашем DNS ничего не сломалось, и срочных правок не требуется. Но три тега из типичной записи официально устарели, механизм, по которому принимающие серверы находят вашу политику, заменён полностью, а рекомендация по самой строгой политике развернулась в обратную сторону. Если запись писали пять лет назад, часть её описывает протокол, которого в таком виде больше нет.

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

В мае 2026 года IETF опубликовал три документа: RFC 9989 (основной протокол DMARC), RFC 9990 (агрегированные отчёты) и RFC 9991 (отчёты об ошибках). Вместе они отменяют RFC 7489 и RFC 9091. RFC 7489 вышел в 2015 году как документ категории Informational — описание того, что делала индустрия, а не стандарт IETF. RFC 9989 находится на Standards Track, в статусе Proposed Standard. Одиннадцать лет DMARC был широко внедрённой договорённостью с неоднозначностями, которые каждый вендор трактовал по-своему. Теперь за ним стоит формальный консенсус. Что не изменилось: записи по-прежнему начинаются с v=DMARC1. Никакого DMARC2 нет. Неизвестные теги получатели обязаны игнорировать, поэтому любая запись, работающая сегодня, продолжит работать. Это уборка, а не миграция.

2. Три тега в вашей записи больше не работают

Реестр тегов DMARC в IANA обновлён. Три тега помечены как historic — признаны устаревшими и не должны встречаться в актуальных реализациях:

• pct (частота выборки). Тег, позволявший применять политику к части писем, не прошедших проверку, исчез. Причины удаления изложены в приложении A.6 к RFC 9989.
• rf (формат отчётов об ошибках).
• ri (интервал агрегированных отчётов). Принимающие серверы в любом случае должны формировать отчёты не реже раза в 24 часа.

Вместо них появился зарегистрированный тег t: тестовый режим политики DMARC со значениями y или n и значением по умолчанию n. Значение t=y просит получателя применять уровень ниже заявленной политики. p=reject; t=y → обрабатывается как quarantine. p=quarantine; t=y → обрабатывается как none. Это замена тому, как раньше через pct разбивали внедрение на этапы. Ещё два активных недоиспользуемых тега: np (политика для несуществующих поддоменов) и psd (объявляет домен публичным суффиксом).

3. Public Suffix List исчез, вместо него DNS Tree Walk

Это самое крупное техническое изменение в спецификации. По RFC 7489 получатели использовали Public Suffix List, чтобы вычислить организационный домен отправителя. Старая спецификация не предписывала конкретный список, не давала указаний, как часто его обновлять, и признавала, что разные получатели с разными списками дадут несогласованный результат. RFC 9989 заменяет это механизмом DNS Tree Walk. Получатель сначала запрашивает _dmarc на уровне Author Domain. Если валидной записи нет, он поднимается по пространству имён на одну метку за раз, максимум восемь запросов. Два практических следствия:

1. Если вы отправляете с домена, где больше восьми меток, публикуйте запись ровно на этом имени. Запись на промежуточном zone cut обход просто не найдёт.
2. Крупные организации с децентрализованным DNS получают инструмент. Публикация psd=n на поддомене объявляет его собственным организационным доменом, поэтому отдел может вести свою политику, не трогая запись на апексе.

Общее правило не изменилось: публикуйте явные записи DMARC на тех доменах, с которых вы реально отправляете.

4. Рекомендация по p=reject развернулась

Годами стандартный совет звучал так: провести каждый домен от p=none к p=quarantine и дальше к p=reject. RFC 9989 заметно осторожнее, и эта осторожность нормативная:

• Домены, на которых работают пользователи, способные писать в почтовые рассылки, не должны публиковать p=reject. Списки рассылки и пересылка регулярно ломают выравнивание SPF, а политика reject приводит к автоматической отписке пользователей.
• Домены, которые всё же публикуют p=reject, не должны полагаться только на SPF и обязаны подписывать письма валидным DKIM. Подписи DKIM обычно переживают пересылку. SPF — обычно нет.
• Принимающие серверы не должны отклонять письмо только на основании того, что домен опубликовал p=reject. При отсутствии другого анализа следует обращаться с такой почтой как с quarantine.
• Для перехода на reject: публикуйте p=none минимум месяц, затем p=quarantine столько же, и сравните результаты перед решением.

Это не отступление. Это признание того, что одиннадцать лет показали: reject наносит побочный урон непрямым потокам почты.

5. Что требуют почтовые провайдеры — отдельный вопрос

RFC описывает протокол. Google, Yahoo и Microsoft описывают условия, при которых ваши письма доходят до их пользователей. Google: с февраля 2024 года отправители более 5000 писем в сутки на личные аккаунты Gmail обязаны иметь и SPF, и DKIM, запись DMARC на отправляющем домене (none допустимо), выравнивание поля From, отписку в один клик и долю спама ниже 0,3%. С ноября 2025 года Google усилил применение мер, включая временные и постоянные отказы в доставке. Microsoft: действует с 5 мая 2025 года: домены, отправляющие более 5000 писем в сутки на outlook.com, hotmail.com и live.com, должны иметь SPF, DKIM и DMARC минимум с p=none. Несоответствующая почта сначала уходит в Junk, следующий шаг — отказ с 550 5.7.515 Access denied. Yahoo предъявляет эквивалентные требования. RFC снижает градус вокруг p=reject, а провайдеры поднимают нижнюю планку по наличию аутентификации. Противоречия нет. Публикуйте записи везде, аутентифицируйте всерьёз обоими механизмами и подходите к уровню политики осознанно.

6. Две ловушки SPF, которые спецификация называет прямо

Hard fail прячет от вас проблемы. Если ваша запись SPF заканчивается на -all, получатель может отклонить письмо на раннем этапе SMTP-сессии, до того как DMARC вообще будет вычислен. Сессия не доходит до фазы DATA, домен From не раскрывается, и письмо не попадает в ваши агрегированные отчёты. Письма, которые прошли бы DMARC по выровненной подписи DKIM, отклоняются только по SPF — невидимо для вас. Делегированные поддомены позволяют подделать основной домен. При относительном выравнивании, если атакующий контролирует DNS поддомена вашего организационного домена и публикует там запись SPF, он может отправлять письма с вашим апекс-доменом в поле From и получать DMARC pass. Меры защиты: строгое выравнивание, явные записи DMARC на каждом отправляющем домене, аккуратный контроль делегирования и квалификатор ? для слишком широких источников в SPF.

7. Проверка на 30 минут, которую можно сделать сегодня

# Ваша политика DMARC
dig +short TXT _dmarc.vashdomen.md

# Ваша запись SPF
dig +short TXT vashdomen.md | grep spf1

# Селектор DKIM, если он известен
dig +short TXT selector._domainkey.vashdomen.md

Затем ответьте на шесть вопросов:

1. Есть ли в записи pct, rf или ri? Запланируйте их удаление.
2. Есть ли адрес rua, и разбирает ли кто-нибудь реально приходящие туда отчёты? Адрес для отчётов, который никто не читает, — это не мониторинг.
3. Есть ли собственная запись у всех доменов, с которых вы отправляете, включая поддомены для CRM, тикет-системы, выставления счетов и маркетинговых платформ?
4. Публикуют ли припаркованные и неотправляющие домены p=reject; np=reject? Нет потока почты — нет риска для совместимости.
5. Если у вас p=reject, подписан ли DKIM каждый поток писем, или вы опираетесь на SPF?
6. Когда последний раз кто-то читал агрегированный отчёт и что-то по нему сделал?

8. Почему это важно именно в Молдове и Румынии

Статья 21(2) NIS2 требует мер управления рисками и базовой кибергигиены. DMARC она не называет. На практике проверяющие считают SPF, DKIM и DMARC принятой технической реализацией управления риском почтового канала. Публикация записи сама по себе не делает вас соответствующими, а её отсутствие трудно защитить на проверке. Румыния: NIS2 транспонирована через OUG 155/2024, утверждённое Законом 124/2025, который действует с 10 июля 2025 года. Приказы 1 и 2/2025 директора DNSC (Monitorul Oficial № 776 от 20 августа 2025 года) устанавливают порядок регистрации существенных и важных субъектов. Молдова: Закон 48/2023 о кибербезопасности действует с 1 января 2025 года. Постановления Правительства 860/2024 и 562/2025 определяют поставщиков в критических секторах и их обязательства. Персональные данные: Закон 195/2024 вступает в силу 23 августа 2026 года. Подделка домена, закончившаяся мошенническим платежом, — это инцидент безопасности с измерением защиты данных. Одна локальная деталь, которую стоит проверить прежде всего. Большинство компаний в Молдове и Румынии держат Google Workspace или Microsoft 365 для почты сотрудников, а всё остальное отправляют откуда-то ещё: бухгалтерский софт, панель управления хостингом, CRM, системы бронирования. Домен в Workspace обычно аутентифицирован правильно. Ломают выравнивание остальные четыре или пять отправителей, и про их существование никто не вспоминает, пока клиент не скажет, что счёт так и не пришёл.

БЕЗОПАСНОСТЬ · ЗАЩИТА ЭЛЕКТРОННОЙ ПОЧТЫ

Может ли кто-то сегодня отправить письмо от имени вашего домена?

Настройка SPF, DKIM и DMARC в соответствии с RFC 9989, аудит всех систем, которые отправляют письма от вашего имени, мониторинг агрегированных отчётов и поэтапный путь к строгой политике без потери легитимной почты. От 400 EUR.

3 ДНЯ

ПОЛНАЯ СДАЧА

Защитить почту →

Как помогает команда WebDirect

Большинство проблем с аутентификацией почты — это не отсутствующая DNS-запись. Это четыре забытые системы, которые отправляют письма от вашего имени, поддомен, который никто не задокументировал, и политика reject, опубликованная без DKIM за спиной. Команда WebDirect проводит аудит всей поверхности отправки для компаний в Молдове, Румынии и ЕС, приводит записи в соответствие с действующей спецификацией и доводит домены до строгой политики в темпе, который не ломает по дороге счета и сбросы паролей. Если хотите знать, кто сегодня может отправлять письма от имени вашего домена, напишите нам.

Источники

• RFC 9989, DMARC, IETF, май 2026.
• RFC 9990, DMARC Aggregate Reporting, IETF, май 2026.
• RFC 9991, DMARC Failure Reporting, IETF, май 2026.
• Google, Email sender guidelines, support.google.com.
• Microsoft, Outlook's New Requirements for High Volume Senders, апрель 2025.
• Директива (ЕС) 2022/2555 (NIS2), статья 21.
• Румыния: OUG 155/2024, Закон 124/2025, приказы DNSC № 1 и 2/2025.
• Молдова: Закон 48/2023, Постановления Правительства 860/2024 и 562/2025.
• Молдова: Закон 195/2024 о защите персональных данных.

Материал носит информационный характер и не является юридической консультацией.

Частые вопросы

Значит ли RFC 9989, что нужно переписывать запись DMARC?
Нет. Записи по-прежнему начинаются с v=DMARC1 и любая корректная запись продолжит работать. Уберите устаревшие теги pct, rf и ri при следующем изменении DNS и убедитесь, что записи опубликованы на всех доменах, с которых вы отправляете.Что заменило тег pct?
Тег t, тестовый режим политики DMARC. Публикация t=y просит получателей применять политику на уровень ниже заявленной: p=reject; t=y обрабатывается как quarantine, p=quarantine; t=y — как none.Что такое DNS Tree Walk?
Механизм, заменивший Public Suffix List. Получатель запрашивает _dmarc на вашем отправляющем домене, и если валидной записи нет, поднимается по пространству имён на одну метку за раз, максимум восемь запросов. Если домен содержит более восьми меток, опубликуйте запись ровно на этом имени.Стоит ли ставить p=reject?
Только после того, как DKIM настроен на каждом потоке писем, и после разбора агрегированных отчётов. RFC 9989 не рекомендует p=reject для доменов, чьи пользователи пишут в рассылки. Припаркованные домены можно переводить в reject сразу.Действуют ли правила Gmail и Outlook, если мы отправляем несколько сотен писем в день?
Пороги в 5000 писем в сутки определяют, кто обязан соответствовать. Ниже порога аутентификация всё равно проверяется и влияет на попадание в инбокс. Требования разумно считать минимальной планкой, а не потолком.Обеспечивает ли DMARC соответствие NIS2?
Ни один отдельный контроль не обеспечивает соответствие NIS2. Статья 21 не называет DMARC. На практике аутентификация почты считается принятой реализацией управления риском почтового канала.Сколько стоит аудит безопасности электронной почты?
Email Security Hardening (настройка SPF, DKIM, DMARC, меры против фишинга и аудит инфраструктуры) начинается от 400 EUR, срок — 3 рабочих дня.