DMARC дає збій: оберіть політику, не порушивши справжню пошту

November 2, 2025 • February 3, 2026 • Читання: 5 хв • Views: 9

Було корисно?

«Електронний лист вашого CEO “не пройшов”, служба підтримки має три скриншоти помилок доставки, які не збігаються, а відділ маркетингу клянеться, що «нічого не змінювали». Тим часом ваш домен підробляють у фішингових кампаніях, і команда безпеки вимагає p=reject вже вчора.

Ось пастка DMARC: якщо почати застосовувати політику занадто рано, ви блокуватимете легітимні листи. Якщо не застосовувати — відкриваєте шведський стіл для підміни. Трюк не в тому, щоб просто вибрати політику. Трюк — заслужити її.

Що насправді робить DMARC (і чого не робить)

DMARC — це шар політики та звітності, побудований поверх SPF і DKIM. Він відповідає на одне питання: чи повинен отримувач довіряти домену в видимому заголовку From? DMARC перевіряє, чи проходить SPF або DKIM і чи є воно вирівняним з доменом у заголовку From. Якщо є автентифікація з вирівнюванням — DMARC проходить. Якщо ні — DMARC зазнає невдачі, і отримувач застосовує вашу політику: none, quarantine або reject.

Важливо: DMARC — це не фільтр від спаму. Він не оцінює вміст. Він не зупиняє скомпрометовані акаунти, які надсилають шкідливі листи, використовуючи валідну автентифікацію. Він не виправляє вашу репутацію. Це ближче до «захисту бренду з ручками», і ці ручки можуть нашкодити, якщо крутити їх як діджей опівночі.

Цікаві факти та історичний контекст (щоб зрозуміти, чому це дивно)

DMARC народився з болю: з’явився близько 2012 року як прагматична відповідь на масову підміну доменів, яку самі SPF і DKIM не вирішували.
SPF виник раніше за DKIM: SPF набрав популярність на початку 2000-х, коли підробка envelope sender була повсюдною, а SMTP це ігнорував.
DKIM з’явився через співпрацю галузі: він виник як зусилля великих постачальників поштових скриньок для збереження цілісності повідомлення під час переадресації.
Вирівнювання — це «нове» вимого: недостатньо просто, щоб SPF або DKIM проходили; DMARC вимагає, щоб аутентифікований домен відповідав видимому From.
Переадресація за дизайном ламає SPF: стандартна переадресація змінює IP-постачальника, тож SPF часто падає навіть коли початковий відправник був легітимним.
Звіти DMARC зробили пошту видимою: агрегатні звіти — один з перших широко використовуваних телеметричних каналів для автентифікації пошти в Інтернеті.
Адаптація політик прискорилася після тиску великих провайдерів: коли великі поштові сервіси почали явно маркувати неавтентифіковану пошту, керівники різко зацікавилися.
Політика для субдоменів існує тому, що атаки люблять субдомени: тег sp= — це мовчазне визнання, що «одна політика для всіх» рідко витримує корпоративну реальність.

Одна цитата, яку операційники повторюють не без причини: «Надія — це не стратегія.» — генерал Гордон Р. Салліван. Автентифікація пошти — це майстер-клас із цієї ідеї.

Швидка інструкція діагностики

Це послідовність «припиніть гадати». Мета — знайти вузьке місце за кілька хвилин, а не намалювати гарну діаграму, яку ніхто не прочитає.

Перше: підтвердіть вісь, що не проходить (SPF, DKIM або вирівнювання)

Візьміть реальне невдале повідомлення (краще з поштового провайдера, а не зі скриншота).
Перевірте Authentication-Results і зафіксуйте:
- прохід/помилку SPF та домен, який використано.
- прохід/помилку DKIM та домен підписувача (d=).
- прохід/помилку DMARC та домен з «header.from».
Якщо SPF або DKIM проходить, але DMARC не проходить — у вас проблема з вирівнюванням, а не з автентифікацією.

Друге: ідентифікуйте систему відправника

Шукайте підказки в заголовках: Received:, X-Mailer, вендор-специфічні заголовки.
Зіставте це зі знаним потоком: Microsoft 365, Google Workspace, Salesforce/Marketo, Zendesk, on-prem Postfix, HR-система, платформа для рахунків тощо.
Якщо швидко не ідентифікуєте — агрегатні звіти DMARC допоможуть, якщо ви їх збираєте.

Третє: вирішіть, чи можна це виправити конфігурацією або потрібна зміна маршрутизації

Виправляється конфігурацією: додати DKIM-підпис, виправити From-домен, додати include в SPF, виправити селектор, опублікувати запис DMARC, встановити режим вирівнювання.
Потрібна зміна маршрутизації: третя сторона повинна надсилати через ваш авторизований ретранслятор, або використовувати власний домен, або підтримувати DKIM з вашим доменом.

Не починайте зі зміни політики DMARC. Почніть з того, щоб ваші легітимні потоки проходили автентифікацію. Політика йде останньою.

Як обрати політику DMARC без зламу пошти

Політика DMARC — це не моральна позиція. Це інженерія трафіку. Ваша мета: зупинити підміни, зберігши доставку легітимної пошти. Найбезпечніший шлях — поступове застосування з телеметрією.

Що на практиці означають три політики

`p=none` (моніторинг)

Це просить отримувачів нічого спеціального не робити з невдачами. Це не марно — якщо у вас налаштована звітність, це фаза видимості. Ставтеся до p=none як до режиму лише для читання: ви вимірюєте зону ураження, перераховуєте відправників і виправляєте вирівнювання. Якщо залишитесь тут назавжди — зловмисники будуть вдячні за внесок у їхні квартальні цілі.

`p=quarantine` (м’яке застосування)

Це просить отримувачів ставитися до невдачі як до підозрілої пошти — зазвичай поміщати у спам. Поведінка відрізняється за провайдерами. Деякі агресивні, деякі м’якші, деякі роблять вигляд, що вас ігнорують. Quarantine корисний, бо показує вплив на користувача з меншими наслідками за reject. Але він небезпечний: люди не завжди перевіряють спам, а бізнес-процеси не люблять ймовірну доставку.

`p=reject` (жорстке застосування)

Це просить отримувачів відкидати невдалі листи прямо під час SMTP. Це найчистіша позиція для запобігання підміни. Але вона також безжальна: будь-який легітимний потік, що не проходить вирівнювання, стане аварією. Ви не «пробуєте reject». Ви впроваджуєте його так само обережно, як правило фаєрвола у проді: з інвентарем, канарками та планом відкату.

Поступове застосування, яке не підпалить продакшн

Використовуйте процентне розгортання з тегом pct=. Почніть з pct=10 або pct=25 для quarantine або reject, залежно від впевненості у вашому інвентарі відправників.

Типова безпечна послідовність:

Базова: p=none + працюючі агрегатні звіти (rua=) принаймні 2–4 тижні.
Прибирання: виправіть або усуньте невдалі легітимні потоки; додайте DKIM-підписування скрізь, де можна.
Часткове застосування: p=quarantine; pct=25, моніторьте вплив на користувачів і неочікувані джерела.
Сильніше: p=quarantine; pct=100 або перехід на p=reject; pct=25, якщо все чисто.
Ціль: p=reject; pct=100, плюс sp=reject, якщо ви контролюєте субдомени.

Жарт №1: DMARC як ремінь безпеки — всі його люблять, поки він не защемить, коли ви тягнетесь за кавою.

Що робити з субдоменами (де складність розмножується)

Якщо ваша організація використовує субдомени для маркетингу, транзакційних листів або регіональних брендів, встановіть явну політику для субдоменів за допомогою sp=. Інакше ви випадково застосуєте політику до субдоменів, про які навіть не підозрювали.

Консервативно: p=reject; sp=none щоб захистити батьківський домен, даючи субдоменам простір для дихання.
Строго: p=reject; sp=reject коли ви знаєте, що відправники на субдоменах чисті.

Наскільки суворим має бути вирівнювання?

Вирівнювання DMARC може бути релаксованим або суворим:

Релаксоване вирівнювання (за замовчуванням): дозволяє вирівнювання на рівні організаційного домену (наприклад, підпис з d=mail.example.com вирівнюється з From example.com).
Суворе вирівнювання: вимагає точного збігу доменів. Саме тут законні налаштування найчастіше ламаються.

У більшості підприємств суворе вирівнювання — справа майбутнього, після того як ви ліквідуєте дивну поведінку вендорів і стандартизуєте відправні домени. Починайте з релаксованого, якщо немає сильної причини інакше.

Вирівнювання та режими відмов, які болять у продакшені

SPF: envelope sender відрізняється від From

SPF автентифікує домен у SMTP envelope sender (Return-Path), а не заголовок From. DMARC потім перевіряє, чи вирівнюється домен, автентифікований SPF, із заголовком From.

Поширений шаблон невдачі:

Return-Path: bounces.vendor-mail.example.net (домен вендора)
From: billing@example.com (ваш домен)
SPF проходить для домену вендора, але не вирівнюється з example.com → DMARC не проходить, якщо DKIM не вирівняний.

DKIM: підпис є, але не для вашого домену

DKIM підписує вміст і прив’язує його до домену через тег d=. DMARC перевіряє, чи цей домен вирівнюється з заголовком From. Якщо вендор підписує як d=vendor.com, а він надсилає From ваш домен, DKIM може проходити, але DMARC все одно зазнає невдачі.

Переадресація: SPF падає, DKIM може вціліти

Класична переадресація ламає SPF, бо IP переадресатора не міститься у вашому SPF-записі. DKIM може пережити переадресацію, якщо повідомлення не змінюється в дорозі. Багато систем змінюють його (додавання префіксу в темі, футери), що ламає DKIM теж. Тоді DMARC падає і ви отримуєте зустріч «чому це працювало минулого року?»

Мейлінг-листи: подрібнювач DKIM

Мейлінг-листи часто перепакують або модифікують повідомлення (додавання префіксу в темі, підписів списку), що ламає DKIM. SPF рідко вирівнюється, бо відправляє лист сервер списку. DMARC зазнає невдачі. Сучасні менеджери списків можуть пом’якшити це, але ви не контролюєте всі списки, на які підписані ваші користувачі.

Кілька вендорів: смерть від тисячі «просто додайте цей include»

SPF має жорстке обмеження: 10 DNS-запитів під час оцінки. Кожен include: рахується, плюс редиректи та деякі механізми. Перевищите — отримуєте permerror. DMARC байдуже, чому SPF впав; він просто бачить невдачу. Ви можете зламати пошту, «авторизувавши» занадто багато речей.

Звіти DMARC: різниця між контролем та забобоном

Агрегатні звіти (RUA) показують, хто надсилає від вашого імені, яку автентифікацію вони проходять і з яким об’ємом. Вони не ідеальні. Вони затримані, деякі провайдери їх відбирають, і їх іноді важко парсити. Але без них ви робите зміни політики всліпу.

Практичні завдання: команди, виводи, рішення

Ці завдання розроблені для workflow типу SRE: перевірити стан, інтерпретувати результат, прийняти рішення, змінювати по одній речі за раз.

Завдання 1 — Перевірте, чи існує запис DMARC і чи синтаксично він коректний

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; fo=1; adkim=r; aspf=r; pct=100"

Що це означає: DMARC існує; політика — моніторинг; звіти надсилаються на ваші поштa; встановлено релаксоване вирівнювання.

Рішення: Якщо запису немає або він невірний — виправте це перед будь-якими іншими діями. Якщо ви ще на p=none, ви в режимі інвентаризації.

Завдання 2 — Підтвердіть, що DNS повертає один TXT-запис DMARC

cr0x@server:~$ dig TXT _dmarc.example.com +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"

Що це означає: Один запис — добре.

Рішення: Якщо ви бачите кілька TXT-відповідей — консолідуйте. Кілька записів DMARC — невизначена поведінка, і поштові провайдери зазвичай обирають хаос.

Завдання 3 — Перевірте SPF та порахуйте include (ризик запитів)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org -all"

Що це означає: SPF авторизує Google, Microsoft, Mailgun. Може бути нормально, але кожен include коштує запитів.

Рішення: Якщо у вас більше кількох include, проведіть тест підрахунку запитів (наступне завдання). Якщо ви близько до 10 — припиніть додавати include і змініть стратегію (вирівнювання DKIM через вендорів або консолідуйте через ретранслятор).

Завдання 4 — Виявити permerror SPF через ліміт DNS-запитів

cr0x@server:~$ spfquery -ip=203.0.113.10 -sender=bounce@example.com -helo=mx.example.com
pass (lookup_count=7)

Що це означає: SPF пройшов і використав 7 DNS-запитів. Маєте запас.

Рішення: Якщо бачите permerror (lookup limit exceeded), потрібно зменшити складність SPF. Це не «пізніше» — це «сьогодні» перед застосуванням політики.

Завдання 5 — Витягніть заголовок невдалого повідомлення і прочитайте Authentication-Results

cr0x@server:~$ sed -n '1,120p' failing-message.eml | egrep -i 'authentication-results|dmarc=|spf=|dkim=|from:|return-path'
Return-Path: <bounces@vendor.example.net>
From: "Billing" <billing@example.com>
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@vendor.example.net designates 198.51.100.20 as permitted sender) smtp.mailfrom=bounces@vendor.example.net;
       dkim=none (message not signed);
       dmarc=fail (p=quarantine sp=quarantine dis=none) header.from=example.com

Що це означає: SPF пройшов для домену вендора, але DMARC впав, бо немає DKIM і SPF не вирівнюється з example.com.

Рішення: Потрібне DKIM-підписання з d=example.com (переважно), або змінити вендора, щоб надсилати з їхнього домену (менш ідеально для бренду), або маршрутизувати через вашу інфраструктуру.

Завдання 6 — Перевірте, чи існує публічний ключ DKIM для селектора

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw..."

Що це означає: Селектор s1 опублікований. Це необхідно, але недостатньо.

Рішення: Якщо відсутній — DKIM впаде для листів, підписаних цим селектором. Опублікуйте або виправте його перед застосуванням.

Завдання 7 — Перевірте, чи повідомлення дійсно DKIM-підписане і вирівняне

cr0x@server:~$ grep -i '^DKIM-Signature:' -m 1 good-message.eml
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date:message-id; bh=...; b=...

Що це означає: Домен підписування d=example.com вирівнюється з From example.com. Цей потік має проходити DMARC навіть якщо SPF ламається (переадресація).

Рішення: Якщо d=vendor.com, DKIM може проходити, але вирівнювання DMARC може не пройти. Виправте конфігурацію вендора, щоб підписувати вашим доменом.

Завдання 8 — Протестуйте оцінку DMARC за допомогою інструмента, як OpenDMARC

cr0x@server:~$ opendmarc-testmsg < failing-message.eml | sed -n '1,25p'
opendmarc-testmsg: EnvelopeFrom: bounces@vendor.example.net
opendmarc-testmsg: HeaderFrom: example.com
opendmarc-testmsg: SPF: pass
opendmarc-testmsg: DKIM: fail
opendmarc-testmsg: DMARC: fail (policy=quarantine)

Що це означає: Логіка DMARC зі сторони отримувача погоджується з тим, що ви бачите у реальному середовищі.

Рішення: Не сперечайтесь з продом. Виправте DKIM або вирівнювання.

Завдання 9 — Перевірте логи Postfix щодо поведінки DKIM milter (on-prem)

cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Jan  3 10:12:11 mx1 postfix/cleanup[22190]: 9F3C42C10D: message-id=<20260103101210.9F3C42C10D@mx1.example.com>
Jan  3 10:12:11 mx1 opendkim[1187]: 9F3C42C10D: DKIM-Signature field added (s=s1, d=example.com)
Jan  3 10:12:11 mx1 postfix/qmgr[1120]: 9F3C42C10D: from=<billing@example.com>, size=28412, nrcpt=1 (queue active)

Що це означає: Ваш MTA додає DKIM-підписи з очікуваним селектором і доменом.

Рішення: Якщо не бачите «DKIM-Signature field added», шлях підписування зламаний (milter впав, невірний сокет, неправильні права ключа).

Завдання 10 — Підтвердіть, що ваша DMARC-поштова скринька для звітів отримує агрегатні звіти

cr0x@server:~$ sudo -u postfix mailq | head
Mail queue is empty

Що це означає: Безпосередньо не про DMARC, але це показує, що черга MTA не завалена. Якщо ви робите локальну доставку, це важливо.

Рішення: Якщо черга зростає і призначення — ваша rua поштова скринька, ви втрачаєте звіти і летите всліпу. Виправте доставку пошти перед зміною політики.

Завдання 11 — Витягніть XML агрегатного звіту DMARC і підсумуйте топ невдалих джерел

cr0x@server:~$ unzip -p rua-archive/aggregate-report-001.zip '*.xml' | grep -Eo '<source_ip>[^<]+' | head
<source_ip>192.0.2.55
<source_ip>198.51.100.20
<source_ip>203.0.113.99

Що це означає: У вас є швидкий список IP-адрес, що надсилають від вашого домену.

Рішення: Для кожного топового IP ідентифікуйте систему/вендора. Невідомі IP — це або shadow IT, або активна підміна. Обидва варті уваги; тільки один заслуговує тикета вендору.

Завдання 12 — Перевірте, які системи підключаються до ваших вхідних MX (виявлення спуфінгу та ретрансляторів)

cr0x@server:~$ sudo grep -h "connect from" /var/log/mail.log | awk '{print $NF}' | sed 's/[][]//g' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  412 203.0.113.77
  198 198.51.100.20
   76 192.0.2.55

Що це означає: Топ підключаючихся IP. Це не доводить спуфінг, але показує, хто з вами контактує.

Рішення: Якщо бачите несподіваних відправників або великі стрибки — корелюйте з DMARC-невдачами та подіями безпеки. Можливо, ви під прицілом активних кампаній підміни.

Завдання 13 — Перевірте, що ваша DMARC-політика — це те, що ви думаєте (кешований DNS бреше)

cr0x@server:~$ dig TXT _dmarc.example.com @8.8.8.8 +short
"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r"

Що це означає: Публічний резолвер бачить quarantine на 25%. Добре для поступового розгортання.

Рішення: Якщо різні резолвери дають різні відповіді — у грі TTL або розповсюдження DNS. Не переходьте на reject, поки не побачите узгоджений результат.

Завдання 14 — Перевірте SPF для конкретного вендорського потоку (чи вирівнюється він?)

cr0x@server:~$ dig +short TXT vendor.example.net
"v=spf1 ip4:198.51.100.0/24 -all"

Що це означає: Вендор авторизує власний діапазон IP для свого домену. Це нічого не дає щодо вирівнювання з вашим From-доменом.

Рішення: Припиніть намагатися «вирішити SPF» для невирівняних сторонніх відправників. Наполягайте на DKIM-підписанні вашим доменом або зміні From-домену.

Завдання 15 — Перевірте, що ротація селекторів DKIM не залишила мертві записи (поширено під час «прибирання»)

cr0x@server:~$ for s in s1 s2 s2024; do echo "== $s =="; dig +short TXT ${s}._domainkey.example.com; done
== s1 ==
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."
== s2 ==
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."
== s2024 ==

Що це означає: Селектор s2024 відсутній. Якщо якийсь відправник досі його використовує — DKIM впаде.

Рішення: Тимчасово відновіть ключ або мігруйте відправника на існуючий селектор перед застосуванням політики. Видалення старих селекторів — не «гігієна», якщо вони ще використовуються.

Завдання 16 — Підтвердіть межу організаційного домену для релаксованого вирівнювання (поведінка public suffix)

cr0x@server:~$ python3 - <<'PY'
import sys
from email.utils import parseaddr
print("example.co.uk aligns with sub.example.co.uk under relaxed mode, but not with example.com")
PY
example.co.uk aligns with sub.example.co.uk under relaxed mode, but not with example.com

Що це означає: Релаксоване вирівнювання використовує логіку організаційного домену (на основі правил public suffix). Країнові домени можуть дивувати людей.

Рішення: Якщо ви працюєте під доменами на кшталт example.co.uk, ретельно перевірте конфігурації вендорів і очікування; суворе вирівнювання швидко стає болючим.

Жарт №2: SPF — дієта інформаційної безпеки пошти: просто на папері, зруйнована одним «ще одним include».

Три корпоративні міні-історії (бо ми ніколи не вчимося просто)

Міні-історія 1: Аутейдж через хибне припущення

Компанія мала чисту на вигляд конфігурацію: Microsoft 365 для співробітників, відома маркетингова платформа та on-prem ретранслятор для принтерів і «спеціальних систем». Безпека хотіла p=reject. Адмін електронної пошти погодився, бо звіти DMARC показували «переважно pass».

Хибне припущення було підступним: вони подумали, що «переважно pass» означає «решта — підміна». Це не так. Регіональний HR-інструмент надсилав листи з From: hr@example.com, але маршрутизував через інфраструктуру вендора без вирівняного DKIM. SPF проходив — але не для правильного домену. DMARC падав. При p=none лист доходив. При p=reject він відхилявся.

У понеділок кандидати не отримали пропозицій. Рекрутери підняли хвилю. Юристи питали, чи компанія «скасувала» пропозиції. Безпека отримала докори за вимогу reject, а команда пошти — за її впровадження. Менеджмент зробив те, що робить менеджмент: призначив зустріч, потім ще одну про першу зустріч.

Виправлення було просте: налаштувати HR-вендора підписувати DKIM з d=example.com з делегованим селектором, потім знову включити посилення. Урок був неприємніший: успіх DMARC — це перерахувати кожного легітимного відправника. Будь-яке припущення «невідоме = шкідливе» зрештою вас підведе.

Міні-історія 2: Оптимізація, що відбилася бумерангом

Інша організація вирішила «спростити DNS». Хтось помітив, що SPF виріс у невеличкий роман. Видалили те, що виглядало як «старі include», і об’єднали селектори DKIM, бо «не потрібно так багато». Намір був добрий. Але не протестували в реалі.

Через два тижні рівень DMARC-невдач зріс. Не скрізь — лише у кількох поштових провайдерів. Команда марно звинувачувала «зміни провайдера» та «репутацію». Правда була така: один «старий include» все ще покривав транзакційний потік для скидання пароля в легасі-додатку. Він надсилав рідко, тож не показувався в щоденних панелях. Коли він відправив, SPF падав, і легасі-додаток не DKIM-підписував. При посиленні політики листи для скидання пароля тихо зникали у quarantine або відхилялися.

Тим часом об’єднання селекторів DKIM зламало інтеграцію вендора, який хардкодив ім’я селектора. Той вендор продовжував підписувати старим селектором, який уже не існував у DNS. DKIM одразу впав. DMARC-невдачі зросли для цього відправника.

Команда відкотила зміни, а потім написала правило: ніяких «прибирань» SPF/DKIM без мапування кожного include і селектора на власника, систему та тестове повідомлення. Оптимізація хороша, але автентифікація пошти карає винахідливість. Вона віддає перевагу нудній паперовій роботі та стабільному DNS.

Міні-історія 3: Нудна, але правильна практика, що врятувала положення

Середня SaaS-компанія вела DMARC-звіти до внутрішньої поштової скриньки, потім до парсера, що створював щотижневий інвентар відправників. Нічого фантастичного. Жодного ML. Просто список джерел, коефіцієнтів проходження та «нові відправники з минулого тижня». Це була та сама «нудна робота», яка стає важливою у потрібний момент.

Одного вівторка звіт помітив новий IP-джерело, що надсилало невеликий, але ненульовий обсяг листів з From: finance@example.com. SPF падав. DKIM відсутній. DMARC не проходив. При їхній поточній p=quarantine значна частина потоку потрапляла в спам. Це було добре, але недостатньо.

Безпека розслідувала і виявила фішингову кампанію, спрямовану на клієнтів. Оскільки команда мала телеметрію і базу, вони не сперечалися, чи це справжня загроза. Вони перейшли на p=reject; pct=25 на 24 години, перевірили, що легітимні потоки не постраждали, а потім підняли до 100% reject. Вони також встановили sp=reject після підтвердження чистоти субдоменів.

Клієнти зауважили менше фішингових листів з використанням бренду компанії вже за кілька днів. Нудна практика — послідовна звітність і інвентар — зробила застосування контролюваною зміною, а не стрибком віри. Ніхто не отримав виклику на нічну зміну. Найкращі аварії — ті, яких ніколи не сталося.

Поширені помилки: симптом → корінь → виправлення

1) «SPF проходить, але DMARC не проходить»

Симптом: Authentication-Results показує spf=pass, DMARC не проходить.

Корінь: SPF пройшов для домену, що не вирівнюється з header From (поширено при сторонніх відправниках).

Виправлення: Увімкніть DKIM-підписання, вирівняне з вашим From-доменом (найкраще), або змініть From-домен на домен вендора, або маршрутизайте відправника через вашу вирівняну інфраструктуру.

2) «DKIM проходить, але DMARC не проходить»

Симптом: dkim=pass але DMARC не проходить.

Корінь: Домен підписування DKIM (d=) не вирівнюється з header From; вендор підписує своїм доменом.

Виправлення: Налаштуйте вендора підписувати вашим доменом через делегований DKIM (опублікуйте їхній селектор під вашим доменом), або змініть From-домен.

3) «Все працювало, поки ми не поставили p=reject»

Симптом: Негайні відмови для частини легітимної бізнес-пошти.

Корінь: Невідомі легітимні відправники, зламані селектори DKIM або SPF permerror були приховані під p=none/quarantine.

Виправлення: Відкотіться до quarantine з pct=, виправте інвентар відправників, потім поступово повторно застосуйте reject.

4) «Переадресована пошта почала відхилятися після застосування DMARC»

Симптом: Користувачі скаржаться, що переадресації на особисті скриньки не доходять; доставка на мейлінг-листи не проходить.

Корінь: Переадресатори ламають SPF; модифікації списків ламають DKIM; DMARC зазнає невдачі.

Виправлення: Переконайтеся, що ваша вихідна пошта DKIM-підписана вирівняно; для списків розгляньте спеціальні пом’якшувальні заходи (наприклад, переписування From) або дозвольте відомі поведінки списків у нижележачих системах, де це можливо.

5) «SPF permerror з’являється раптово»

Симптом: Деякі отримувачі показують SPF permerror або fail; інші проходять.

Корінь: Перевищено ліміт DNS-запитів; деякі оцінювачі по-іншому роблять short-circuit, або таймаути DNS штовхають у тимчасові помилки.

Виправлення: Зменшіть DNS-запити SPF, консолідувавши відправників, видаливши невикористовувані include або використайте вирівнювання DKIM замість залежності від SPF.

6) «DMARC-звіти перестали приходити»

Симптом: Поштова скринька RUA тиха; панелі застарівають.

Корінь: Скринька переповнена, зміни в маршрутизації, невірна адреса rua або фільтрація блокує великі zip-додатки.

Виправлення: Переконайтеся, що поштовий ящик для звітів приймає великі повідомлення, не видаляє автоматично і що адреса rua правильна та моніториться.

7) «Ми маємо DMARC, але підміни все ще трапляються»

Симптом: Клієнти отримують фішинг під вашим брендом, незважаючи на наявність запису DMARC.

Корінь: Ви на p=none, або отримувачі не застосовують політику однаково, або зловмисники використовують подібні домени.

Виправлення: Перейдіть на reject, коли легітимні потоки проходять; додайте політику для субдоменів; моніторьте подібні домени окремо (DMARC не захистить від examp1e.com).

Чек-листи / покроковий план

Покроковий план: безпечно дійти до `p=reject`

Інвентар відправників за допомогою агрегатних звітів DMARC принаймні 2–4 тижні. Призначте власника кожному джерелу.
Класифікуйте потоки:
- Пошта співробітників (M365/Workspace)
- Транзакційна (додаткова пошта, рахунки, скидання пароля)
- Маркетинг (кампанії)
- Підтримка/системи тикетингу
- Інфраструктура (алерти, моніторинг)
Стандартизуйте From-домени: вирішіть, які домени дозволені для кожного потоку. Будьте суворі. Вендори люблять творчі From-адреси.
Увімкніть вирівняне DKIM-підписання скрізь, де можна. Віддавайте перевагу DKIM для сторонніх потоків, бо вирівнювання простіше, і воно краще переживає переадресацію.
Виправте SPF, але тримайте його легким:
- Видаліть мертві include
- Тримайтеся нижче 10 запитів
- Використовуйте -all, коли впевнені; ~all — тимчасова підпора, а не стратегія
Опублікуйте DMARC з звітністю: p=none + rua. Перевірте, що звіти справді приходять і парсяться.
Встановіть політику для субдоменів явним чином через sp=. Не дозволяйте випадкове успадкування застосування.
Перейдіть до quarantine з pct: почніть з pct=25, потім 50, потім 100 у міру зниження рівня невдач і прийнятного шуму служби підтримки.
Перейдіть до reject з pct: почніть 10–25, стежте за новими невдачами. Рамуйте обережно.
Закріпіть управління: будь-який новий вендор, що надсилає від вашого домену, має підтримувати вирівняний DKIM або використовувати вендорський домен; «не можемо» означає «ми вас не підключатимемо».
Продовжуйте моніторинг: DMARC — не налаштував і забув. Вендори змінюють IP, інтеграції змінюються, хтось купує компанію — і ваша DMARC-позиція знову зустрічається з реальністю.

Чек-лист: перед зміною політики DMARC

Чи маємо мінімум один робочий RUA-адрес і чи він отримує звіти?
Чи є актуальний інвентар відправників з власниками?
Чи основні потоки проходять DMARC (не лише SPF або DKIM)?
Чи SPF нижче ліміту DNS-запитів і стабільний?
Чи опубліковані селектори DKIM для всіх активних підписувачів?
Чи є план відкату (попередній запис і розуміння TTL)?
Чи повідомили ми підтримку і безпеку про очікувані наслідки?

Чек-лист: коли вендор «повинен надсилати від вашого домену»

Чи може вендор DKIM-підписувати з d=yourdomain через делегований селектор?
Чи можуть вони підтримати кастомний Return-Path, вирівняний з вашим доменом (рідко найкращий шлях, але іноді можливий)?
Чи можуть вони надсилати через ваш ретранслятор (SMTP submission), щоб ви самі підписували пошту?
Чи мають вони per-tenant DKIM і стабільні патерни відправлення?
Чи можуть вони надати тестові повідомлення і технічний контакт, що розуміє автентифікацію?

Питання та відповіді

1) Чи варто одразу стрибнути на `p=reject`, щоб зупинити підміни?

Лише якщо ви впевнені, що ваші легітимні потоки вже проходять DMARC. Інакше ви міняєте підміни на самозавдані втрати пошти. Стадіюйте з pct і телеметрією.

2) Чи безпечний `p=quarantine`?

Безпечніший за reject, але не безпечний. Частина критичної бізнес-пошти може опинитися в папці спам, що фактично те саме, що втрата — лише з додатковим запереченням.

3) Чому SPF проходить, але DMARC усе одно не проходить?

Бо SPF автентифікував envelope-домен, а DMARC дивиться на header From. Якщо вони не вирівнюються, SPF не допомагає DMARC. Зазвичай вирішення — вирівняне DKIM-підписання.

4) Переадресація ламає нашу пошту. Чи несумісний DMARC з переадресацією?

DMARC виявляє крихкість переадресації. SPF ламається при пересиланні; DKIM може вціліти, якщо повідомлення не змінюється. Для ваших вихідних потоків DKIM-підписуйте вирівняно, щоб хоча б один механізм міг пройти.

5) Чи потрібні нам forensic-звіти (`ruf=`)?

Зазвичай ні. Forensic-звіти підтримуються непослідовно і можуть створювати приватні ризики. Агрегатні звіти (RUA) — робоча конячка для операційних рішень.

6) Яка найпоширеніша причина, чому DMARC «раптом перестає працювати» після років?

Новий відправник або зміна маршруту. Типові тригери: маркетинг додає платформу, служба підтримки змінює вендора, SaaS-інструмент починає надсилати «від вашого домену», або селектори DKIM ротаційовано невірно.

7) Чи потрібне суворе вирівнювання (`adkim=s`, `aspf=s`)?

Не спочатку. Суворе вирівнювання зменшує двозначність, але підвищує вимоги до кожного відправника. Почніть з релаксованого, дочекайтесь reject, потім розгляньте суворе там, де воно не ламає систему.

8) Що щодо субдоменів: чи встановлювати `sp=reject`?

Лише коли ви знаєте, що використовує субдомени. Якщо у вас багато вендорських субдоменів, почніть з sp=none або sp=quarantine і проведіть інвентаризацію.

9) Якщо ми користуємося Microsoft 365 або Google Workspace, чи потрібен нам DMARC?

Так. Ці платформи можуть автентифікувати вашу вихідну пошту, але DMARC — це те, як увесь світ розуміє, що робити, коли хтось підмінює ваш домен.

10) Як довго залишатися на `p=none`?

Достатньо, щоб зловити нормальні бізнес-цикли: щонайменше два тижні, часто місяць. Квартальні білінгові процеси і рідкі робочі потоки — саме там ховаються «невідомі відправники».

Висновок: наступні кроки, які ви можете виконати

Якщо DMARC зазнає невдачі, не починайте з питання «quarantine чи reject?» Почніть з питання «який легітимний потік не проходить вирівнювання?» Виправте це, потім застосовуйте політику. Політика — останній крок, не перший.

Практичні наступні кроки

Витягніть невдале повідомлення і прочитайте Authentication-Results. Визначте, чи проблема в SPF, DKIM чи вирівнюванні.
Перевірте записи DMARC і SPF у DNS з кількох резолверів. Виправте синтаксис та усуньте дублікати.
Перетворіть DMARC-звіти в інвентар: кожен відправник, власник і коефіцієнт проходження.
Надинайте вирівняне DKIM-підписання для кожного стороннього відправника, який має використовувати ваш From-домен.
Етапно застосовуйте політику з pct: спочатку quarantine, потім reject, з планом відкату і проінформованою підтримкою.

Зробіть це — і «DMARC дає збій» перетвориться на вирішувану інженерну задачу замість нескінченого email-потоку з темою «URGENT».

Схожі статті

Блокування електронної пошти «550 5.7.1» — реалістичний шлях виправлення