DMARC вирівнювання: що це і як налаштувати правильно

Ваш лист «проходить SPF» і «проходить DKIM»… і все одно DMARC не проходить, повідомлення потрапляють у спам або, ще гірше, зникають у мовчазній корпоративній поштовій темниці. Це не невдача долі. Це вирівнювання.

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

DMARC вирівнювання простими словами (і чому це важливо)

DMARC — це не стільки про те, чи «працює» SPF або DKIM. Це про те, чи автентифікація, яку ви отримали, відноситься саме до домену, який бачить користувач. Цей домен, видимий користувачу, — це домен у заголовку RFC5322 From: (те, що клієнти пошти показують як відправника).

Вирівнювання означає: домен, який автентифікувався через SPF і/або DKIM, повинний «збігатися» (за строгими або релаксованими правилами) з доменом у From:. DMARC проходить, коли:

• SPF проходить і домен, автентифікований через SPF, вирівнюється з From:, або
• DKIM проходить і домен підпису DKIM вирівнюється з From:.

Більшість збоїв і інцидентів із доставкою трапляються тому, що хтось прочитав «SPF pass» у заголовку й перестав думати. Це як сказати «сертифікат SSL дійсний», не перевіривши, чи він виданий для вашого імені хоста.

Чим вирівнювання не є

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

Чому це важливо в продакшені

Вирівнювання — це спосіб, яким приймачі відрізняють «легітимну пошту від example.com» від «випадкового сервера, який може пройти SPF для mailer.vendor.com, підроблюючи From: example.com». Без вирівнювання SPF/DKIM корисні, але не пов’язують надійно ідентичність бренду. З вирівнюванням і примусом ви отримуєте вимірюване зменшення спуфінгу і чистіший сигнал для потрапляння в папку «Вхідні».

Цікаві факти та коротка історія

• DMARC з’явився тому, що SPF і DKIM вирішували різні задачі, але лишили прогалину: жоден з них не вимагав, щоб автентифікований домен збігався з видимим доменом відправника.
• SPF перевіряє ідентичність «envelope-from» (Return-Path), а не людсько-зрозумілий From:. Така невідповідність — джерело багатьох інцидентів «але SPF пройшов!».
• DKIM спочатку ставив пріоритет на цілісність повідомлення й відповідальність на рівні домену, тому DKIM-підписи переживають багато проміжних кроків, але не всі модифікації.
• DMARC формалізував канали зворотного зв’язку для одержувачів на масштабі через агреговані звіти (RUA), щоб власники доменів могли виявляти невідомих відправників і помилки конфігурації.
• Релаксоване вирівнювання існує, бо інтернет — це безлад: організації регулярно відправляють з піддоменів, і суворе співпадіння заблокувало б легітимні шаблони.
• Форвардинг зламав SPF задовго до DMARC; DMARC дає шлях через DKIM, що виживає при пересиланні, коли IP змінюється.
• «pct» у DMARC створили для поступового впровадження, щоб ви могли застосувати політику без перетворення служби підтримки на відділ психологічної допомоги.
• ARC (Authenticated Received Chain) з’явився пізніше, щоб зберігати результати автентифікації через проміжні вузли — корисно, але це не підстава ігнорувати вирівнювання.

Як вирівнювання працює насправді (SPF vs DKIM)

Почнімо з ідентичностей: три «From», які плутають людей

Електронна пошта має кілька ідентичностей, які схожі, доки не зіпсують вам тиждень:

• RFC5322.From: видимий заголовок From:. DMARC використовує його як орієнтир.
• RFC5321.MailFrom (envelope-from): використовується для отсків; після доставки показується як Return-Path:. SPF автентифікує цей домен.
• DKIM d=: домен підпису в DKIM-підписі. DKIM автентифікує цей домен.

Умова проходження DMARC (операційна версія)

DMARC дивиться на домен у From: і ставить запитання:

1. Чи пройшов SPF для якогось MailFrom-домену?
2. Якщо так — чи вирівнюється той MailFrom-домен з доменом у From:?
3. Чи пройшов DKIM для якоїсь підпису з d=?
4. Якщо так — чи вирівнюється цей d= з доменом у From:?

Якщо проходить або вирівняний SPF або вирівняний DKIM, DMARC проходить. Якщо ні — DMARC не проходить, незалежно від наявності «pass» у інших місцях.

Що на практиці означає «вирівнюється»

Вирівнювання порівнює домени, а не повні адреси. DMARC зазвичай оцінює Організаційний Домен (приблизно: реєстрований домен) на основі Public Suffix List.

Приклади:

• From: billing.example.com вирівнюється (релакс) з mail.example.com, бо обидва мають example.com як організаційний домен.
• From: example.com не вирівнюється з mail.vendor.com. Оце і є суть.

SPF-вирівнювання: чому воно частіше ламається

SPF-вирівнювання використовує домен в envelope-from (MailFrom). Багато SaaS-відправників використовують власний bounce-домен, наприклад bounces.vendor.com. SPF може пройти для нього, але він не вирівняється з From: example.com. Якщо постачальник не підтримує custom MailFrom / branded return-path, вирівнювання не відбудеться.

Також SPF оцінюється проти підключаючогося IP. Форвардери змінюють IP, і SPF «залишає свій ланч-пакет біля спортзалу».

DKIM-вирівнювання: зазвичай надійна опора

DKIM-вирівнювання використовує домен d= у DKIM. Якщо ви можете підписувати з d=example.com (або піддоменом, вирівняним з ним), ви переживете пересилання та багато реле, бо DKIM підписує заголовки та тіло, а не залежить від IP.

Але DKIM уразливий по-іншому: проміжні вузли можуть переписувати повідомлення (підписи внизу, префікси теми, перенос рядків, зміни MIME), і підпис може зламатися. Це не теорія — це вівторок.

Цитата (перефразована думка), яка пасує у ваш поштовий пайплайн

Перефразована думка: надія — не стратегія; використовуйте телеметрію й автоматизацію, щоб зробити відмови видимими й відновлюваними. — від різних інженерів з надійності, популяризовано в культурі SRE

Строге vs релаксоване вирівнювання (aspf/adkim)

DMARC вирівнювання має два регулятори:

• aspf: режим вирівнювання SPF
• adkim: режим вирівнювання DKIM

Релаксоване вирівнювання (r): що воно насправді дозволяє

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

Практична порада: почніть з релаксованого вирівнювання, якщо у вас немає вагомої причини переходити на суворе. Строге не обов’язково «безпечніше», якщо воно штовхає команди до хаків або ускладнює налаштування постачальників.

Строге вирівнювання (s): коли можна дозволити собі бути прискіпливими

Строге означає, що домени мають точно збігатися. Якщо ваш видимий From: — example.com, то MailFrom для SPF має бути example.com (не bounce.example.com), і DKIM d= має бути example.com (не mail.example.com).

Строге вирівнювання підходить, якщо:

• ви маєте жорсткий контроль над усіма вихідними відправниками, і
• ви не покладаєтеся на безліч SaaS-платформ, і
• ви готові розробити процеси, щоб це підтримувати.

Жарт #1: Строге вирівнювання — як дрес-код у стартапі: звучить рішуче, доки не помітиш, що ваш CEO в худі з плямами з 2017 року.

Піддомени: вирівнювання та спадкування DMARC

Політика DMARC, опублікована на _dmarc.example.com, застосовується до example.com. Піддомени можуть успадковувати політику, якщо ви не публікуєте окремі записи, і ви можете використовувати тег sp=, щоб вказати політику для піддоменів.

Операційно, піддомени — це місце, де «плутанина вирівнювання» стає «інцидентом вирівнювання». Маркетинг хоче news.example.com, продукт — notify.example.com, підтримка — support.example.com, а хтось в HR підключає новий сервіс опитувань, який наполягає на From: example.com, бо «бренд». Ось так виникають масштабні проблеми з DMARC.

Як проєктувати вирівнювання для реальних відправників (люди, додатки, SaaS)

Визначте стратегію домену у From:

Вам потрібна узгоджена політика щодо того, що з’являється в From:. Виберіть один з цих підходів і дотримуйтеся його:

• Шаблон A: один домен для всього (From: example.com). Простіш для користувачів; складніше для вирівнювання, бо кожен відправник має вирівнюватися ідеально.
• Шаблон B: функціональні піддомени (billing.example.com, news.example.com). Чіткіше розмежування і легша інтеграція постачальників. Користувачі помічають це, але також помічають, коли ваша пошта не доходить.
• Шаблон C: виділений домен для відправки (mail.example.com) з корпоративним example.com для людей. Рекомендується, бо зменшує радіус ураження.

Мій пріоритет: Шаблон B або C. Якщо ваш домен — як спільна кухня, не кладіть сире м’ясо поруч із тортом.

Визначте, як DMARC має проходити: «DKIM-перший» — зазвичай розумно

Для сучасних екосистем вихідної пошти розглядайте вирівнювання DKIM як основний шлях для проходження DMARC. Налаштуйте SPF теж, але не сподівайтеся, що він переживе пересилання, розсилки та «допоміжні» шлюзи.

Контрольний список для підключення постачальників (фокус на вирівнюванні)

Коли SaaS-платформа надсилає від вашого імені, вам потрібні ці можливості:

• Custom DKIM з d= у вашому домені (або вирівняному піддомені).
• Custom MailFrom / return-path (опційно, але корисно) для отримання SPF-вирівнювання теж.
• Підтримка кількох DKIM-селекторів для ротації ключів без простоїв.
• Чітка документація щодо переписування заголовків, щоб DKIM виживав.

Якщо вони не підтримують custom DKIM, не дозволяйте їм використовувати ваш основний домен у From:. Дайте їм піддомен або іншу поверхню бренду. DMARC — це політика. Політика може казати «ні».

Як вирівнювання взаємодіє з розсилками та пересиланням

Мейлінг-розсилки часто модифікують повідомлення (додають футери, префікси теми). Це може зламати DKIM. Форвардери ламають SPF. DMARC стоїть посередині і каже: «принесіть мені вирівняну автентифікацію».

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

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

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

Завдання 1: Отримати DMARC-запис і швидко перевірити теги

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

Що це означає: DMARC існує, політика — quarantine, обидва вирівнювання релаксовані, повний rollout.

Рішення: Якщо ви все ще бачите відмови DMARC, проблема в вирівнюванні/автентифікації, а не в «відсутньому записі». Якщо p=none, ви в режимі спостереження і повинні планувати накладення політики.

Завдання 2: Перевірити DMARC для піддомену, який ви вважаєте «покритим»

cr0x@server:~$ dig +short TXT _dmarc.news.example.com

Що це означає: Явного DMARC-запису на піддомені немає.

Рішення: Підтвердіть, чи ви покладаєтеся на спадкування і чи встановлено sp= на організаційному домені. Якщо маркетинг надсилає з news.example.com, вам, ймовірно, потрібен явний запис (або принаймні свідомо обрана політика sp=).

Завдання 3: Перевірити, чи є SPF для домену в From (не достатньо, але необхідно)

cr0x@server:~$ dig +short TXT example.com | sed -n 's/.*"\(v=spf1[^"]*\)".*/\1/p'
v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Що це означає: SPF авторизує конкретний IP і набір Google. Політика SPF закінчується -all (жорстке відхилення).

Рішення: Якщо ви використовуєте SaaS-відправників, переконайтеся, що їхні діапазони включені (безпосередньо або через include). Але також: плануйте вирівнювання SPF, контролюючи MailFrom, а не тільки «SPF існує».

Завдання 4: Порахувати DNS-пошуки SPF (прихований режим відмов)

cr0x@server:~$ spfquery -debug -ip 203.0.113.10 -sender bounce@example.com -helo mx.example.com 2>&1 | tail -n 12
...
spfquery: using default zone: example.com
spfquery: found TXT record: v=spf1 ip4:203.0.113.10 include:_spf.google.com -all
spfquery: include:_spf.google.com
spfquery: result: pass

Що це означає: Оцінка SPF для цього відправника/IP проходить.

Рішення: Якщо ви бачите помилки ліміту пошуків у реальних заголовках (permerror), потрібно спростити або «зламати» SPF. «Pass» у лабораторії — не доказ, якщо в продакшені є більше include, ніж ви тестували.

Завдання 5: Отримати TXT-записи селектора DKIM (постачальник або внутрішній)

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

Що це означає: Публічний ключ DKIM опубліковано для селектора s1.

Рішення: Якщо DKIM не проходить у приймача, підтвердіть, що підписувач використовує цей селектор і домен. Якщо постачальник каже «ми підписуємо», перевірте реальні d= і s= у заголовках.

Завдання 6: Переглянути реальний заголовок повідомлення для підказок по DMARC/SPF/DKIM та вирівнюванню

cr0x@server:~$ grep -E '^(From:|Return-Path:|Authentication-Results:|DKIM-Signature:)' -n sample.eml | sed -n '1,120p'
3:From: "Example Billing" <billing@example.com>
8:Return-Path: <bounce-123@mailer.vendor.com>
41:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailer.vendor.com; s=dkim1; ...
72:Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce-123@mailer.vendor.com designates 203.0.113.55 as permitted sender) smtp.mailfrom=bounce-123@mailer.vendor.com;
       dkim=pass header.i=@mailer.vendor.com header.s=dkim1 header.b=...;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Що це означає: SPF пройшов для mailer.vendor.com і DKIM пройшов для mailer.vendor.com, але From: — example.com. Жоден із них не автентифікує example.com. DMARC не проходить через невирівнювання.

Рішення: Попросіть постачальника підтримати custom DKIM (підпис з d=example.com або вирівняного піддомену) і бажано custom MailFrom. Якщо не можуть — змініть видимий домен From на піддомен, який відправник може вирівняти (наприклад, billing.example.com) і опублікуйте там DMARC.

Завдання 7: Перевірити, що DKIM вирівнюється з From (порівняння доменів)

cr0x@server:~$ python3 - <<'PY'
import re,sys
data=open("sample.eml","r",errors="ignore").read().splitlines()
from_dom=None
dkim_d=None
for line in data:
    if line.lower().startswith("from:"):
        m=re.search(r'@([A-Za-z0-9.-]+)', line)
        if m: from_dom=m.group(1).lower()
    if line.lower().startswith("dkim-signature:"):
        m=re.search(r'\bd=([A-Za-z0-9.-]+)', line)
        if m: dkim_d=m.group(1).lower()
print("from=",from_dom)
print("dkim d=",dkim_d)
PY
from= example.com
dkim d= mailer.vendor.com

Що це означає: Не вирівнюється ні за суворим, ні за релаксованим режимом (різні організаційні домени).

Рішення: Виправити домен підписування DKIM або перемістити домен From так, щоб він відповідав тому, що можна автентифікувати.

Завдання 8: Переконатися, що MTA дійсно підписує DKIM для потрібного домену

cr0x@server:~$ sudo opendkim-testkey -d example.com -s s1 -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: key OK

Що це означає: Селектор присутній і відповідає приватному ключу, налаштованому локально (з погляду OpenDKIM).

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

Завдання 9: Підтвердити, який Return-Path / MailFrom використовує ваша система відправки

cr0x@server:~$ postconf -n | grep -E '^(myhostname|mydomain|myorigin|smtp_mail_name|sender_canonical_maps|smtp_generic_maps)'
myhostname = mx1.example.com
mydomain = example.com
myorigin = $mydomain

Що це означає: Базова ідентичність Postfix. Це не гарантує вирівнювання MailFrom, але дає уявлення про значення за замовчуванням і чи є карти переписування.

Рішення: Якщо реле або додаток встановлюють envelope-from по-іншому, відстежте це. Вирівнювання SPF часто означає контроль цієї envelope-ідентичності, а не тільки DNS.

Завдання 10: Протестувати SMTP-подачу і зафіксувати, що сервер додає

cr0x@server:~$ swaks --to you@recipient.test --from billing@example.com --server smtp.example.com --data <(printf 'Subject: test\n\nhello\n') --header "Date: $(date -R)"
=== Trying smtp.example.com:25...
=== Connected to smtp.example.com.
<** 250 2.0.0 Ok: queued as 9F2A8123

Що це означає: Повідомлення прийнято для доставки.

Рішення: Отримайте заголовки доставленого повідомлення на стороні одержувача (або в вашій тестовій поштовій скриньці) і перевірте DKIM d=, SPF smtp.mailfrom і результат DMARC. «Queued» не означає «вирівняно».

Завдання 11: Швидко розпарсити Authentication-Results для вирівнювальних ідентифікаторів

cr0x@server:~$ awk 'BEGIN{RS="";FS="\n"} {for(i=1;i<=NF;i++) if($i ~ /^Authentication-Results:/) print $i}' sample.eml
Authentication-Results: mx.google.com;
       spf=pass ... smtp.mailfrom=bounce-123@mailer.vendor.com;
       dkim=pass header.i=@mailer.vendor.com ...;
       dmarc=fail ... header.from=example.com

Що це означає: Показує ідентичності, які використав приймач: smtp.mailfrom і header.i проти header.from.

Рішення: Якщо smtp.mailfrom або header.i не з вашої сім’ї доменів, вирівнювання не може пройти. Виправляйте відправника, а не DMARC-запис.

Завдання 12: Перевірити логіку організаційного домену (пастки Public Suffix)

cr0x@server:~$ python3 - <<'PY'
from publicsuffix2 import get_sld
tests=["example.com","billing.example.com","example.co.uk","a.b.example.co.uk"]
for t in tests:
    print(t,"->",get_sld(t))
PY
example.com -> example.com
billing.example.com -> example.com
example.co.uk -> example.co.uk
a.b.example.co.uk -> example.co.uk

Що це означає: Релаксоване вирівнювання DMARC порівнює організаційні домени, які відрізняються для суфіксів на кшталт .co.uk.

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

Завдання 13: Перевірити поведінку DMARC sp= для піддоменів

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

Що це означає: Кореневий домен — reject; піддомени за замовчуванням підлягають quarantine, якщо не перевизначено.

Рішення: Якщо ви мігруєте відправників на піддомени, щоб зменшити ризик, sp може вас здивувати. Явний DMARC на піддомені уникне питань «чому маркетинг опинився в quarantine?».

Завдання 14: Підтвердити, що домен має дійсний MX і не містить опечаток (таке буває)

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

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

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

Завдання 15: Перевірити наявність кількох DMARC TXT-записів (хаос залежно від приймача)

cr0x@server:~$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
"v=DMARC1; p=reject; rua=mailto:security@example.com"

Що це означає: Існує два DMARC-записи. Це недійсно; приймачі можуть вибрати один, ігнорувати обидва або поводитися непередбачувано.

Рішення: Виправіть DNS негайно: публікуйте рівно один DMARC-запис на домен. Це «зупиніть кровотечу» перед глибшою діагностикою.

Швидкий план діагностики

Якщо у вас є 15 хвилин до ескалації «збої електронної пошти», не блукайте. Перевірте це в порядку пріоритету.

Перше: підтвердіть, що відмова — через вирівнювання, а не базову автентифікацію

1. Витягніть заголовок невдалого повідомлення з поштової скриньки одержувача (краще Gmail або Microsoft — вони деталізовані).
2. Знайдіть Authentication-Results і прочитайте три поля: header.from, smtp.mailfrom і header.i (DKIM-ідентичність).
3. Якщо SPF/DKIM «pass», але ідентичності не збігаються з header.from, це вирівнювання.

Друге: визначте, який шлях має бути вашим основним для проходження DMARC

• Якщо пошта пересилається або проходить через проміжні вузли: віддавайте пріоритет DKIM-вирівнюванню.
• Якщо пошта прямою лінією до одержувача з стабільними IP і контрольованим MailFrom: SPF-вирівнювання може бути надійним.
• Якщо обидва не проходять: або ви не підписуєте коректно, або дозволяєте постачальникам надсилати «від вашого імені» без контролю доменів.

Третє: встановіть, хто відправляє невирівняну пошту

• Перевірте Return-Path — часто показує постачальника.
• Перевірте DKIM d= — показує домен підписувача.
• Порівняйте зі списком авторизованих відправників. Якщо списку немає — вітаємо: ви знайшли причину існування DMARC-звітів.

Четверте: оберіть найменш ризикове виправлення

• Найкраще виправлення: налаштувати custom DKIM для вашого домену на тому відправнику.
• Наступне по корисності: перемістити видимий From на виділений піддомен, який відправник може вирівняти, і опублікувати DMARC на цьому піддомені.
• Уникайте: постійного послаблення політики DMARC як рішення. Тимчасове зниження pct може допомогти під час інциденту; постійне — повертає спуфінг.

Жарт #2: Якщо ви «пофіксили DMARC» встановленням p=none, це не вирішення; це наклеювання стикера на пожежний датчик.

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

1) «SPF=pass, DKIM=pass, DMARC=fail»

Симптом: Authentication-Results показує SPF pass і DKIM pass, але DMARC fail.

Корінна причина: SPF і DKIM автентифікували інші домени, ніж видимий From:. Типово з SaaS-постачальниками, які використовують власний Return-Path і d=.

Виправлення: Увімкніть custom DKIM підписування для вашого домену (вирівняний d=). Опційно налаштуйте custom MailFrom для вирівнювання SPF.

2) DMARC ламається тільки при пересиланні

Симптом: Прямі одержувачі отримують у вхідні; переслані — у quarantine/reject.

Корінна причина: Форвардери ламали SPF через зміну IP; DKIM може бути відсутній або зламаний, і тоді немає шляху вирівнювання.

Виправлення: Увімкніть DKIM-підписування і зробіть його стійким під час типового транзиту. Не покладайтеся лише на SPF для проходження DMARC, якщо пересилання поширене.

3) DKIM проходить у ваших тестах, але падає в реальності

Симптом: Деякі приймачі показують dkim=fail (bad signature), інші — pass.

Корінна причина: Проміжні вузли змінюють повідомлення (футери, дисклеймери, банери «зовнішній відправник», MIME-конверсії). Або підписувач включає нестабільні заголовки в підпис.

Виправлення: Налаштуйте DKIM: оберіть адекватну canonicalization, підписуйте стабільні заголовки, і усуньте шлюзи, які переписують контент після підпису (або підписуйте після переписування).

4) «Ми встановили aspf=s і все зламалося»

Симптом: Сплеск відмов DMARC після переходу на суворе вирівнювання.

Корінна причина: Ваш MailFrom — піддомен (наприклад, bounce.example.com) або постачальник використовує власний return-path. Строге потребує точного співпадіння.

Виправлення: Використовуйте релаксоване вирівнювання (aspf=r), якщо не можете гарантувати точне-міждоменне MailFrom всюди. Або змініть видимий From на домен, який точно співпадатиме.

5) Випадкова, непослідовна поведінка DMARC серед приймачів

Симптом: Gmail каже DMARC pass, Microsoft — fail, менші провайдери — різно.

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

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

6) Пошта піддомену відхиляється після примусового застосування політики на корені

Симптом: Пошта від news.example.com почала падати після того, як ви ввели примус на example.com.

Корінна причина: Піддомен успадковує політику, а відправник не вирівнюється для цього піддомену. Або застосовано sp=reject.

Виправлення: Опублікуйте явний DMARC для піддомену і налаштуйте DKIM/SPF для нього; або свідомо налаштуйте sp.

7) DKIM вирівнюється, але DMARC все одно не проходить

Симптом: Ви бачите dkim=pass з d=example.com, але DMARC fail.

Корінна причина: Може бути, що підпис, який проходить, не є тим, який вирівнюється (кілька підписів), або приймач вибрав інший результат DKIM як «найкращий» (нюанси реалізації), або видимий From — інший домен, ніж очікувалося.

Виправлення: Ретельно інспектуйте Authentication-Results, щоб побачити, який підпис оцінювали і який header.from. Переконайтеся, що вирівняний DKIM-підпис присутній і дійсний у приймача.

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

Покроковий план впровадження, який уникне самонанесених збоїв

1. Перелік відправників. Занотуйте кожну систему, що може відправляти з вашим доменом у From:: M365/Google Workspace, тикетинг, CI/CD оповіщення, CRM, маркетинг, білінг, моніторинг, люди з SMTP-клієнтів.
2. Виберіть архітектуру From-домену. Віддавайте перевагу виділеному домену відправки або функціональним піддоменам, щоб ізолювати постачальників.
3. Увімкніть DKIM скрізь, де можливо. Якщо відправник не може підписувати вашим доменом, не дозволяйте йому використовувати ваш кореневий From-домен.
4. Опублікуйте SPF обережно. Тримайте його в межах лімітів DNS-пошуків; уникайте неконтрольованих ланцюжків include.
5. Опублікуйте DMARC з p=none спочатку. Додайте rua для збору агрегованих звітів. Тримайте вирівнювання релаксованим, якщо не впевнені.
6. Переглядайте DMARC-звіти і виправляйте прогалини у вирівнюванні. Тут ви знайдете «таємного відправника», про якого продукт забув.
7. Перейдіть на p=quarantine з pct менше 100, якщо потрібно. Використовуйте pct як запобіжник, а не як стиль життя.
8. Перейдіть на p=reject, коли впевнені. Спуфінг перестане бути проблемою бренду і стане проблемою приймача.
9. Автоматизуйте постійні перевірки. Ротація DKIM-ключів, дрейф DNS, зміни постачальників і поглинання — це те, де вирівнювання тихо деградує.

Операційний чекліст для кожного нового відправника (надрукуйте або закріпіть у процесі закупівель)

• Яким буде видимий домен у From:?
• Чи платформа підписує DKIM з d= у нашому домені (або вирівняному піддомені)?
• Чи можемо ми встановити custom MailFrom / return-path у нашому домені для вирівнювання SPF?
• Які селектори використовуються, і чи можна обертати ключі без простоїв?
• Чи переписують вони повідомлення після підпису (футери, трекінг, зміни open/click)?
• Чи підтримують вони окремі домени для середовищ (prod vs staging)?
• Як ми тестуватимемо перед запуском (seed list, захоплення заголовків, валідація DMARC)?

Три корпоративні міні-історії з реальних випадків

Міні-історія 1: Інцидент через неправильне припущення

Компанія щойно перенесла транзакційну пошту до нового провайдера. План міграції був простим: оновити SPF, додати DKIM «бо є галочка», потім посилити DMARC до p=reject після тижня спокою.

На другий день підтримка почала отримувати тікети: скидання паролів не доходили до частини користувачів — переважно великих провайдерів з агресивним фільтруванням. Інженери перевірили логи, підтвердили, що листи поставлені в чергу і що API провайдера повернув успіх. Тобто «пошта в порядку».

Потім хтось подивився реальний заголовок одержувача. SPF пройшов. DKIM пройшов. DMARC провалився. From: був example.com, але постачальник підписував з d=vendor-mail.com і використовував Return-Path під vendor-bounce.com. Команда припускала «pass = pass». DMARC цього не врахував.

Виправлення не було героїчним: налаштували custom DKIM для example.com у постачальника і вирівняли bounce-домен під контролем у піддомені. Доставляння відновилося. Великий культурний здобуток: постмортем додав правило — жодних змін політик без перевірки вирівнювальних ідентичностей у Authentication-Results принаймні у двох великих приймачів.

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

Інша організація захотіла «очистити DNS». Їхній SPF набрався до монстра includes, бо кожен відділ додавав постачальників. Хтось запропонував «заплющити» SPF, перетворивши includes на статичний список IP. Менше DNS-пошуків. Швидше оцінювання. Усі кивнули.

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

«Оптимізація» замінила динамічні include (що адаптувалися до змін IP) на крихкий знімок. Режим відмови не лише SPF fail. Він каскадував у DMARC, перетворивши зміну IP у постраждалого постачальника на інцидент для клієнта.

Затверджений дизайн був нудніший: відновити include постачальника, видалити застарілі include, розділити відправників по піддоменах з явним DKIM-вирівнюванням і відстежувати кількість SPF-пошуків у CI. Розумна частина — не DNS-фокус, а проєктування шляху автентифікації так, щоб дрейф одного постачальника не ламав DMARC.

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

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

Одного тижня тести показали, що маркетингова пошта все ще доходить, але вирівнювання DKIM змінилося: d= стало vendor.com замість news.example.com. DMARC проходив лише тому, що ще працювало вирівнювання SPF, і лише для прямих одержувачів. Переслані одержувачі впали б наступного разу, як тільки їхній корпоративний шлюз почав би маршрутизувати через новий хоп.

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

Команда відкрила тікет, відновила custom DKIM і додала пункт у контракт: зміни, що впливають на ідентичності відправки, мають бути анонсовані. Виправлення було банальним. Збереження — величезним. Ось як виглядає «операційна досконалість», коли ніхто не аплодує.

Часті питання (FAQ)

1) Якщо SPF проходить, чому DMARC не проходить?

Тому що SPF може проходити для envelope-from домену, і DMARC вимагає, щоб цей домен вирівнювався з видимим From:. SPF pass без вирівнювання — поширене явище з третіми відправниками.

2) Чи покладатися на SPF- чи DKIM-вирівнювання?

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

3) Що конкретно змінюють «adkim» і «aspf»?

Вони встановлюють строгий (s) або релаксований (r) режим вирівнювання для DKIM і SPF. Релаксований дозволяє піддомени (той самий організаційний домен). Строгий вимагає точного співпадіння.

4) Чи завжди строге вирівнювання безпечніше?

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

5) Чому DMARC ламається, коли розсилка додає футер?

Бо DKIM-підписи покривають частини тіла й заголовків. Якщо список змінює тіло, DKIM може зламатися. Якщо SPF також падає через пересилання, DMARC не проходить.

6) Чи можна виправити вирівнювання, змінивши лише DMARC-запис?

Рідко. Політика DMARC не створює вирівнювання — вона його оцінює. Більшість виправлень у конфігурації відправника: домен підписування DKIM, MailFrom домен або стратегія видимого From.

7) Який найбезпечніший шлях перейти на p=reject?

Почніть із p=none з агрегованими звітами, виправте всі відомі відправники, потім перейдіть на p=quarantine з контролем pct за потреби, а потім — на p=reject. Не пропускайте етап «виправити відправників».

8) Чи потрібен custom return-path, якщо вже є DKIM-вирівнювання?

Не обов’язково, але корисно. Наявність і вирівнювання SPF та DKIM робить вашу пошту більш стійкою до особливостей приймачів та проміжних вузлів.

9) Як піддомени впливають на вирівнювання?

У релаксованому режимі піддомени вирівнюються, якщо вони ділять організаційний домен. У строгому — ні. Політика DMARC також може по-різному застосовуватися до піддоменів через sp або явні піддоменні записи.

10) Який найшвидший доказ того, що постачальник не може відповідати вимогам DMARC?

Надішліть тестовий лист і проаналізуйте заголовки: якщо DKIM d= і SPF smtp.mailfrom — домени постачальника й це незмінно, вони не зможуть вирівнятися з вашим From:, доки не підтримається custom-ідентичність.

Висновок: наступні дії, що справді знижують ризик

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

Зробіть наступне, у порядку пріоритету:

1. Визначте стратегію From-домену (корінь vs піддомени vs виділений домен відправки). Зробіть це політикою, а не побажанням кожної команди.
2. Зробіть DKIM-вирівнювання стандартом для кожного відправника, особливо постачальників.
3. Використовуйте DMARC-звіти і перевірку заголовків як телеметрію, а не як формальність.
4. Поступово переходьте до примусу (none → quarantine → reject), використовуючи pct як запобіжник — не як постійний засіб.
5. Операціоналізуйте процес: щотижневий seed-тест із збереженням заголовків виявляє «постачальник відкотив налаштування» ще до клієнтських проблем.