DMARC от p=none к p=reject без потери легитимной почты: поэтапное развёртывание (2026)

Опубликовано 2026-07-08

Показатели по состоянию на 2026-06-29 · методология v7. Агрегированные данные переписи по 261 млн оценённых доменов. См. как мы выставляем оценки.

Переводите DMARC от p=none к p=reject в четыре этапа: 2–4 недели мониторинга отчётов rua, исправление каждого легитимного отправителя, наращивание p=quarantine через pct, затем reject — никогда не прыгайте сразу на reject. 70 368 600 из 261 086 232 оценённых доменов застряли на мягком SPF без принудительного DMARC — по данным переписи Defaults.Exposed.

Это операционный runbook: таблица этапов с критериями выхода, запись для каждого этапа, тонкость pct из RFC 7489, меняющая смысл «50%» на уровне reject, и тег sp= для поддоменов. Если вы ещё решаете, стоит ли включать принудительное применение, сначала прочитайте 6 стадий зрелости DMARC — это концептуальная рамка; а если сами уровни политики для вас новы, начните с введения что на самом деле означают p=none, p=quarantine и p=reject. Эта страница — про то, как делать.

Почему нельзя прыгнуть сразу на p=reject?

Потому что p=reject велит каждому соблюдающему политику получателю отбрасывать почту, не прошедшую DMARC, — а пока вы не изучили свои отчёты, вы не знаете, что именно не проходит. Почти каждый домен, включивший мониторинг, обнаруживает забытых легитимных отправителей: CRM, инструмент выставления счетов, контактную форму. Прыгните на reject в первый же день — и эта почта не попадёт в спам; она исчезнет на этапе SMTP. Потеря партии счетов учит организацию бояться DMARC, и запись откатывают на p=none навсегда — из 261 086 232 оценённых доменов ровно там застряли 37 312 637, и лишь 10,59% (27 640 987) вообще доходят до принудительной политики.

Вторая причина — выравнивание. DMARC проходит, только когда SPF или DKIM проходит и выравнивается с видимым доменом From: SPF — по домену Return-Path (RFC5321.MailFrom), DKIM — по d= подписи. Сторонние отправители обычно проходят SPF на своём домене, а не на вашем, поэтому этап «исправить все источники» — это в основном включение у каждого вендора DKIM для собственного домена; подробно разобрано в руководстве DMARC не проходит, а SPF и DKIM проходят.

Каковы четыре этапа развёртывания?

Этап	Запись политики	pct	Что происходит с непрошедшей почтой	Критерии выхода
1. Мониторинг	`p=none; rua=mailto:…`	—	Доставляется как обычно; вы получаете агрегированные отчёты	2–4 недели отчётов; каждый отправитель в них определён как легитимный или нет
2. Исправление источников	`p=none` (без изменений)	—	По-прежнему доставляется как обычно	Каждый легитимный источник проходит DMARC с выравниванием (DKIM для собственного домена у каждого отправителя); остаются только неизвестный/поддельный трафик
3. Наращивание quarantine	`p=quarantine`	10 → 25 → 50 → 100	Выборочная доля уходит в папки спама; невыбранная доля обрабатывается как p=none (доставляется)	1–2 недели на pct=100 без единого легитимного письма в карантине
4. Reject	`p=reject`	100	Отклоняется на этапе SMTP; отправитель получает возврат, получатель не видит ничего	Постоянно — держите `rua` включённым навсегда, чтобы ловить новых отправителей

Данные по состоянию на 2026-06-29; поведение политики — по RFC 7489.

Этап 3 — то место, где домены застревают или паникуют. Попадание в спам обратимо: пользователи находят письмо, вы ослабляете pct, чините источник. Отклонение необратимо — поэтому чистая работа quarantine на pct=100 и есть входной билет на этап 4.

Как провести развёртывание, шаг за шагом?

Запустите бесплатное сканирование на defaults.exposed, прежде чем трогать DNS. Оно подтверждает вашу текущую политику и наличие SPF и DKIM в основе — двух опор, на которых стоит принудительное применение.
Включите мониторинг, если ещё не включили. Публикация p=none с rua= — пятиминутный шаг из руководства «DMARC policy not enabled». Собирайте отчёты 2–4 недели — достаточно, чтобы поймать ежемесячных отправителей вроде рассылок счетов.
Проведите инвентаризацию всех источников из отчётов. Рассортируйте отправителей на ваших, ваших вендоров и неизвестных. Сырые отчёты приходят в XML — инструмент обработки отчётов (или панель вашего провайдера) превращает их в читаемый список отправителей.
Добейтесь выровненного прохождения от каждого легитимного источника. Включите у каждого вендора DKIM для собственного домена (обычно две CNAME-записи в его панели), чтобы подписи несли ваш домен, а не его. Для выравнивания предпочитайте DKIM: он переживает пересылку, а SPF — нет.
Дождитесь чистых двух недель. Выходите из этапа 2, только когда все отмеченные в отчётах сбои — исключительно трафик, который вы не узнаёте, то есть тот самый спуфинг, который вы хотите блокировать.
Перейдите на p=quarantine; pct=10 — отредактируйте существующую TXT-запись _dmarc (разобранный пример: настройка DMARC на IONOS) и следите за синтаксисом: опечатка в теге политики может полностью обесценить запись. Поднимайте pct до 25, 50, 100 за 2–4 недели, следя за отчётами и обращениями в поддержку. Что-то легитимное в спаме: опустите pct, почините источник, продолжайте.
Перейдите на p=reject после 1–2 чистых недель на pct=100. Оставьте rua= включённым навсегда — каждый новый инструмент, который заведёт ваша компания, — это будущий непроходящий отправитель.

Что на самом деле делает pct? Тонкость RFC 7489

pct просит получателей применять вашу политику к указанному проценту непрошедшей почты. Тонкость из RFC 7489 §6.6.4: почта, не попавшая в выборку, не возвращается к «доставить как обычно» — к ней применяется следующая по мягкости политика. При p=quarantine; pct=25 остальные 75% обрабатываются как p=none и доставляются. Но при p=reject; pct=50 остальные 50% попадают в карантин, а не доставляются. Мягкого reject не существует: как только ваша запись говорит reject, каждое непрошедшее сообщение как минимум попадает в спам у соблюдающих политику получателей.

Использованное осознанно, это преимущество: p=reject; pct=1 ведёт себя как «почти всё в карантин, отклонять по капле» — вполне законный финальный трамплин. Две оговорки: получатели реализуют выборку не одинаково, поэтому относитесь к pct как к грубой ручке; и уберите тег (или установите pct=100), когда этап 4 стабилен, чтобы запись говорила именно то, что вы имеете в виду.

А что с поддоменами — тег sp=?

По умолчанию поддомены наследуют политику организационного домена: p=reject на yourdomain.com покрывает и mail.yourdomain.com. Тег sp= позволяет им расходиться — как в полезную, так и в опасную сторону. Полезно: p=quarantine; sp=reject запирает поддомены, с которых вы никогда не отправляете, пока корневой домен ещё в середине наращивания — спуферы намеренно целятся в поддомены доменов, находящихся под мониторингом. Опасно: забытый sp=none молча выводит все поддомены из-под политики reject, которую вы шесть недель зарабатывали. Проверьте его на этапе 4; если одному поддомену действительно нужна более мягкая политика, опубликуйте запись _dmarc на этом поддомене вместо того, чтобы ослаблять все.

Означает ли NIS2, что бизнесу в ЕС это обязательно?

DMARC работает одинаково везде — на границе ЕС в этом runbook ничего не меняется. Меняется давление комплаенса. Статья 21(2)(j) NIS2 требует от подпадающих под неё организаций защищать свои коммуникации, а Имплементационный регламент Комиссии (ЕС) 2024/2690 детализирует технические требования для охватываемых им субъектов цифровой инфраструктуры: его Приложение (пункт 6.7.2(k)) требует плана внедрения международно согласованных современных стандартов безопасности электронной почты, а пункт 6.7.2(l) — лучших практик безопасности DNS. Принудительная политика DMARC с SPF и DKIM в основе — признанный аудируемый контроль против спуфинга; p=none — это демонстративно мониторинг, а не защита. Если ваши клиенты подпадают под регулирование, их анкеты для поставщиков всё чаще спрашивают именно это.

Часто задаваемые вопросы

Сколько времени занимает всё развёртывание? Обычно шесть–десять недель: 2–4 недели мониторинга, 1–3 недели исправления источников, 2–4 недели наращивания quarantine, затем reject. Это календарное время, а не трудозатраты — в основном ожидание отчётов, подтверждающих каждое изменение. 89,41% из 261 086 232 оценённых доменов без принудительной политики (данные по состоянию на 2026-06-29) по большей части не находятся в середине развёртывания — они так и не запустили отсчёт.

Можно ли пропустить quarantine и использовать p=reject с низким pct? Можно — по RFC 7489 §6.6.4 p=reject; pct=10 означает 10% отклонённых и 90% в карантине, примерно поздний этап 3. Но начинать с p=quarantine проще для понимания, а получатели по-разному честно реализуют выборку. В любом случае этапы 1–2 неоспоримы: никакой вариант принудительного применения не безопасен, пока легитимные отправители всё ещё не проходят проверку.

А как быть с почтой, которую я не могу починить, — пересыльщиками и списками рассылки? Пересылка ломает SPF по самой своей природе, а некоторые списки рассылки переписывают содержимое, ломая и DKIM. Выровненный DKIM переживает обычную пересылку, что закрывает большую часть проблемы; небольшой остаток — как раз то, ради чего существует этап quarantine: почта в папке спама обратима, пока вы разбираетесь. Подробности в руководстве пересланная почта не проходит SPF.

Достаточно ли остановиться на p=quarantine? Это большая часть пользы, и это намного лучше, чем у 37 312 637 доменов, застрявших на p=none (из 261 086 232 оценённых, данные по состоянию на 2026-06-29), — но поддельная почта всё ещё попадает в папки спама, откуда люди её вылавливают. Reject — это конечная точка: лишь 10,59% оценённых доменов вообще применяют политику принудительно, и именно завершение засчитывают проверяющие сервисы, страховщики и анкеты.

Отправьте владельцу отчёт

Если вы проводите это развёртывание для клиента или работодателя, финиш можно показать. Когда p=reject начнёт резолвиться, повторно запустите бесплатное сканирование и перешлите отчёт с оценкой: домен, переходящий на принудительную политику, с отметкой времени и простым языком. Эта одна страница отвечает на пункт о безопасности почты в продлениях киберстраховки и анкетах поставщиков, продиктованных NIS2, лучше, чем скриншот DNS-панели, — и делает шесть недель аккуратной, невидимой работы видимыми для того, кто за неё платит.

Проверьте свою политику DMARC бесплатно

Узнайте, какая у вас сейчас политика — и способны ли SPF и DKIM нести принудительное применение — конфиденциально и только для владельца.

Проверьте свой домен → · Исправить DMARC → · «DMARC policy not enabled» — честный первый шаг → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.