DMARC — quarantine проти reject: коли переходити і як впровадити безпечно

Ваш CEO щойно переслав лист, що «виглядає як від фінансів», і питає, чи легітимний переказ.
Заголовки показують, що він не від вас. Користувачі цього не помічають. І ваш домен скоро стане улюбленим маскарадом для зловмисників.

DMARC — це доросле рішення. Але перемикання з p=none на p=reject — це не просто смілива галочка: це продакшн-зміна, яка може непомітно зламати реальну пошту.
Ось як зробити це по-SRE: вимірювано, відкатно і нудно в найкращий спосіб.

DMARC у продакшні: ментальна модель, що уникає самоіндукованих відмов

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

Вирівнювання — це те, що люди напівпам’ятають і потім шкодують.
DMARC не має значення, що SPF пройшов для bounce.vendor-mail.example, якщо повідомлення заявляє про yourbrand.com.
Так само не має значення, що DKIM пройшов для mailer.thirdparty.com, якщо видимий From — yourbrand.com і підпис не зроблено від вашого домену (або від правильно вирівняного).

Ось найчистіша робоча модель:

• Особистість у заголовку From — це те, що бачать користувачі і що захищає DMARC.
• SPF автентифікує SMTP envelope sender (Return-Path / MAIL FROM), а не заголовок From.
• DKIM автентифікує домен підпису (d=), а не заголовок From.
• DMARC вимагає, щоб щонайменше SPF або DKIM пройшли і були вирівняні з доменом From.
• Політика: p=none спостерігає, p=quarantine підштовхує, p=reject зачиняє двері.

Операційна правда: DMARC не складний, він широкий. Ваш домен, ймовірно, надсилає пошту з місць, які ви не згадаєте:
системи тикетингу, HR-інструменти, CRM, маркетингові платформи, сторінки статусу, автоматизації підрядників, принтери, сканери та та одна аплікація, яку команда написала в 2018 і що досі «тимчасово» працює.

Хороше впровадження DMARC — це фактично виявлення активів вихідної пошти, зі змінами DNS у кінці.

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

• SPF з’явився майже за десять років до DMARC. SPF почався на початку 2000-х як відповідь на масове підроблення, але він ніколи не автентифікував те, що бачить користувач у From.
• DKIM виник внаслідок злиття двох підходів. DomainKeys (Yahoo) та Identified Internet Mail (Cisco) злилися в DKIM, тому частина термінології досі відчувається як написана комітетом.
• DMARC з’явився з ідеї «нам набридло фішити власних користувачів». Великі провайдери поштових скриньок і великі відправники просували його, щоб зупинити підроблення домену відправника, а не щоб вирішити всі проблеми зі спамом.
• Ключова функція DMARC — звітування. Агреґатні звіти (RUA) перетворюють приймачів на джерела телеметрії. Це рідкість у світі пошти, де зазвичай панують відчуття й звинувачення.
• Пересилка пошти старша за більшість вашого SaaS-стеку. Початкова екосистема пошти припускала пересилання та перемаркування як норму. Примусова політика DMARC може конфліктувати з цією історією.
• ARC існує тому, що «пересилка ламає SPF/DKIM» не вщухала. Authenticated Received Chain — це пластир, щоб зберегти результати автентифікації через проміжні ланки.
• Великі приймачі поступово загострювали поведінку. Дотримання DMARC не стало масовим відразу; провайдери поетапно вводили примус та UI-сигнали роками, тому поради 2016 року часто не спрацьовують сьогодні.
• DMARC не лише для reject. Багато організацій з великим трафіком живуть на p=quarantine з поступовим збільшенням pct, бо деякі екосистеми пошти ніколи не стають повністю детерміністичними.

Quarantine vs reject: що реально змінюється на каналі

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

Що зазвичай означає quarantine

Quarantine — це інструкція «помітити як підозріле». Найчастіше: папка спаму, класифікація як junk або додаткові фільтри.
Деякі приймачі все ще доставлятимуть у вхідні залежно від власної моделі.

Операційно quarantine — це тестова смуга:

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

Що зазвичай означає reject

Reject — це відмова приймача прийняти доставку під час SMTP (ідеально) або відкидання пізніше (менш ідеально).
Якщо ваша легітимна пошта не проходить DMARC під політикою reject, часто отримаєте:

• Жорсткі bounce-и для транзакційних листів.
• Тиху недоставку в залежності від поведінки приймача (рідко, але трапляється).
• Тренування у надзвичайному режимі: «листи не приходять» — це бізнес-аутедж, не IT-квиток.

Reject — це ціль для доменів з високою довірою (керівництво, зарплати, фінанси, юридичні) і для брендів, які часто підробляють.
Це також обіцянка: ви кажете приймачам, що ваша позиція автентифікації достатньо зріла, і повідомлення, що не проходять, ймовірно ворожі.

Одне суб’єктивне правило: не переходьте на reject, поки не зможете відповісти з доказами на питання «Які системи надсилають пошту від нашого домену і чи вони вирівняні?»
Якщо ваша відповідь «переважно Microsoft 365», ви не готові. «Переважно» — це як трапляються відмови.

Жарт №1: DMARC — як поставити замок на вхідні двері — гарна ідея — поки не згадаєте, що ваш сусід по кімнаті все ще користується вікном.

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

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

1) Ви володієте DNS і можете змінювати його надійно

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

2) SPF не ідеальний, але адекватний

SPF має покривати ваших легітимних відправників і уникати перевищення ліміту 10 DNS-запитів. Також: поступово мінімізуйте невизначеність ~all.
SPF-прохід недостатній для DMARC, але хаос у SPF робить аналіз DMARC нестерпним.

3) DKIM-підписування присутнє для основних платформ

DKIM — ваш найкращий друг, коли пошту пересилають або ретранслюють.
Якщо ви можете підписувати з d=yourbrand.com (або вирівняного піддомену), зробіть це.

4) У вас є поштовий ящик для звітів і хтось їх читає

Агреґатні DMARC-звіти — це XML. Вони не «дружні для людини», але операційно — золото.
Вам потрібен ящик для їх отримання, парсер/робочий процес (комерційний або внутрішній) і очікування «приблизно на черговість»: хтось перевіряє при зміні політики.

5) Ви розумієте свою толерантність до ризику

Толерантність банку — не та сама, що у креативного агентства. Визначте:

• Які домени мають швидко перейти на reject (для керівництва, платежів)?
• Які домени можуть довше залишатися в quarantine (маркетинг, багато третіх сторін)?
• Чи потрібні вам політики для піддоменів (sp=)?

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

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

Завдання 1: Перевірити поточний DMARC-запис

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

Значення: Поточна політика — лише моніторинг (p=none). Розслаблене вирівнювання для SPF і DKIM. Звітування налаштоване.

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

Завдання 2: Перевірити синтаксис DMARC-запису в DNS

cr0x@server:~$ python3 - <<'PY'
import re, subprocess, shlex
domain="_dmarc.yourbrand.com"
out=subprocess.check_output(["dig","+short","TXT",domain],text=True).strip()
print(out)
if "v=DMARC1" not in out:
    raise SystemExit("Missing v=DMARC1")
if " p=" not in out and ";p=" not in out:
    raise SystemExit("Missing p=")
print("Looks like DMARC-ish TXT is present.")
PY
"v=DMARC1; p=none; rua=mailto:dmarc-rua@yourbrand.com; ruf=mailto:dmarc-ruf@yourbrand.com; fo=1; adkim=r; aspf=r; pct=100"
Looks like DMARC-ish TXT is present.

Значення: Принаймні DMARC-подібний запис повертається послідовно.

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

Завдання 3: Перевірити поточний SPF-запис

cr0x@server:~$ dig +short TXT yourbrand.com | sed -n 's/^"//; s/"$//; /v=spf1/p'
v=spf1 include:spf.protection.outlook.com include:mailgun.org ip4:203.0.113.10 ~all

Значення: SPF існує і перелічує кілька провайдерів плюс IP, закінчується softfail.

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

Завдання 4: Порахуйте DNS-запити SPF (уникати 10-пунктового обриву)

cr0x@server:~$ python3 - <<'PY'
import dns.resolver, re
domain="yourbrand.com"
visited=set()
def get_spf(d):
    txt=[]
    for r in dns.resolver.resolve(d,"TXT"):
        s="".join([b.decode() for b in r.strings])
        if s.startswith("v=spf1"):
            txt.append(s)
    return txt[0] if txt else None

lookups=0
def walk(d):
    global lookups
    if d in visited: return
    visited.add(d)
    spf=get_spf(d)
    if not spf: return
    for token in spf.split():
        if token.startswith("include:"):
            lookups += 1
            walk(token.split(":",1)[1])
        if token.startswith("redirect="):
            lookups += 1
            walk(token.split("=",1)[1])

walk(domain)
print("Estimated include/redirect lookups:", lookups)
print("Visited domains:", len(visited))
PY
Estimated include/redirect lookups: 2
Visited domains: 3

Значення: Ви нижче звичного ліміту 10 DNS-запитів для SPF (цей скрипт лише наближає; реальна оцінка враховує інші механізми).

Рішення: Якщо ви близько/понад 10, спростіть SPF перед посиленням DMARC. Інакше ви «виправите» підроблення, зламавши пошту.

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

cr0x@server:~$ dig +short TXT selector1._domainkey.yourbrand.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...snip..."

Значення: Публічний ключ DKIM існує для selector1. Це необхідно, щоб прийачі могли перевірити DKIM-підписи від цього селектора.

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

Завдання 6: Перевірити вирівнювання DMARC на прикладі повідомлення (з заголовків)

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;
       dkim=pass header.i=@yourbrand.com header.s=selector1 header.b=abc123;
       spf=pass (google.com: domain of bounce@mg.yourbrand.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@mg.yourbrand.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourbrand.com

Значення: DMARC проходить, бо принаймні SPF або DKIM проходять і вирівняні з header.from=yourbrand.com. Тут DKIM-вирівнювання ідеальне.

Рішення: Якщо DMARC не проходить, але SPF проходить, ймовірно, SPF пройшов для іншого домену (невирівнювання). Виправляйте вирівнювання, а не «ще більше SPF».

Завдання 7: Знайти основні невдалені джерела в RUA XML (швидко і брудно)

cr0x@server:~$ ls -1 dmarc-rua/ | head
google.com!yourbrand.com!1735516800!1735603200.xml
outlook.com!yourbrand.com!1735516800!1735603200.xml

cr0x@server:~$ grep -RhoE '<source_ip>[^<]+' dmarc-rua/*.xml | sed 's/<source_ip>//' | sort | uniq -c | sort -nr | head
  482 203.0.113.10
  117 198.51.100.25
   41 192.0.2.77

Значення: У вас є кілька великих IP-джерел, що генерують трафік, помічений DMARC.

Рішення: Ідентифікуйте кожен IP (ваш MTA, ваш постачальник, невідома система). Невідомі високонавантажені IP блокують впровадження примусу.

Завдання 8: Зіставити підозрілий IP з провайдером (реверс + підказка ASN)

cr0x@server:~$ whois 198.51.100.25 | egrep -i 'OrgName|org-name|descr|netname|origin|aut-num' | head
NetName:        EXAMPLE-NET
OrgName:        Example Email Services
OriginAS:       AS64500

Значення: Цей IP, ймовірно, належить постачальнику або принаймні ідентифікованій мережі.

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

Завдання 9: Перевірити, чи піддомени мають власні DMARC-записи

cr0x@server:~$ for d in marketing.yourbrand.com status.yourbrand.com hr.yourbrand.com; do
  echo "== $d =="
  dig +short TXT _dmarc.$d
done
== marketing.yourbrand.com ==
"v=DMARC1; p=none; rua=mailto:dmarc-rua@yourbrand.com"
== status.yourbrand.com ==

== hr.yourbrand.com ==

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

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

Завдання 10: Симулювати зміну політики безпечно (використовуйте pct=10 з quarantine)

cr0x@server:~$ cat <<'EOF'
_dmarc.yourbrand.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"
EOF
_dmarc.yourbrand.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"

Значення: Це запис, який ви пропонуєте опублікувати: quarantine, але лише для 10% невдалих повідомлень.

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

Завдання 11: Перевірити розповсюдження DNS від кількох резолверів

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "== resolver $r =="
  dig +short @$r TXT _dmarc.yourbrand.com
done
== resolver 1.1.1.1 ==
"v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"
== resolver 8.8.8.8 ==
"v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"
== resolver 9.9.9.9 ==
"v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"

Значення: Зміна видима з основних публічних резолверів.

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

Завдання 12: Слідкувати за логами пошти на наявність bounce-ів, пов’язаних із DMARC (приклад Postfix)

cr0x@server:~$ sudo grep -E 'dmarc|policy|reject|quarantine' /var/log/mail.log | tail -n 20
Jan 04 10:21:16 mx1 postfix/smtp[18233]: host gmail-smtp-in.l.google.com[142.250.102.27] said: 550-5.7.26 Unauthenticated email from yourbrand.com is not accepted due to domain's DMARC policy. (in reply to end of DATA command)

Значення: Приймач відхилив повідомлення явно через вашу політику DMARC. Це або блокування підробки (добре), або легітимний відправник, що не проходить вирівнювання (погано).

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

Завдання 13: Підтвердити, що третя сторона підписує вирівняним DKIM

cr0x@server:~$ grep -Eo 'dkim=[a-z]+|header.i=@[^;]+|header.s=[^;]+' sample-vendor.eml
dkim=pass
header.i=@vendor-mail.example
header.s=s1

Значення: DKIM пройшов, але підписано як vendor-mail.example, а не вашим доменом. Це не вирівняється з From yourbrand.com.

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

Завдання 14: Виявити невідповідність «From domain» vs «envelope from» у вихідному повідомленні

cr0x@server:~$ egrep -i '^(From:|Return-Path:)' sample.eml
Return-Path: <bounce@mg.yourbrand.com>
From: Billing <billing@yourbrand.com>

Значення: Envelope — mg.yourbrand.com, видимий From — yourbrand.com. Вирівнювання SPF залежить від того, чи вважає relaxed, що mg.yourbrand.com вирівняний (при relaxed — так, бо це піддомен). При strict вирівнювання не пройде.

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

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

cr0x@server:~$ dig +short TXT _dmarc.yourbrand.com | tr -d '"' | tr ';' '\n' | sed 's/^ *//'
v=DMARC1
p=quarantine
pct=10
adkim=r
aspf=r
rua=mailto:dmarc-rua@yourbrand.com

Значення: Тегу sp= немає. Піддомени успадковують p= за замовчуванням, якщо не публікують власного DMARC-запису.

Рішення: Якщо у вас багато «диких» піддоменів, розгляньте встановлення sp=none, поки батьківський переходить на quarantine/reject. Або зробіть навпаки, якщо піддомени зловживаються.

Завдання 16: Швидкий smoke-test виходу з кожної відомої системи (мінімально, але дієво)

cr0x@server:~$ swaks --to dmarc-test@externalmailbox.example --from noreply@yourbrand.com --server smtp.office365.com --auth-user noreply@yourbrand.com --auth-password 'REDACTED' --data "Subject: DMARC smoke test

hello"
=== Trying smtp.office365.com:587...
=== Connected to smtp.office365.com.
<** 220 ...
>** EHLO ...
<** 250-...
>** MAIL FROM:<noreply@yourbrand.com>
<** 250 2.1.0 Sender OK
>** RCPT TO:<dmarc-test@externalmailbox.example>
<** 250 2.1.5 Recipient OK
>** DATA
<** 354 Start mail input; end with <CRLF>.<CRLF>
>** .
<** 250 2.0.0 OK

Значення: Повідомлення прийнято вашим вихідним сервером. Реальна перевірка відбувається у приймача, коли ви аналізуєте Authentication-Results.

Рішення: Зробіть це для кожної платформи (O365, Gmail, маркетинговий вендор, система тикетингу). Якщо якась не може створити вирівняну пошту — виправте її перед reject.

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

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

Перш за все: визначте, це reject, quarantine чи щось інше

• Попросіть bounce. Якщо є bounce-повідомлення, прочитайте його. Якщо воно згадує DMARC або «unauthenticated», ви в правильній зоні.
• Перевірте SMTP-відповідь приймача в логах. Логи вашого MTA зазвичай містять точний код статусу і текст.
• Перевірте, чи користувач просто не бачить його (quarantine). Якщо політика quarantine, лист може потрапляти в папку спаму.

По-друге: визначте, який саме відправник надсилає повідомлення

• Витягніть повідомлення з системи відправлення, якщо можливо (черга, архів відправлених, логи аплікації).
• Витягніть Return-Path, From та DKIM d=.
• Перевірте з RUA-звітами, щоб знайти обсяг і частку відмов для того IP-джерела.

По-третє: вирішіть, виправляти вирівнювання SPF, DKIM чи змінювати From

• Якщо DKIM присутній і не проходить: підпис зламався (зміна контенту, поганий ключ, неправильний селектор) або вендор неправильно налаштований.
• Якщо DKIM проходить, але не вирівнюється: вендор підписує своїм доменом; потрібен custom DKIM або стратегія з піддоменом.
• Якщо SPF проходить, але DMARC не проходить: envelope-from домен не вирівнюється з From, або пересилка зламала SPF, і ви залежали від SPF.

По-четверте: контролюйте зону впливу, доки виправляєте

• Тимчасово знижуйте pct, якщо потрібно (особливо під час quarantine-рампу).
• У надзвичайних випадках поверніться з reject на quarantine, поки ремонтуєте — але розглядайте це як відкат, а не стиль життя.
• Комунікуйте чітко: який відправник, які потоки і очікуваний час відновлення.

Чеклісти / покроковий план: від none → quarantine → reject

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

Фаза 0: Моніторинг, який реально моніторить (1–4 тижні)

• Опублікуйте DMARC з p=none, rua і (опціонально) ruf, якщо можете обробляти чутливі форензічні дані. Багато організацій пропускають ruf.
• Переконайтеся, що SPF існує і DKIM увімкнено для основних платформ.
• Налаштуйте робочий процес для агреґатних звітів:
  • Щоденний перегляд у перший тиждень.
  • Щотижневий перегляд далі, поки не стане стабільно.
• Створіть інвентар:
  • Усі легітимні відправники.
  • Які домени вони використовують у From і envelope-from.
  • Яким доменом вони підписують DKIM.
  • Хто відповідає за конфігурацію.

Ворота для переходу далі

• Ви можете віднести 90–95% трафіку, поміченого DMARC, до відомих систем.
• Для відомих систем у вас є явний план виправлення будь-якого невдалого вирівнювання.
• У вас є принаймні одна зовнішня скринька для перевірки заголовків.

Фаза 1: Quarantine з низьким відсотком (1–3 тижні)

• Встановіть p=quarantine; pct=10 (або 5, якщо ви обережні).
• Тримайте вирівнювання розслабленим (aspf=r; adkim=r), якщо немає причин для strict.
• Моніторинг:
  • Рівні відмов у RUA по джерелах.
  • Квитки до служби підтримки про відсутню пошту або зміни в папках спаму.
  • Логи outbound bounce.

Ворота для підвищення pct

• Немає невідомих високонавантажених джерел, що не проходять DMARC.
• Всі критичні бізнес-відправники (транзакційні, білінг, автентифікація, HR) надійно проходять DMARC.
• Вплив на користувачів керований і зрозумілий (false positive quarantine відслідковуються до відправника і виправляються).

Фаза 2: Quarantine 25 → 50 → 100 (2–6 тижнів)

• Піднімайте до 25%, потім 50%, потім 100% з кількома днями між кроками.
• Кожен крок має містити:
  • Тікет зміни з інструкцією для відкату.
  • Названого власника, що спостерігає RUA і логи пошти.
  • Список «watchlist» відправників (вендори, легасі аплікації).

Фаза 3: Reject з поступовим pct (1–4 тижні)

• Перейдіть на p=reject; pct=10, потім нарощуйте як вище.
• Тримайте quarantine як крок відкату (швидший, ніж повертатися до none).
• Коли стабільно на reject, розгляньте:
  • Строге вирівнювання для SPF/DKIM, якщо екосистема підтримує.
  • Закріплення поведінки піддоменів з sp=.

Чого не варто робити

• Не стрибайте з none прямо на reject тільки тому, що «ми увімкнули DKIM у Microsoft 365». У вас більше відправників, ніж ви думаєте.
• Не використовуйте DMARC, щоб замаскувати «ми не знаємо, хто надсилає пошту». DMARC змусить вас знати. Саме в цьому суть.
• Не встановлюйте strict вирівнювання рано, якщо ви не впевнені щодо envelope-from доменів і DKIM вендорів.

Три корпоративні міні-історії (анонімізовано, болісно правдоподібні)

Міні-історія 1: Інцидент, спричинений хибним припущенням

Середній fintech вирішив, що настав час для p=reject. Вони були на p=none місяцями, бачили багато підробок і відчували тиск аудиту безпеки.
Команда з пошти припустила просто: «Уся пошта йде з Microsoft 365, плюс маркетингова платформа, яку ми вже підписали DKIM».

У понеділок вранці вони перемкнули на reject 100%. За годину onboarding-листи клієнтам перестали доходити до декількох великих провайдерів.
Продажі назвали це «проблемою доставки». Підтримка — «система пошти впала». Інженери — «ми нічого не міняли».

Корінь був у третій системі: провайдері ідентифікації, що надсилав «magic link» для входу. Він використовував From: noreply@yourbrand.com, але підписував DKIM доменом вендора.
SPF теж проходив — для домену вендора. При p=none приймачі доставляли. При reject DMARC не пройшов вирівнювання і отримав відмову.

Виправлення не було героїчним. Вони ввімкнули custom DKIM в постачальника для yourbrand.com і підправили envelope-from на вирівняний піддомен.
Складнощі були організаційні: команда ідентифікації володіла тим вендором, а команда пошти не була залучена до імплементації.

Урок на майбутнє: найбільші DMARC-ризики — не ті системи, які ви знаєте. Це ті, що купили по картці та з дедлайном.

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

Глобальний ритейлер мав складний SPF: багато include, регіональні відправники і кілька легасі IP.
Хтось спробував «оптимізувати», перебираючи SPF у довгий перелік IP, щоб уникнути ліміту DNS-запитів і зменшити затримку у приймачів.

Це працювало деякий час. Потім вендор почав ротацію вихідних IP. Оскільки процес флаттенінгу був ручним і погано документований, SPF-запис відстав від реальності.
Деякі приймачі почали фейлити SPF; DMARC іноді проходив завдяки DKIM, але не завжди — бо кілька систем не завжди DKIM-підписувалися.

Коли команда перейшла на p=quarantine, ті маргінальні випадки почали йти в спам. Найдратівніша частина: це було нестабільно, залежно від того, яким IP вендор надсилав у ту годину.

Вони тимчасово відкотилися до p=none. Потім зробили нудну роботу:
стандартизували DKIM для транзакційних відправників, автоматизували оновлення SPF і перестали покладатися виключно на SPF як єдиний вирівнювальний метод.

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

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

B2B софтверна компанія проводила повільний DMARC-rollout. Безпека хотіла reject. Маркетинг нервував. Фінанси були голосніші за обох.
Власник пошти наполягав на календарі змін і малих pct-рампах з планом відкату і явним списком відправників під наглядом.

Під час підвищення quarantine з 25% до 50% агреґатні звіти показали новий IP-джерело з низьким обсягом, але високим відсотком відмов.
Це не була підробка. Це був новий інструмент customer success, що надсилав «звіти про зустрічі» як from=yourbrand.com від імені співробітників.

Оскільки rollout мав ворота, нічого катастрофічного не сталося. Команда зупинилася на 50% і не йшла далі.
Вони перевели той інструмент на виділений піддомен, ввімкнули custom DKIM і перевірили вирівнювання тестовими повідомленнями.

Через два тижні вони продовжили рамп, досягли reject, і ніхто поза командою пошти не помітив — мій улюблений тип успіху.

Цитата (парафраз): «Failure isn’t an option» — не просто лозунг, а дисципліна: готуйтесь, щоб не покладатися на удачу.

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

Це повторювані злочинці. Ви впізнаєте їх по шаблону скарг.

1) Симптом: «Тільки деяким отримувачам наші листи не доходять» після переходу на reject

Корінь: Змішані шляхи відправлення. Одна доріжка вирівнюється (DKIM або SPF), інша — ні (часто вендор чи регіональна система).

Виправлення: Використовуйте RUA-звіти, щоб сегментувати по IP і знайти систему, що фейлить. Увімкніть вирівняний DKIM для цього відправника або перемістіть From на вирівняний піддомен.

2) Симптом: Листи потрапляють у спам одразу після quarantine, але DMARC проходить у ваших тестах

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

Виправлення: Тестуйте кожен основний шлях відправки. Підтвердіть DMARC-прохід і вирівнювання в Authentication-Results. Якщо проходження стабільне, дивіться на репутацію/контент, а не на політику DMARC.

3) Симптом: DMARC не проходить, хоча SPF в заголовках каже «pass»

Корінь: SPF пройшов для іншого домену, ніж видимий From (невирівнювання). Звично з вендорами, що використовують свої bounce-домени.

Виправлення: Налаштуйте custom return-path / envelope-from під вашим доменом (вирівняний піддомен) або покладайтесь на вирівняний DKIM.

4) Симптом: DKIM іноді проходить, іноді ні для тієї самої системи

Корінь: Зміни повідомлення в дорозі (завантажувачі футерів, дисклеймери, переписування посилань), кілька підписантів DKIM з неконсистентною конфігурацією або несинхронна ротація ключів/селекторів.

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

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

Корінь: Strict вирівнювання вимагає точного збігу доменів. Envelope-from піддомен (наприклад, mg.yourbrand.com) більше не вирівнюється з yourbrand.com для SPF.

Виправлення: Тримайте розслаблене вирівнювання, якщо немає вагомих причин. Якщо переходите на strict, переконайтеся, що DKIM підписує точним From-доменом або змініть envelope-from відповідно.

6) Симптом: Частина пересланої пошти (особливо на персональні акаунти) починає фейлити після reject

Корінь: Форвардери можуть ламати SPF і іноді DKIM. DMARC тоді не проходить у кінцевого приймача.

Виправлення: Для важливої пошти надавайте перевагу DKIM-вирівнюванню і розгляньте ARC-aware потоки. Для розсилок — налаштуйте список так, щоб він поважав DMARC (може потребувати перезапису From).

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

Корінь: Адреса rua не приймається приймачами (деякі валідовуют), проблеми з ящиком, описка в DNS або у вас дуже мало трафіку через приймачів, що відправляють звіти.

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

8) Симптом: Ви опублікували DMARC, але нічого не змінилося

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

Виправлення: Перевірте, що існує один DMARC TXT-запис у _dmarc.yourbrand.com і протестуйте відоме невдале повідомлення (етично і акуратно).

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

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

1) Коли я повинен переходити з quarantine на reject?

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

2) Чи безпечно йти відразу з p=none на p=reject?

Лише якщо у вас дуже мала, строго контрольована поверхня відправлення і ви вже перевірили вирівнювання для кожного відправника.
Більшість організацій думають, що вони малі і контрольовані. Більшість помиляється. Використовуйте quarantine і pct-рампи, якщо ви не в кризі підроблення.

3) Що насправді робить pct?

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

4) Чи потрібні і SPF, і DKIM для DMARC?

Строго кажучи: ні, DMARC може пройти з одним з них. Операційно: так, варто мати обидва.
DKIM особливо важливий, бо SPF крихкий при пересиланні і ретрансляції.

5) Чи варто встановлювати aspf=s і adkim=s (strict)

Не на початку. Починайте з розслабленого. Strict для тих випадків, коли ви хочете зменшити краєві випадки зловживань і маєте сильний контроль над вендорами і піддоменами.
Strict також чудовий спосіб виявити приховані залежності о 2-й ночі.

6) Піддомени — чи успадковують вони політику батька?

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

7) Чому деякі вендори «підтримують DMARC», але все одно не проходять вирівнювання?

Багато вендорів мають на увазі «ми підтримуємо SPF і DKIM для нашого домену». Це недостатньо, якщо ви хочете надсилати як ваш домен.
Зазвичай потрібен custom DKIM (підпис від вашого домену) і іноді custom return-path під вашим доменом.

8) Чи зупинить DMARC усі фішингові атаки проти мого бренду?

Він зупиняє підроблення прямого домену (коли нападник використовує From: ceo@yourbrand.com, відправляючи з іншого місця) для приймачів, що застосовують DMARC.
Він не зупиняє схожі домени, підміни імені в полі From або скомпрометовані легітимні акаунти.

9) Який найбільший операційний ризик DMARC reject?

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

10) Якщо я зараз під активним підробленням, який найшвидший безпечний крок?

Перейдіть на p=quarantine; pct=100 швидко, якщо у вас є базове вирівнювання для основних платформ, а потім пришвидшіть ремедіацію і рамп до reject.
Якщо ви впевнено підтверджуєте DKIM-вирівнювання для ядра пошти, можете йти на reject швидше — але робіть це з відкритими очима і під наглядом.

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

Quarantine і reject у DMARC — це не філософські позиції. Це режими примусу.
Quarantine — спосіб вчитися, не знижуючи бізнес. Reject — спосіб втілити це навчання і зробити підроблення значно складнішим.

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

1. Перевірте поточні DMARC/SPF/DKIM записи в DNS і підтвердіть існування саме одного DMARC-запису.
2. Увімкніть RUA-звітування, якщо воно відсутнє, і почніть збирати агреґатні звіти щоденно.
3. Побудуйте інвентар відправників із RUA-джерел IP і заголовків Authentication-Results.
4. Виправте першого топового легітимного відправника (зазвичай це вендор з невирівняним DKIM).
5. Перейдіть на p=quarantine; pct=10 з планом відкату, потім підвищуйте обережно.
6. Перейдіть на p=reject, коли ваші критичні потоки стабільно проходять DMARC, а невідомі джерела ясно не ваші.

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