Від p=none до p=reject без втрати пошти: інженерний рампінг DMARC через p=quarantine
p=reject — це не перемикач, а фініш багатотижневого вимірювання. Розбираємо, чому alignment важливіший за самі SPF/DKIM-записи, і даємо відтворюваний план рампінгу none→quarantine→reject на 6–10 тижнів із читанням RUA-звітів та воротами переходу між фазами.
EvilMail Team13 липня 2026 р.12 хв читання
Класичний сценарій: адмін хоче «зробити пошту безпечною», відкриває DNS, ставить _dmarc у p=reject і йде спати. Наступного ранку служба підтримки завалена: не дійшов лист від платіжного провайдера, HR-розсилка про зарплату впала з 550 5.7.1, а половина команди не отримала пошту, переслану з їхніх старих аліасів. Нічого не «зламалося» — DMARC спрацював рівно так, як його попросили. Просто попросили не те.
p=reject — це не старт захисту, а фініш вимірювання. Це остання дія в процесі, де ви спершу побачили всіх легітимних відправників від свого домену, довели кожного до стану PASS і лише потім увімкнули відмову. Нижче — інженерний план, як пройти шлях none → quarantine → reject за 6–10 тижнів і не втратити жодного справжнього листа.
Що DMARC перевіряє насправді: alignment, а не «просто SPF і DKIM»
DMARC не додає жодної нової криптографічної перевірки. Він бере результати двох уже наявних механізмів — SPF і DKIM — і зшиває їх із доменом, який користувач бачить у полі From:
DMARC рампінг: від p=none до p=reject без втрати пошти | EvilMail — EvilMail Blog
. Ця зшивка називається
alignment
(вирівнювання), і саме вона ламає пошту при переході на reject, а не «неправильні записи».
Правило проходження одне:
DMARC PASS, якщо `(SPF pass AND SPF aligned)` OR `(DKIM pass AND DKIM aligned)`. Достатньо однієї гілки.
SPF alignment — домен у Return-Path (envelope MAIL FROM) збігається з доменом у From:.
DKIM alignment — тег d= у підписі збігається з доменом у From:.
Режим збігу задають теги adkim і aspf: relaxed (значення r) вимагає збігу лише organizational domain (mail.example.com вирівняний із example.com), strict (s) — точного збігу FQDN.
Ось де ховається головна пастка. Лист від Mailchimp чудово проходить SPF — але по домену Mailchimp (servers.mcsv.net), а не по вашому. SPF pass, SPF aligned — fail. Якщо при цьому DKIM не піднятий на вашому домені, DMARC провалюється, хоча технічно «і SPF, і DKIM налаштовані». Тому фраза «у нас усе аутентифіковано» нічого не гарантує, доки ви не перевірили саме вирівнювання.
Фаза 0 — p=none і збір телеметрії
Перший запис нічого не блокує. Це чистий режим спостереження: ви просите приймаючі сервери надсилати вам звіти про те, що вони бачать від вашого домену.
rua — адреса для агрегованих звітів, ruf — для forensic (сьогодні його майже ніхто не шле через приватність, але тег лишаємо). fo=1 каже: звітуй, якщо провалився будь-який із механізмів, а не тільки обидва одразу. Якщо доменів одиниці, rua можна лити у власну скриньку; на масштабі одразу закладайте парсер, бо це десятки gzip-XML щодня.
Головне правило Фази 0 — витримати 2–4 тижні, щоб захопити повний цикл ділової активності. Місячні інвойси, квартальні звіти, HR-розсилки про зарплату, нагадування від SaaS — усе це шле пошту від вашого домену нерегулярно. Перейдете далі за тиждень — і рівно ці рідкісні джерела впадуть у reject, бо ви їх просто не побачили.
Тут видно суть проблеми: spf=pass, але в policy_evaluated DKIM fail, а реальний SPF-домен у auth_results — servers.mcsv.net, тобто невирівняний. Це Mailchimp, який пройде reject лише після того, як ви піднімете йому DKIM на своєму домені.
Мета фази — скласти вичерпний список джерел: власний MTA, Google Workspace, транзакційні (SendGrid, Postmark, SES), маркетинг (Mailchimp), тикети (Zendesk), біллінг/HR SaaS. Для кожного, хто у fail, є два лікування: додати include: у SPF або (краще) підняти DKIM через CNAME на ключ провайдера:
dns
s1._domainkey.example.com. IN CNAME s1.domainkey.u1234.wl567.sendgrid.net.
Читати сотні XML руками неможливо. Робочий стек — parsedmarc → Elasticsearch → Grafana/Kibana. Не хочете тримати інфраструктуру — є хостовані dmarcian, Valimail і безкоштовний Postmark DMARC.
Ворота переходу з Фази 0: у звітах не лишилось невпізнаних IP, усі відомі джерела в PASS кілька днів поспіль, повний бізнес-цикл спостережено.
Фаза 1 — p=quarantine з поступовим pct
Тепер вмикаємо реальну дію, але з контрольованим радіусом вибуху. quarantine кладе провальний лист у Спам — це відновно, на відміну від reject. Але навіть сюди не варто стрибати на 100% одразу. Рампимо через тег pct:
Семантику pct плутають найчастіше. Він не «10% пошти йде в спам». Він означає: до pct% провального трафіку застосовується задана політика (quarantine), а до решти (100 − pct)% — наступна за суворістю, тобто none. Отже pct=10 чіпає лише 10% того, що і так провалює DMARC. Це і є ваш контрольований радіус.
Проходимо щаблі 10 → 25 → 50 → 100, по 3–7 днів на кожному, дивлячись у RUA і на скарги користувачів. Що моніторити: сплеск у папці «Спам» у власних співробітників, нові раніше не бачені IP, провали forwarding. Якщо на pct=25 вилазить джерело, яке ви пропустили — відкочуєтесь, чините DKIM/SPF, повертаєтесь. Reject такої розкоші не дає.
Фаза 2 — p=reject і політика для піддоменів
Фінальний запис вмикає відмову і — обов'язково — закриває піддомени:
sp=reject — політика для піддоменів. Ставте її, навіть якщо піддомени не шлють пошту. Інакше зловмиснику досить спамити від billing.example.com, який DMARC на кореневому домені не прикриває.
np=reject — новіший тег для неіснуючих піддоменів. Захищає від підробки на *.example.com, яких у вас узагалі немає в DNS.
reject із pct=100 — це також передумова для BIMI (логотип бренду в поштовому клієнті вимагає щонайменше quarantine; pct=100). І головне: після reject моніторинг RUA не вимикається. Нова SaaS-інтеграція, яку підключить маркетинг за півроку, зламається тихо — лист просто не дійде, і ніхто не побачить причини, крім вас у звітах.
Три головні джерела втрати легітимної пошти
1. Forwarding і аліаси. Пересилання зберігає тіло листа, тому DKIM-підпис зазвичай виживає — але Return-Path змінюється на сервер-пересилач, і SPF ламається. Рятує саме DKIM-alignment: якщо він є, DMARC проходить по DKIM-гілці попри мертвий SPF. SRS лагодить SPF при пересиланні, але DMARC він не рятує, бо не чіпає домен у From:. Висновок: не покладайтесь на SPF як єдину гілку.
2. Поштові розсилки і списки. Mailman та подібні додають футер у тіло і префікс [list-name] у Subject. Будь-яка зміна підписаних заголовків чи тіла робить DKIM-підпис недійсним — і SPF, і DKIM провалюються. Рятунок — ARC (Authenticated Received Chain): список підписує повідомлення заголовками ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results, засвідчуючи «на вході до мене DMARC був pass». Приймаючий бік, який довіряє цьому ARC-ланцюгу, пропускає лист попри зламаний DKIM.
3. Ліміт 10 DNS-lookup у SPF. SPF дозволяє максимум 10 звернень (include, a, mx, ptr, exists). Перевищення → PermError → SPF провалюється цілком. Роздутий запис ловиться на це легко:
Кожен include: тягне власні вкладені lookup — цей приклад уже балансує на межі. Чистіть ланцюги, прибирайте невживаних відправників, а SPF-flattening застосовуйте обережно: він ламається, коли провайдер змінює свої IP. І знову той самий висновок — тягніть DKIM усюди, щоб DMARC мав другу, стійкішу гілку.
Перевірити результат наскрізь допоможе swaks із читанням заголовків на приймаючому боці:
Для доменів на evilmail.pro цей рампінг уже зашитий у дефолтні DMARC-шаблони, тож вам не доведеться писати теги вручну — але перевірити чинний запис перед кожним переходом фази однаково варто через нашу перевірку DNS-записів.
