Доставляння пошти: єдина політика DMARC, що зупиняє підробки без втрат листів

Єдина політика DMARC (і чому вона працює)

Якщо ви хочете захист від підробок без втрати легітимної пошти, не починайте з «p=reject» і емоцій. Почніть із політики, яка
змушує автентифікацію стати реальною, вимірюваною та виконуваною — одночасно даючи вам запасний вихід для проблемних аспектів пошти (форвардинг,
зламані розсилки, сторонні відправники та застарілі системи, що думають, ніби «DKIM» — новий музичний фестиваль).

Політика

Практичний стандарт, який я рекомендую для більшості організацій, що відправляють реальну пошту і мають принаймні одного стороннього відправника:
DMARC на організаційному домені з p=quarantine, pct=100, жорстким вирівнюванням DKIM (adkim=s), розслабленим вирівнюванням SPF (aspf=r) та адекватною конфігурацією звітності.
Потім переходьте на p=reject, коли ваші автентифіковані потоки будуть чистими.

Приклад запису (налаштуйте під свій домен і скриньку для звітів):

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

Чому саме така конфігурація?

• p=quarantine at pct=100: ви застосовуєте політику, але так, щоб відхилення зазвичай йшли в спам замість повного відкидання.
  Це тримає бізнес-пошту в руслі, поки ви чистите відправників. Ви не «моніторите»; ви змінюєте наслідки.
• adkim=s (жорстке вирівнювання DKIM): DKIM — найнадійніший шлях через форвардинг і сучасну поштову інфраструктуру.
  Жорстке вирівнювання змушує ваших постачальників і системи підписувати від вашого домену (або коректно організованою стратегією піддоменів).
• aspf=r (розслаблене вирівнювання SPF): SPF постійно ламається через форвардинг і NAT’овані реле. Розслаблене вирівнювання SPF
  рятує вас від покарання легітимних потоків, поки ви мігруєте світ до DKIM-першої автентифікації.
• sp=quarantine: не забувайте про піддомени. Атакувальники не забувають.
• rua/ruf/fo: вам потрібна телеметрія. Не ідеальна, але достатня, щоб ідентифікувати, які системи падають і чому.

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

Одна цитата, яка й досі справджується в операціях: адаптована ідея від Werner Vogels: «Все ламається постійно; проектуйте і експлуатуйте з цим урахуванням.»
Впровадження DMARC ламається по нудних причинах. Плануйте це, і ви не дізнаєтеся цього дорогою ціною.

Жарт №1: Аутентифікація пошти — єдина система безпеки, де «форвардинг» вважається «порушенням», але всі все одно так роблять.

Коли можна відразу ставити p=reject

Рідко, але таке буває. Якщо ваш домен не використовується для жодної легітимної пошти (зареєстрований домен без пошти або бренд-домен, що лише редіректить на
окремий поштовий домен), то йдіть одразу до:

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

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

DMARC у виробничих термінах: що насправді відбувається з повідомленням

DMARC — це політика, яку оцінює отримувач (Gmail, Microsoft, Yahoo, шлюз вашого клієнта). Він читає ваш DNS-запис, перевіряє результати автентифікації повідомлення
і вирішує, що робити далі.

Три домени, що мають значення (і чому люди плутаються)

• Header From: домен, який люди бачать у заголовку From:. DMARC вирівнюється саме з ним. Це ідентичність, яку ви захищаєте.
• SPF domain: домен, що використовується під час SMTP MAIL FROM / Return-Path перевірки. Часто це домен для відскоків.
• DKIM d= domain: домен, який підписує повідомлення.

DMARC проходить, якщо (SPF проходить і вирівнюється) АБО (DKIM проходить і вирівнюється).
Потім отримувачі застосовують вашу політику: none, quarantine або reject.

Вирівнювання: та частина, на якій усі спотикаються

Вирівнювання — це правило порівняння рядків, а не філософська концепція.

• Розслаблене вирівнювання (r): піддомени вирівнюються. mail.example.com вирівнюється з example.com.
• Жорстке вирівнювання (s): має точно співпадати. mail.example.com не вирівнюється з example.com.

Чому бути жорстким щодо DKIM, але розслабленим щодо SPF у рекомендованій політиці?
Тому що DKIM — це тривала ідентичність. SPF — перевірка IP-шляху; шлях змінюється. DKIM переживає, коли повідомлення бере «мальовничий маршрут».

Реальність доставляння: отримувачі використовують не тільки DMARC

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

Якщо ви хочете зупинити підробки без втрат листів, ставтеся до DMARC як до rollout розподіленої системи: спостерігайте, примусово застосовуйте поступово, валідуйте телеметрією, потім загортайте.

Цікаві факти та історичний контекст (те, що пояснює дивності)

• DMARC з’явився тому, що SPF і DKIM вирішували різні частини проблеми. SPF автентифікує шлях відправлення; DKIM автентифікує повідомлення. Жоден окремо не захищає надійно видимий домен From.
• SPF передував широкому поширенню хмарної пошти. Він проектувався в часи, коли «сервер, що відправляє вашу пошту», був більш стабільною концепцією, ніж нині.
• DKIM створювали, щоб переживати форвардинг. Він підписує тіло повідомлення та обрані заголовки, тож може проходити, навіть коли шлях SMTP змінюється — якщо тільки форвардер не переписує вміст.
• DMARC — політика, що керується отримувачем. Ви публікуєте політику; отримувачі вирішують виконання. Тому «ми поставили p=reject» не означає, що всі відправлять відкидання однаково.
• DMARC популяризував звітування по домену в масштабі. Агреговані звіти (RUA) стали першим послідовним способом для багатьох організацій інвентаризувати невідомих відправників.
• Політика для піддоменів (sp=) існує, бо нападники люблять піддомени. Організації їх забувають; фішери — ні.
• Ранні впровадження DMARC спиралися на quarantine. Організації навчилися, що прямий перехід на reject часто ламає легітимні маркетингові і тікетингові потоки.
• ARC з’явився здебільшого через побічні ефекти DMARC. Форвардинг і розсилки можуть ламати DMARC; ARC допомагає зберегти контекст автентифікації між хопами.
• «p=none» не безпечний. Це режим моніторингу, але він також посилає сигнал отримувачам, що ви не застосовуєте політику. Це може впливати на те, наскільки серйозно вони ставляться до спроб підробки.

Коротка історія №1: хибне припущення, що зламало вихідну пошту

Середня SaaS-компанія вирішила «завершити проєкт DMARC» перед річним аудитом відповідності. У них був SPF, у них був DKIM (деінде),
і був електронний список постачальників. Хтось припустив, що цього достатньо.

Вони переключили DMARC з p=none на p=reject на кореневому домені пізно в п’ятницю. У понеділок вранці customer success не міг надіслати документи для онбордингу.
Продавці скаржилися, що потенційні клієнти «перестали відповідати». Фінанси сказали, що рахунки повертаються. Підтримка накопичила тікети зі скриншотами
«message rejected due to DMARC policy».

Насправді проблема була нудною: їх CRM відправляв листи, використовуючи Return-Path домен, що належав постачальнику (SPF проходив, але не вирівнювався), а DKIM-підпис
використовував d=vendor.example (DKIM проходив, але не вирівнювався). При p=none нікому це не було важливо. При p=reject отримувачі звернули увагу.

Виправлення не було героїчним. Вони налаштували у постачальника підписування з d=their-domain.example за допомогою власного DKIM-ключа і встановили виділений домен відскоку,
який вирівнювався. Головний урок: проходження автентифікації замало; вона має вирівнюватися з доменом у From.

Вони також навчилися ніколи не впроваджувати застосування політики без останньої бази звітів. Звіти надходили в необслуговувану скриньку.
Телеметрія, яку ніхто не читає, — це перформанс-арт.

Коротка історія №2: оптимізація, що відкотилася

Велика компанія з кількома бізнес-одиницями хотіла зменшити DNS-запити від SPF через ліміт у 10 запитів. Інженер запропонував оптимізацію: замінити ланцюг include одним
include від постачальника і звузити SPF до невеликого набору IP «для безпеки».

Зміна зменшила запити. Вона також спричинила періодичні SPF softfail і permerror для легітимної пошти, бо частина пошти йшла через регіональні роутери, яких не було в «вужчому» списку. Ще гірше: IP маркетингової платформи ротаційно змінювалися, а include постачальника, на який вони покладались, не відповідав фактичному потоку їхнього акаунту.

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

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

Розв’язання полягало в тому, щоб припинити розглядати SPF як первинну ідентичність. Вони відновили SPF до стабільної, коректної бази й віддали пріоритет підписанню DKIM на кожному вихідному потоці, використовуючи вирівняні d= домени. Оптимізація була реальна, але її застосували не до того шару. SPF має бути точним і мінімальним, а не «хитрим».

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

Інша організація — неефектна, але операційно зріла — мала практику: кожна вихідна система мала власника, runbook і щомісячний перегляд звітів DMARC.
Ніхто за це не отримував підвищення. Ось чому це працювало.

Вони тримали DMARC у p=quarantine кілька місяців, поки мігрували постачальників. Кожного разу, коли новий відправник з’являвся в RUA-звітах, створювався тікет:
знайти власника, верифікувати потік, налаштувати DKIM з вирівняним d= і підтвердити вирівнювання SPF або задокументувати, чому його не будуть покладати.

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

Найкраща частина: їм не довелося метушитися. Вони вже мали налаштовані ручки. Вони просто посилили моніторинг і перевірили, що жоден легітимний потік не регресував. Ось як «нудне» платить вашу зарплату.

Жарт №2: Найбільш надійна пошта — та, про яку ніхто не помічає, — поки фінансовий директор не може надіслати таблицю, і раптом це «пріоритетний інцидент».

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

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

Перше: підтвердьте, яку доменну ідентичність ви захищаєте

• Який домен у Header From бачать користувачі?
• Це кореневий домен, піддомен чи похожий домен?
• Чи є у вас DMARC-запис саме для цього домену (включно з поведінкою політики для піддоменів)?

Друге: перевірте оцінку DMARC на реальному зразку

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

Третє: перелікуйте відправників за допомогою агрегованих даних DMARC

• Які IP відправляють від імені вашого домену?
• Які джерела падають і в якому обсязі?
• Чи сконцентровані відмови в якогось постачальника, регіону або конкретного застосунку?

Четверте: вирішіть, пов’язана відмова з політикою чи з репутацією

• Якщо бачите жорсткі відмови з повідомленнями про DMARC — це питання застосування/вирівнювання.
• Якщо бачите «accepted but spam», це може бути репутація, вміст або непослідовність автентифікації (переривчастий DKIM, permerror SPF тощо).

П’яте: змінюйте по одному кроку

Пошта — це розподілена система, якою ви не повністю керуєте. Якщо одночасно зміните DMARC, SPF, DKIM і інфраструктуру відправлення, ви нічого не дізнаєтеся
і все одно щось зламаєте.

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

Це практичні завдання, які можна виконати в shell. Передбачається, що у вас є базові DNS-інструменти та доступ до заголовків повідомлень у скриньці.
Для аналізу заголовків ви вставляєте вміст у локальні файли. Суть не в інструментах, а в ухваленні рішень.

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

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

Що означає вивід: У вас є DMARC-запис, це DMARC1, і політика — quarantine для домену й піддоменів.

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

Завдання 2: Підтвердьте, що у вас немає кількох TXT-записів DMARC (класична пастка)

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

Що означає вивід: Відповідь містить рівно один запис у секції answer.

Рішення: Якщо ви бачите два TXT-відповіді, об’єднайте їх в один. Деякі отримувачі вибирають один з них довільно — це як рулетка з виплатою зарплат.

Завдання 3: Перевірте SPF-запис і виявте проблему з 10 DNS-запитами

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

Що означає вивід: SPF використовує кілька include; кожен include може викликати додаткові DNS-запити.

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

Завдання 4: Перевірте наявність DKIM-селектора для відомого відправника

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

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

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

Завдання 5: Надішліть тест і перевірте заголовок Authentication-Results (з файлу збереженого заголовка)

cr0x@server:~$ grep -i "^Authentication-Results:" -A2 message.eml
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=Qd9...
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com

Що означає вивід: DKIM і SPF обидва проходять. DKIM підписує як example.com.

Рішення: Цей потік має проходити DMARC за умови, що Header From — example.com і налаштування вирівнювання дозволяють це.

Завдання 6: Перевірте результат DMARC у заголовках (отримувач вам скаже)

cr0x@server:~$ grep -i "^Authentication-Results:" -A5 message.eml | grep -i dmarc
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Що означає вивід: DMARC пройшов і політика була б quarantine для відмов; disposition NONE означає, що застосовувальної дії не було.

Рішення: Якщо DMARC тут не проходить, припиніть сперечатися про «правильність» SPF і виправте вирівнювання або підписування DKIM.

Завдання 7: Виявити поширену відмову: DKIM проходить, але не вирівнюється

cr0x@server:~$ grep -i "^Authentication-Results:" -A3 message.eml
Authentication-Results: mail.receiver.example;
       dkim=pass header.i=@vendor.example header.s=selector1 header.b=abc...
       spf=pass smtp.mailfrom=vendor-bounces.example

Що означає вивід: DKIM проходить для vendor.example, SPF проходить для vendor-bounces.example. Якщо Header From — example.com, ні один не вирівнюється.

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

Завдання 8: Перевірте наслідки розслабленого і жорсткого вирівнювання

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; adkim=s; aspf=r"

Що означає вивід: DKIM має точно співпадати; SPF може вирівнюватися через піддомен.

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

Завдання 9: Підтвердьте MX і хто фактично приймає вхідну пошту (ціль підробок — і вхідна пошта)

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

Що означає вивід: Це ваші вхідні приймачі; вони будуть застосовувати політики і давати заголовки/логи.

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

Завдання 10: Перевірте, чи піддомени випадково не залишилися незахищеними

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

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

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

Завдання 11: Перевірте зворотний DNS (не DMARC, але зіпсує вам день)

cr0x@server:~$ dig +short -x 203.0.113.10
mailout.example.com.

Що означає вивід: PTR існує для відправного IP, що допомагає репутації і прийняттю.

Рішення: Якщо PTR відсутній або вказує на щось сумнівне, виправте rDNS з вашим ISP/хмарним провайдером. DMARC не компенсує погану гігієну відправника.

Завдання 12: Перевірте, що ім’я HELO/EHLO резольвиться (знову ж таки, не DMARC, але важливо)

cr0x@server:~$ dig +short A mailout.example.com
203.0.113.10

Що означає вивід: Прямий DNS збігається з ім’ям, яке використовує вихідний сервер.

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

Завдання 13: Виявлення ризику permerror SPF, перелічивши include (ручна перевірка)

cr0x@server:~$ dig +short TXT _spf.google.com
"v=spf1 ip4:64.233.160.0/19 ip4:66.102.0.0/20 include:_netblocks.google.com ~all"

Що означає вивід: Include можуть вкладатися; ваш початковий SPF-запис може перевищити ліміт запитів залежно від того, у що ті include розгортаються.

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

Завдання 14: Перевірте, чи є DKIM-підпис у повідомленні

cr0x@server:~$ grep -i "^DKIM-Signature:" -m1 -n message.eml
42:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date:mime-version; bh=...; b=...

Що означає вивід: Повідомлення підписане з d=example.com. Це ідентичність, яку DMARC може вирівняти.

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

Завдання 15: Переконайтеся, що ваша скринька для звітів DMARC існує і приймає листи

cr0x@server:~$ host -t MX example.com
example.com mail is handled by 10 mx1.mailhost.example.
example.com mail is handled by 20 mx2.mailhost.example.

Що означає вивід: Ваш домен має робочі MX. Це не доводить існування скриньки, але підтверджує маршрутизацію вхідної пошти.

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

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

Покрокове впровадження, що зупиняє підробки без втрат пошти

1. Інвентар легітимних відправників.
   Використайте наявні знання (IT, маркетинг, білінг, підтримка) і підтвердіть через агреговані дані DMARC, коли вони стануть доступні.
   Мета: список систем, що відправляють «From: @yourdomain».
2. Виберіть доменну стратегію.
   Вирішіть, чи будете ви:
   • Відправляти все з кореневого домену (складніше), або
   • Використовувати функціональні піддомени для сторонніх (рекомендовано): billing.example.com, news.example.com, support.example.com.

   Це зменшує радіус ураження і робить вирівнювання підконтрольнішим.

3. Налаштуйте DKIM для кожного відправника.
   Надавайте пріоритет DKIM перед SPF для довгострокової надійності. Вимагайте вирівняних d= доменів.
4. Опублікуйте SPF, який є коректним, а не хитрим.
   Тримайте його мінімальним. Уникайте ланцюжків з 9 include і молитви. Використовуйте піддомени, щоб розділяти обов’язки за потреби.
5. Опублікуйте DMARC з p=none лише стільки, щоб зібрати базу.
   Зазвичай 1–2 тижні достатньо при нормальному трафіку.
6. Перейдіть на p=quarantine, pct=100.
   Саме тут підробки стають значно важчими, і у вас ще є поступка для доставляння.
7. Виправляйте відмови вирівнювання.
   Використовуйте звіти та заголовки, щоб ідентифікувати, які відправники падають і чому. Домагайтеся від постачальників кастомного DKIM і вирівняних доменів відскоку.
8. Заблокуйте піддомени.
   Встановіть sp=quarantine або sp=reject. Публікуйте явні DMARC-записи для піддоменів з високим ризиком, якщо потрібно.
9. Перейдіть на p=reject.
   Тільки коли:
   • Ваші високонавантажені легітимні потоки стабільно проходять DMARC.
   • Ви розумієте залишкові відмови і свідомо їх прийняли (або перемістили на піддомени з окремою політикою).
10. Підтримуйте «нудний» цикл.
    Щомісячний перегляд звітів, власності та змін постачальників. Поштова екосистема змінюється. Налаштування постачальників теж.

Операційний чек-лист перед зміною політики DMARC

• Чи є у нас план відкату (DNS TTL, збережений рядок попереднього запису, вікно змін)?
• Чи знаємо ми поточний відсоток проходження по кожному потоку відправлення?
• Чи підписують високоризикові сторонні (маркетинг, CRM, тікетинг) повідомлення DKIM з вирівняним d=?
• Чи SPF знаходиться в межах лімітів запитів і без permerror?
• Чи встановлена політика для піддоменів (sp=)?
• Чи є у нас моніторована скринька для RUA/RUF і спосіб обробляти XML-вкладення?
• Чи готові ми до крайових випадків форвардингу (розсилки, переадресації виписок клієнтів)?

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

1) Симптом: «DMARC fail», але SPF і DKIM десь кажуть «pass»

Корінна причина: Один проходить для іншого домену. Немає вирівнювання з Header From.

Виправлення: Переконайтеся, що DKIM підписує з d=, вирівняним з доменом From (надавайте перевагу точному вирівнюванню, якщо встановлено adkim=s). Використовуйте кастомний домен відскоку для вирівнювання SPF, де можливо.

2) Симптом: Маркетингові листи раптом йдуть у спам після переходу на p=quarantine

Корінна причина: Постачальник підписує своїм доменом або використовує невирівняний Return-Path; DMARC тепер провалюється і отримувачі карантинять.

Виправлення: Налаштуйте у постачальника кастомний DKIM для вашого домену або відправляйте з виділеного піддомену з власною політикою та автентифікацією.

3) Симптом: Деякі транзакційні повідомлення проходять, інші падають із того самого «системи»

Корінна причина: Багато вихідних шляхів: одні підписані, інші ні; або частина йде через реле, що змінює вміст і ламає DKIM.

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

4) Симптом: DMARC-звіти показують купу невідомих IP, що відправляють від вашого домену

Корінна причина: Спроби підробки поширені, і p=none дозволяє їм «виглядати» правдоподібно для деяких отримувачів. Також може бути невидимий shadow IT, що відправляє.

Виправлення: Перейдіть до quarantine; розслідуйте джерела з високим обсягом. Для легітимних невідомих — призначте власника і налаштуйте вирівняний DKIM/SPF.

5) Симптом: Отримувачі повідомляють SPF «permerror» або «temperror»

Корінна причина: Перевищено ліміт SPF-запитів, зіпсований SPF-запис або таймаути DNS.

Виправлення: Зменшіть include, відповідально «сплюсніть» SPF (не порушивши володіння), або сегментуйте за піддоменами. Поліпшіть надійність DNS.

6) Симптом: Переслані повідомлення (клієнти автоматично форвардять рахунки) падають DMARC і потрапляють у карантин

Корінна причина: SPF падає при форвардингу (інший IP), а DKIM може ламатися, якщо форвардер переписує контент або заголовки.

Виправлення: Надавайте пріоритет надійності DKIM (підписуйте фінальну форму, уникайте переписування вмісту). Розгляньте підтримку ARC, якщо ви керуєте форвардерами; для зовнішніх форвардів прийміть деякі втрати і пом’якшіть їх альтернативною доставкою (портали, автентифіковані акаунти клієнтів).

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

Корінна причина: Відсутній тег sp= і відсутні DMARC-записи на піддоменах.

Виправлення: Встановіть sp=quarantine або sp=reject у кореневому DMARC-записі і опублікуйте DMARC на піддоменах з високою цінністю.

8) Симптом: Ви поставили p=reject і тепер партнер каже, що ваші листи «зникають»

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

Виправлення: Тимчасово поверніться в quarantine, поки відремонтуєте, або перемістіть проблемний потік на піддомен з м’якшою політикою як проміжне рішення. Потім виправте вирівнювання правильно.

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

1) Чи «p=none» марний?

Він корисний для виявлення, але не зупиняє підробки. Ставте його як логування без алертів: годиться коротко, безвідповідально назавжди.
Перейдіть до quarantine, як тільки зберете базу і призначите власників.

2) Чому не починати одразу з p=reject, якщо підробки серйозні?

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

3) На кого орієнтуватися: SPF чи DKIM для проходження DMARC?

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

4) Що означає «вирівнювання» практично для постачальників?

Це означає, що постачальник має підписувати від вашого домену в DKIM (custom DKIM) і бажано використовувати домен відскоку/Return-Path у межах вашого домену
(custom return-path). Без цього DMARC провалюється, коли From — ваш домен.

5) Які налаштування adkim і aspf слід вибрати?

Солідний дефолт — adkim=s і aspf=r під час rollout. Це штовхає постачальників робити DKIM правильно, не надто караючи різницю в SPF-шляху.
Якщо ваше середовище підписує з піддоменів умисно, відкоригуйте adkim або змініть стратегію From-домену.

6) Чи потрібні мені RUF (форензичні) звіти?

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

7) Що з розсилками, що змінюють тему або додають підписи?

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

8) Як піддомени допомагають доставлянню і безпеці?

Вони ізолюють репутацію і політику. Помістіть маркетинг на news.example.com, транзакції на billing.example.com, і тримайте людські листи на кореневому домені.
Потім тонко налаштовуйте DMARC для піддоменів за потреби, захищаючи бренд загалом.

9) Якщо DMARC проходить, чому листи все одно йдуть у спам?

Бо автентифікація не є репутацією. Перевірте репутацію IP, рівень скарг, залученість, вміст і консистентність. Проходження DMARC необхідне; воно не достатнє.

10) Скільки часу тривають зміни DMARC, щоб набрати ефект?

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

Висновок: наступні кроки, які можна реалізувати цього тижня

«Одна політика DMARC», що реально працює в продакшені, — це не магічний рядок; це позиція: застосовуйте quarantine на 100%, змушуйте жорстке DKIM-вирівнювання,
тримайте SPF достатньо розслабленим, щоб уникнути самонанесених ран, і використовуйте звітність, щоб відловити кожного відправника, який прикидається вами.

Зробіть це наступним кроком

1. Опублікуйте або перевірте DMARC на кореневому домені з p=quarantine; pct=100; adkim=s; aspf=r; sp=quarantine.
2. Виконайте практичні завдання вище для трьох основних вихідних потоків і підтвердіть проходження DMARC і вирівнювання у реальних заголовках.
3. Виберіть стратегію піддоменів для сторонніх і почніть переміщувати найпроблемніших постачальників туди, якщо вони не можуть швидко зробити вирівняний DKIM.
4. Встановіть нагадування в календарі: щомісячний перегляд звітів DMARC з призначеними власниками. Це запобігає регресії.
5. Коли ваші легітимні потоки стабільно проходять, перемкніться на p=reject із впевненістю, а не з оптимізмом.

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