DMARC-звіти: як їх читати та вчасно виявляти підробки

Що таке DMARC‑звіти насправді (і чим вони не є)

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

Важливі два типи звітів:

• Агрегатні звіти (a.k.a. RUA): періодичні підсумки, зазвичай щоденні, які показують кількість повідомлень по IP‑адресах джерел, результати аутентифікації та розпорядження політики. Їх використовують для моніторингу та виявлення трендів.
• Форензічні/фейлові звіти (a.k.a. RUF): деталі по кожному повідомленню (або вибірці) при невдачі. Багато провайдерів обмежують або не надсилають їх через ризики приватності та зловживань. Якщо увімкнути їх без плану, у вас опиниться поштовий ящик, повний персональних даних, якими ви не хочете володіти.

Чим DMARC‑звіти не є:

• Гарантією, що підробки неможливі. DMARC допомагає запобігати прямим підробкам у приймаючих системах, які його підтримують; він не зупиняє домени‑клонів, шахрайство з відображуваним ім’ям або скомпрометованих постачальників.
• Досконалою істинною інформацією про «хто надіслав лист». Звіти показують те, що спостерігав отримувач. Пересилання, шлюзи та розсилки спотворюють дійсність, якщо ви не розумієте вирівнювання та механіки зламу аутентифікації.
• Заміною журналів. DMARC‑звіти — це погляд зі сторони отримувача. Вам все одно потрібна телеметрія зі сторони відправника, щоб закрити цикл.

Уявляйте DMARC‑звіти як сигнали з рівня SLO для довіри до бренду. Вони не погасять вогонь, але скажуть, де дим і як швидко він шириться.

Цікаві факти та трохи історії

• DMARC з’явився на початку 2010‑х коли великі постачальники пошти намагалися зменшити фішинг в інтернеті, не руйнуючи екосистему електронної пошти миттєво.
• SPF передував DMARC і був спроєктований навколо SMTP‑конверта (Return‑Path), а не видимого користувачу заголовка From. Ця невідповідність — чому DMARC і вимагав «вирівнювання».
• DKIM виник із DomainKeys і Identified Internet Mail; він стандартизував криптографічне підписування заголовків/тіла повідомлення, але не визначав одразу, як одержувачі мають послідовно поводитися при відмовах. DMARC додав політику.
• Тег «pct» у DMARC існує, бо світ працює на поетапних розгортаннях. Це ручка для канаркового розгортання аутентифікації пошти.
• «Relaxed» проти «strict» вирівнювання по суті означає, чи дозволені піддомени, що звучить просто, поки в організації не буде 47 маркетингових платформ і старої ERP, яка думає, що зараз 2003 рік.
• Агрегатні звіти традиційно в XML, не тому що це комусь подобається. Формат широко підтримується і добре стискається, що було важливо при масштабуванні звітів.
• Основні провайдери обмежують або не надсилають форензічні звіти через ризики приватності; деякі більше не відправляють повні зразки повідомлень.
• ARC (Authenticated Received Chain) існує переважно тому, що легітимні потоки, наприклад розсилки, ламають SPF/DKIM; ARC дає спосіб посередникам зберегти результати аутентифікації далі по ланцюгу.

Одна перефразована ідея, яку варто тримати поряд, приписується Werner Vogels: Усе рано чи пізно ламається; розробляйте так, щоб можна було швидко відновитися і вчитися на помилках.

Основи DMARC, які важливі в продакшні

DMARC — це політика + вирівнювання + звітність

DMARC‑запис розміщується за адресою _dmarc.example.com в DNS. Він визначає:

• Політику: що отримувачі повинні робити, коли DMARC не проходить (p=none, p=quarantine, p=reject).
• Вирівнювання: чи має SPF/DKIM «pass» вирівнюватися з доменом у From (relaxed/strict).
• Кінцеві точки звітності: куди надсилати агрегатні (rua) та/або форензічні (ruf) звіти.

Вирівнювання — місце, де більшість організацій втрачає кров

DMARC не вимагає, щоб і SPF, і DKIM проходили. Він вимагає або SPF або DKIM, щоб пройти та вирівнятися з доменом у From.

Типова реальність в продакшні:

• SPF проходить, але не вирівнюється, бо постачальник використовує свій домен для повернення (Return‑Path), а не ваш.
• DKIM проходить, але не вирівнюється, бо постачальник підписує з d=vendor.example замість d=yourdomain.com.
• Обидва ламаються після пересилання, бо SPF не витримує зміни IP, а DKIM — модифікацій заголовків/тіла.

Політика — це не відзнака честі

p=reject — не трофей. Це зміна в продакшні з видимими для користувачів наслідками. Її варто заслужити, інструментуючи та стабілізуючи ваших відправників спочатку.

Коротка суха правда: якщо ви не можете назвати своїх легітимних відправників, ви не готові відкидати невідомі.

Жарт №1: Аутентифікація електронної пошти схожа на чищення міжзубів: усі погоджуються, що це корисно, і ніхто не робить цього, поки не почнеться кровотеча.

Агрегатні проти форензічних: що ви здатні опрацьовувати

Агрегатні (RUA): ваш щоденний пульс

Агрегатні звіти надходять як стиснені вкладення (часто ZIP або GZIP), що містять XML. Кожний звіт охоплює часовий інтервал і включає кілька «записів», кожен з яких підсумовує пошту, що мала спільні:

• IP джерела (або іноді абстракція мережевого блоку)
• домен у From (header From)
• результати аутентифікації та статус вирівнювання
• кількості та застосоване отримувачем розпорядження

Вони чудові для виявлення:

• Нових джерел, що надсилають як ваш домен
• Різких стрибків невдач DMARC через зміну легітимної платформи
• Отримувачів, що несподівано застосовують quarantine/reject через нерівність

Форензічні (RUF): високий сигнал, високі ризики

Звіти про відмови можуть містити заголовки повідомлень і іноді частини повідомлення. Це може включати персональні дані, внутрішній вміст або чутливі ідентифікатори. Ставтеся до них як до логів з PII — застосовуйте політики зберігання та контролю доступу.

У багатьох середовищах правильне рішення: не вмикати RUF, якщо у вас немає конкретного кейсу та безпечного процесу обробки.

Як читати агрегатний звіт як SRE

Почніть із питання: «Що змінилося?»

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

• Базова лінія: відомі джерела, очікувані показники проходження, очікуваний мікс отримувачів.
• Виявлення змін: нові джерела, різке падіння вирівнювання, або аномалії, специфічні для провайдера.
• Атрибуція: зіставте IP з постачальниками/MTAs і вирішіть, авторизувати чи блокувати.

Розумійте три домени, що грають роль

Ви заплутаєтеся, якщо не розділятимете ці поняття:

• Header From domain: те, що бачить користувач; те, за що відповідає політика DMARC.
• SPF domain: домен конверта (Return‑Path / MAIL FROM), який перевіряє SPF.
• DKIM signing domain: значення d= в DKIM‑підписі.

DMARC запитує: чи проходить SPF і вирівнюється з Header From? Або чи проходить DKIM і вирівнюється з Header From? Якщо ні — DMARC не проходить, навіть якщо щось технічно «пройшло».

Disposition — це поведінка отримувача, а не ваш намір

DMARC‑звіти включають те, що отримувач зробив: none/quarantine/reject. Це залежить від вашої опублікованої політики, але також від локальної політики та антиспам‑евристик. Якщо ви публікуєте p=none, отримувачі все одно можуть класифікувати очевидний спам як сміття. І навпаки, навіть з p=reject деякі отримувачі можуть прийняти пошту, якщо вони довіряють ланцюжку пересилання або ARC.

Спочатку зосередьтеся на «не проходить, але мав би пройти»

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

Операційний порядок, який я рекомендую:

1. Виправте легітимні джерела, що не проходять DMARC (вирівнювання, ключі DKIM, проблеми з «flattening» SPF).
2. Перейдіть до p=quarantine із поступовим підвищенням pct.
3. Лише потім: p=reject (також поетапно), з моніторингом, який сигналізує при зростанні невдач.

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

Нижче — приклади завдань, які ви можете виконувати на Linux‑машині або в CI‑задачі, що дістає DMARC‑звіти з пошти/зберігання на кшталт S3. Кожне завдання містить: команду, приклад виводу, що це означає і яке рішення з цього випливає.

Task 1 — Fetch your DMARC record and sanity-check the policy

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

Що це означає: DMARC ввімкнено, режим лише моніторингу (p=none), розслаблене вирівнювання, повне охоплення.

Рішення: Якщо ви вже стабільні й все ще на p=none, заплануйте перехід до p=quarantine з поступовим підняттям pct. Якщо нестабільні — залишайте p=none і пріоритезуйте виправлення вирівнювання.

Task 2 — Verify the reporting mailbox exists and is receiving mail

cr0x@server:~$ ls -lh /var/mail/dmarc-agg
-rw------- 1 dmarc dmarc 218M Jan  3 08:40 /var/mail/dmarc-agg

Що це означає: Звіти надходять і накопичуються.

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

Task 3 — Identify attachment types (zip/gz) before parsing

cr0x@server:~$ file /srv/dmarc/inbox/*
/srv/dmarc/inbox/report-001.xml.gz: gzip compressed data, was "report.xml", last modified: Thu Jan  2 00:00:00 2026, from Unix
/srv/dmarc/inbox/report-002.zip: Zip archive data, at least v2.0 to extract, compression method=deflate

Що це означає: У вас змішані формати. Пайплайн мусить обробляти обидва.

Рішення: Нормалізуйте на сирий XML як перший крок (розпакувати), потім парсити.

Task 4 — Decompress and validate XML is present

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | head -n 8
<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>ExampleMailboxProvider</org_name>
    <email>noreply-dmarc@provider.example</email>
    <report_id>abc123</report_id>

Що це означає: Це агрегатний DMARC‑звіт (feedback XML).

Рішення: Продовжуйте до парсингу. Якщо бачите HTML або bounce, інгестія спрямована не в ту скриньку або ви отримуєте DSN.

Task 5 — Extract key fields quickly using xmllint and XPath

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | xmllint --xpath 'string(/feedback/report_metadata/org_name)' -
ExampleMailboxProvider

Що це означає: Звіт надійшов від конкретного отримувача. Особливості, притаманні конкретному отримувачу, важливі.

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

Task 6 — Pull the date range to correlate with incidents or deploys

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | xmllint --xpath 'concat(/feedback/report_metadata/date_range/begin, " ", /feedback/report_metadata/date_range/end)' -
1704153600 1704240000

Що це означає: Епох‑таймстампи для вікна звіту (begin/end). Це приблизно добова вибірка.

Рішення: Конвертуйте в людський час у вашому інструменті і накладіть на таймлайни деплоїв. Якщо кореляції немає — звинувачуватимете не ту зміну.

Task 7 — Summarize sources (IP + count) to find new senders

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record/row/source_ip/text() | //record/row/count/text()' - 2>/dev/null | \
tr ' ' '\n' | paste - - | head
192.0.2.10	1450
198.51.100.23	12
203.0.113.77	980

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

Рішення: Будь‑який новий IP з нетривіальним обсягом вимагає розслідування. Низькообʼємні невідомі IP можуть бути ціллю спрямованого фішингу — не ігноруйте їх, але пріоритезуйте по‑іншому.

Task 8 — Look specifically for DMARC failures at scale

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record[row/policy_evaluated/dkim="fail" and row/policy_evaluated/spf="fail"]/row/source_ip/text()' - 2>/dev/null | \
sort | uniq -c | sort -nr | head
3 198.51.100.23

Що це означає: Джерельна IP зʼявляється в кількох записах «обидва fail». Це або підробка, або легітимний відправник повністю неправильно налаштований.

Рішення: Якщо IP не належить вам або відомому постачальнику — вважайте підробкою. Якщо це відомий постачальник — ескалюйте, щоб негайно виправили DKIM/SPF вирівнювання.

Task 9 — Check SPF record size and lookup count risk

cr0x@server:~$ dig +short TXT example.com | tr ' ' '\n' | grep -E '^"v=spf1' -n
1:"v=spf1 include:_spf.mailvendor.example include:_spf.crmvendor.example include:_spf.payroll.example -all"

Що це означає: SPF використовує include (нормально). Ризик — невидима кількість DNS‑запитів.

Рішення: Якщо DMARC‑звіт показує SPF permerror/temperror, можливо, ви перевищуєте ліміт у 10 запитів SPF. Почніть інвентаризацію includes і зменшуйте складність; не «додавайте ще один include» бездумно.

Task 10 — Query DKIM selectors that vendors commonly use

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

Що це означає: Селектор s1 існує. Якщо ваш постачальник підписує з s1 і це вирівнюється, все гаразд.

Рішення: Якщо DMARC‑звіт показує DKIM fail, перевірте, що селектор існує, ключ коректний і постачальник дійсно підписує вашим доменом (d=example.com).

Task 11 — Confirm alignment settings (strict vs relaxed) and evaluate risk

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g' | tr ';' '\n' | sed 's/^ *//'
v=DMARC1
p=none
rua=mailto:dmarc-agg@example.com
ruf=mailto:dmarc-fail@example.com
adkim=r
aspf=r
pct=100

Що це означає: Розслаблене вирівнювання для SPF і DKIM. Піддомени можуть вирівнюватися залежно від правил організаційного домену.

Рішення: Залишайте relaxed під час rollout, якщо у вас немає дисциплінованої стратегії піддоменів. Strict — інструмент з гострим лезом; не махайте ним біля маркетингу.

Task 12 — Identify top “disposition=quarantine/reject” and treat as deliverability incident

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record/row/policy_evaluated/disposition/text()' - 2>/dev/null | \
sort | uniq -c | sort -nr
1200 none
230 quarantine
12 reject

Що це означає: Частина пошти потрапляє в quarantine/reject. Це може бути очікувано (підробки) або самозавдана рана.

Рішення: Якщо quarantine/reject нетривіальні і корелюють з легітимними джерелами, зупиніться і виправте вирівнювання перед тим, як підвищувати суворість політики.

Task 13 — Extract “header_from” domains to detect subdomain abuse

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record/identifiers/header_from/text()' - 2>/dev/null | \
tr ' ' '\n' | sort | uniq -c | sort -nr
2100 example.com
45 billing.example.com
7 security-update.example.com

Що це означає: Пошта заявляє, що походить також з піддоменів. Деякі легітимні (пошта від відділів), деякі — творчість атакувальників.

Рішення: Якщо ви свідомо не надсилаєте з піддомену, додайте DMARC‑записи для піддоменів або визначте організаційну політику і закрийте делегування DNS для цих імен.

Task 14 — Reverse-lookup suspicious IPs (quick triage, not proof)

cr0x@server:~$ dig +short -x 198.51.100.23
mailout-23.somehost.example.

Що це означає: PTR підказує хостинг‑провайдера. Там живуть і атакувальники, і постачальники.

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

Task 15 — Spot SPF permerror/temperror in DMARC auth results

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
grep -Eo '<spf>(permerror|temperror)</spf>' | sort | uniq -c
18 <spf>permerror</spf>

Що це означає: Отримувачі не змогли коректно оцінити SPF (часто через перевищення DNS‑запитів, неправильно сформовані записи або транзитні DNS‑помилки).

Рішення: Ставтеся до permerror як до помилки конфігурації. Виправте складність SPF і надійність DNS перед тим, як посилювати політику DMARC.

Task 16 — Confirm your inbound pipeline is not dropping reports (basic mail log check)

cr0x@server:~$ sudo grep -E "dmarc-agg@example.com|dmarc-fail@example.com" /var/log/mail.log | tail -n 5
Jan  3 08:40:12 mx1 postfix/lmtp[22091]: 9B2C312345: to=<dmarc-agg@example.com>, relay=local, delay=0.22, delays=0.05/0/0/0.17, dsn=2.0.0, status=sent (delivered to mailbox)
Jan  3 08:40:14 mx1 postfix/lmtp[22092]: 1A7D912346: to=<dmarc-agg@example.com>, relay=local, delay=0.18, delays=0.04/0/0/0.14, dsn=2.0.0, status=sent (delivered to mailbox)

Що це означає: Звіти доставляються локально; якщо є проблема з пайплайном, вона після доставки.

Рішення: Якщо бачите bounce або reject тут — виправте маршрутизацію пошти/ліміти розміру спочатку. Програма DMARC без звітів — це як моніторинг з вимкненими батарейками.

Покроковий план швидкої діагностики

Коли хтось повідомляє «DMARC не проходить» або «нас підробляють», вам потрібен короткий шлях до істини. Ось порядок дій, що мінімізує час до розуміння проблеми.

По‑перше: підтвердіть, чи це підробка, чи самозавдання

1. Перевірте політику DMARC і налаштування вирівнювання в DNS. Якщо ви на p=none, ви в основному спостерігаєте, а не блокуєте.
2. З агрегатних звітів складіть список топових невдалих IP за кількістю та розпорядженням. Великий обсяг + обидва SPF і DKIM fail зазвичай означає спроби підробки.
3. Зіставте невдалі IP з відомими відправниками. Якщо невдалий IP — ваш ESP/CRM, ймовірно, проблема вирівнювання, а не атака.

По‑друге: ізолюйте механізм провалу (SPF vs DKIM vs alignment)

1. Якщо DKIM проходить, але DMARC не проходить, зазвичай це DKIM‑вирівнювання (неправильне d=) або From‑домен відрізняється (піддомен vs основний).
2. Якщо SPF проходить, але DMARC не проходить, зазвичай це вирівнювання SPF (Return‑Path відрізняється) або ви аутентифікуєте інший домен, ніж видимий From.
3. Якщо обидва fail, підозрюйте підробку, проблему з пересиланням або повністю не налаштованого відправника.

По‑третє: вирішіть шлях пом’якшення

• Легітимний відправник не працює: виправте DKIM‑підписування/селектор та/або налаштуйте кастомний bounce‑домен для вирівнювання SPF; потім перевіряйте звіти протягом 24–48 годин.
• Невідомий відправник (ймовірно підробка): збирайте докази (мікс отримувачів, діапазони IP, обсяги) і рухайте політику до quarantine/reject після очищення легітимного трафіку.
• Проблеми з пересиланням/розсилками: оцініть підтримку ARC і розгляньте DKIM як основний вирівняний механізм замість SPF.

Три корпоративні міні-історії з практики

Міні‑історія 1: Інцидент через хибне припущення

Компанія мала на вигляд чисту конфігурацію: SPF, DKIM і DMARC. Команда безпеки була горда; ІТ втомлені; маркетинг нічого про це не знав.

Вони припустили, що їхній CRM‑постачальник «керує DKIM», бо була відповідна галочка. Він підписував пошту — але не домен компанії. DKIM d= був доменом постачальника. SPF теж «проходив», але з Return‑Path постачальника. Отже, пошта аутентифікувалася, але не вирівнювалася з видимим From. DMARC тихо не проходив, бо політика була p=none.

Потім вони підняли політику до p=quarantine в один вікно змін, бо «ми контролювали це місяцями». Моніторинг — так. Читання звітів — ні. Частина легітимних листів до клієнтів почала потрапляти в спам. Як зазвичай, першим помітив продаж.

Виправлення було простим, але нудним: налаштувати CRM, щоб підписував DKIM з d=example.com з селектором під їхнім контролем, і встановити кастомний bounce‑домен, щоб SPF теж вирівнювався. Справжній урок: «аутентифікація проходить» ≠ «DMARC проходить». Це коштує грошей.

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

Інша організація мала SPF‑запис, що виглядав як ялинка: includes для кожного інструменту, який колись надсилав пошту. Їм казали про ліміт у 10 DNS‑запитів для SPF, тож інженер «оптимізував», розпластавши SPF у довгий список IP, згенерований щонічно.

Спочатку працювало. Запитів стало менше. Пошта проходила. Усі заспокоїлися.

Але відгукнувся боком: один постачальник обернув IP‑адреси. Нічна задача не вловила зміну через транзитну DNS‑помилку під час побудови. Наступного дня значна частина пошти не пройшла SPF у отримувачів. DKIM мав би врятувати, але цей постачальник не підписував вирівняно. DMARC не пройшов. Quarantine виріс. Пішли звернення до підтримки.

Вони повернулися від flattening і зробили безпечніший підхід: обмежили includes шляхом консолідації постачальників, спростили SPF і наполягли на вирівняному DKIM скрізь, щоб SPF не був єдиною точкою відмови. Оптимізація — добре, але оптимізація без моделювання відмов — це мистецтво продуктивності.

Міні‑історія 3: Сумна, але правильна практика, що врятувала день

Регульований бізнес вів DMARC як операційну програму, а не як галочку. Щотижня вони переглядали: топ джерел, нові джерела, невдачі по отримувачах і короткий список рішень «авторизувати або блокувати». Також вели живий інвентар усіх систем, яким дозволено надсилати пошту від імені домену, з власником, призначенням і механізмом аутентифікації.

Одного понеділка звіт показав новий діапазон IP, що надсилав кілька повідомлень з компанійським From, і всі вони провалювалися по обох SPF і DKIM. Обсяг не був величезний; це б не викликало звичайних тривог «аварія пошти». Але нове джерело вирізнялося на тлі чистої і стабільної базової лінії.

Вони передали безпеку докази: org отримувача, IP, header_from і кількості. Безпека звела це з повідомленнями клієнтів про спрямовану фішингову кампанію щодо зарплат. Оскільки DMARC політика вже була p=reject, сумісні отримувачі відмовляли у прийомі. Радіусу кампанії було обмежено.

Без героїки. Без кризового центру. Просто нудний моніторинг і домен, що вже заслужив примусове застосування. Це вигляд операційної зрілості: менше гучних історій.

Жарт №2: DMARC‑звіти — це єдині листи, що ви коли‑небудь отримаєте, які скаржаться на інші листи, що надсилають листи.

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

1) Симптом: DMARC не проходить, але в звітах SPF показує «pass»

Причина: SPF проходить для домену конверта, але не вирівнюється з Header From (bounce‑домен постачальника).

Виправлення: Налаштуйте кастомний Return‑Path / bounce‑домен під вашим доменом у постачальника, або покладіться на вирівняний DKIM. Перед посиленням політики перевірте вирівнювання у звітах.

2) Симптом: DKIM проходить, але DMARC все одно не проходить

Причина: DKIM‑підпис (значення d=) не вирівнюється з Header From (постачальник підписує своїм доменом).

Виправлення: Налаштуйте DKIM‑підписування вашим доменом і опублікуйте потрібні TXT‑записи селекторів. Підтвердіть, відправивши тестовий лист і перевіривши заголовки в скриньці під вашим контролем.

3) Симптом: Раптовий стрибок SPF permerror

Причина: SPF перевищив ліміт DNS‑запитів через забагато includes/redirects або синтаксична помилка.

Виправлення: Зменшіть includes, видаліть мертвих постачальників і просувайте вирівняний DKIM, щоб SPF не був єдиним вирівняним методом. Валідируйте SPF у CI лакером.

4) Симптом: Все працює, крім отримувачів на конкретному провайдері

Причина: Особливості застосування політики на стороні отримувача, локальні налаштування або різниця в тому, як обробляється пересилання/ARC.

Виправлення: Сегментуйте звіти за org_name отримувача. Для проблемного отримувача перевірте, чи часто відбувається пересилання і чи є вирівняний DKIM (воно більш стійке за SPF).

5) Симптом: DMARC невдачі лише для трафіку розсилок

Причина: Розсилки модифікують повідомлення (ламаючи DKIM) і відправляють від свого інфраструктурного домену (ламаючи вирівнювання SPF).

Виправлення: Віддавайте перевагу DKIM‑підписам, що витримують очікувані модифікації, і оцініть підтримку ARC у отримувачів. Операційно — прийміть деякі невдачі для списків або використайте стратегії з піддоменами.

6) Симптом: Ви ніколи не отримуєте DMARC‑звіти

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

Виправлення: Переконайтеся, що скринька існує, приймає великі листи і маршрутується. Розгляньте окремий піддомен і інфраструктуру пошти для звітів DMARC.

7) Симптом: Звіти показують ваші вихідні IP, що не проходять SPF

Причина: SPF‑запис не включає фактичні IP відправлення (новий MTA, новий релей або трафік переміщено в хмару).

Виправлення: Оновіть includes/IP у SPF, але також впровадьте вирівняний DKIM, щоб пропуск SPF не перетворювався на інцидент з доставкою.

8) Симптом: Подвійні або несумісні підрахунки звітів між отримувачами

Причина: Різні отримувачі вибірково агрегують, по‑різному роблять вибірки або по‑різному атрибутують джерела (особливо з великими спільними інфраструктурами).

Виправлення: Використовуйте звіти для трендів і виявлення нових джерел, а не для точного обліку. Корелюйте з логами відправлення для точних чисел.

Контрольні списки / покроковий план

Покроково: побудуйте робочий процес DMARC, що не гниє

1. Створіть виділені адреси для звітів (агрегатну і опціональну фейлову) і розташуйте їх за поштовим сервісом під вашим контролем. Не вкидайте звіти в чиїсь персональні скриньки.
2. Автоматизуйте інгестію: збирайте вкладення, розпаковуйте, зберігайте сирий XML, парсьте в структуру (таблиці або JSON) і зберігайте оригінали обмежений час.
3. Тегуйте кожний запис за org_name отримувача, report_id, діапазоном дат, header_from, source_ip і результатами політики.
4. Ведіть інвентар відправників: кожний легітимний відправник (MTA, SaaS‑платформа, трекінг‑система, моніторинг), власник і чи використовує він вирівняний DKIM або вирівняний SPF.
5. Встановіть базову лінію і алерти щодо:
   • Нових IP‑джерел
   • Нових header_from доменів/піддоменів
   • Рівня невдач DMARC по отримувачах
   • Будь‑якого зростання quarantine/reject
6. Спочатку виправляйте вирівнювання, потім посилюйте політику. Якщо ви намагаєтеся застосувати примус раніше, команда доставки придумуватиме нові слова для вас.
7. Розгортайте примус поступово: p=quarantine; pct=10, потім 25/50/100, і тільки потім думайте про p=reject з черговим підвищенням.
8. Встановіть зберігання і контроль доступу для звітів, особливо якщо вмикаєте форензічні. Ставтеся до них як до чутливої телеметрії.
9. Проводьте щотижневий перегляд із безпекою та власником меседжингу: топ невдач, нові джерела, зміни постачальників і що потрібно авторизувати.

Операційний чеклист: коли додаєте нового постачальника, що надсилає пошту

• Підтвердіть, чи може постачальник підписувати DKIM з d=yourdomain. Якщо ні — добре подумайте, перш ніж дозволяти йому надсилати від вашого імені.
• Опублікуйте селектори DKIM, які вони надають, з контролем змін і власністю.
• Налаштуйте кастомний bounce‑домен (для вирівнювання SPF), якщо підтримується.
• Надішліть тестові повідомлення до кількох поштових провайдерів і перевірте заголовки на наявність вирівняного pass.
• Слідкуйте за DMARC‑звітами 48 годин після увімкнення; перевіряйте невдачі вирівнювання і неочікувані IP.
• Задокументуйте відправника в інвентарі: власник, призначення, очікувані From‑домени, селектори і шлях ескалації підтримки.

Чеклист управління змінами: перехід від p=none до примусу

• Перелічіть усі відомі легітимні джерела за останні 30 днів агрегатних звітів.
• Для кожного джерела переконайтесь, що принаймні один вирівняний механізм (DKIM бажано) стабільно проходить.
• Підтвердіть, що SPF у межах ліміту запитів і не покладається на крихкі flattening‑завдання.
• Почніть з p=quarantine з низьким pct і налаштуйте сповіщення про зміни рівня quarantine.
• Рухайтеся до p=reject лише після того, як quarantine стабільний і легітимні невдачі близькі до нуля.

Поширені запитання

1) Чи потрібні одночасно і SPF, і DKIM, щоб DMARC пройшов?

Ні. DMARC проходить, якщо або SPF, або DKIM проходить і вирівнюється з Header From доменом. На практиці прагніть до вирівняного DKIM скрізь, а SPF розглядайте як корисний, але крихкий механізм.

2) Чому DMARC‑звіти показують «pass» для DKIM, але «fail» для DMARC?

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

3) Чи агрегатні DMARC‑звіти реального часу?

Ні. Це періодичні підсумки, зазвичай щоденні. Використовуйте їх для трендів і виявлення нових джерел, а не для реакції на інциденти в режимі реального часу.

4) Чи варто вмикати форензічні (RUF) звіти?

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

5) Якщо ми опублікуємо p=reject, чи зникнуть підробки скрізь?

Це зменшить прямі підробки у тих отримувачів, що дотримуються DMARC. Але атакувальники все ще можуть використовувати домени‑клони, скомпрометовані акаунти або канали поза електронною поштою. DMARC — необхідний, але не достатній захід.

6) Чому пересилання ламає аутентифікацію?

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

7) Який найшвидший спосіб виявити нову фішингову кампанію в агрегатних звітах?

Шукайте нові source IP, що надсилають ваш Header From домен з обома SPF і DKIM у fail, особливо якщо кількості швидко зростають або з’являються в кількох org отримувачів.

8) У нас багато піддоменів. Як DMARC має їх обробляти?

Визначте, чи піддомени можуть надсилати пошту, і публікуйте явні DMARC‑записи для тих піддоменів, де потрібно. Якщо ігнорувати піддомени, рано чи пізно хтось інший почне «їх використовувати».

9) Чому підрахунки в DMARC‑звітах відрізняються від наших логів вихідної пошти?

Отримувачі агрегують по‑різному, роблять вибірки і можуть виключати частину пошти. Ваші логи — це правда зі сторони відправника; звіти — спостереження зі сторони отримувача. Використовуйте обидва джерела; не очікуйте ідеальної відповідности.

10) Чи можу я за допомогою DMARC‑звітів знайти кожного стороннього постачальника, що надсилає пошту?

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

Висновок: наступні кроки, що не витратять квартал

DMARC‑звіти — це не архівна вимога для відповідності. Це операційний сигнал. Якщо ставитися до них як до логів — інгест, парсинг, базова лінія, алерти — ви виявите підробки і неконфігурації рано, коли виправлення — це лист до постачальника, а не інцидент бренду.

Зробіть це далі:

1. Перевірте свій DMARC‑запис і впевніться, що агрегатні звіти реально надходять.
2. Побудуйте інвентар відправників і зіставте кожний значний source IP у звітах з власником.
3. Виправляйте вирівнювання для легітимних відправників (переважно вирівняний DKIM), потім поетапно підвищуйте політику від none → quarantine → reject з етапами pct.
4. Налаштуйте алерти для нових джерел і зростання рівня невдач, і переглядайте щотижня з безпекою.

Якщо ви хочете, щоб пошта була нудною — і ви цього хочете — зробіть DMARC‑звітність нудною також. Нудно означає, що ви контролюєте ситуацію.