Коротко
DMARC не питає «чи пройшов лист перевірку». Він питає «чи пройшов лист перевірку за тим доменом, який бачить одержувач». Різниця між цими двома питаннями і є узгодженням — і саме на ній спотикається більшість налаштувань, які на перший погляд виглядають завершеними.
Чому самої перевірки замало
У листі є два різні «відправники»:
- Технічний — адреса у зворотному шляху (
Return-Path), яку бачить поштовий сервер і за якою перевіряється SPF. - Видимий — адреса в полі
From:, яку бачить людина у поштовому клієнті.
Одержувач читає друге, а SPF перевіряє перше. Якщо не вимагати, щоб вони стосувалися одного домену, зловмиснику достатньо налаштувати власний домен із бездоганним SPF і поставити у From: ваш. Формально перевірка пройдена — фактично це підробка.
Узгодження закриває саме цей розрив.
Як це працює
DMARC вважає лист успішним, якщо виконується хоча б одна з умов:
- SPF пройшов і домен зворотного шляху узгоджується з доменом у
From:, або - DKIM пройшов і домен підпису (
d=) узгоджується з доменом уFrom:.
Достатньо одного механізму. Обидва — краще, але не обов'язково.
Relaxed і strict
Режим узгодження задається в записі DMARC двома тегами: aspf для SPF і adkim для DKIM.
| Режим | Тег | Що вважається збігом |
|---|---|---|
| Relaxed (за замовчуванням) | aspf=r, adkim=r |
Достатньо організаційного домену: mail.example.com узгоджується з example.com |
| Strict | aspf=s, adkim=s |
Потрібен точний збіг домену |
Relaxed підходить майже всім і саме тому стоїть за замовчуванням: піддомени для розсилок — нормальна практика. Strict має сенс, коли ви свідомо контролюєте кожен піддомен і хочете, щоб жоден інший не міг виступати від вашого імені.
Типовий випадок: розсилка через сторонню платформу
Ви налаштували розсилку, платформа рапортує «SPF та DKIM налаштовано», а DMARC усе одно провалюється. Майже завжди причина одна:
- у
From:стоїтьnews@yourbrand.com; - SPF перевіряється за доменом платформи, наприклад
bounces.vendor.net; - DKIM підписано доменом
d=vendor.net.
Обидві перевірки пройдено — і жодна не узгоджена з yourbrand.com. Рішення теж одне: налаштувати на боці платформи власний піддомен для відправки й власний ключ DKIM, щоб d= став вашим доменом.
Як прочитати це у звітах
У зведених звітах DMARC різниця видно безпосередньо. Блок auth_results показує «сирий» результат перевірки, policy_evaluated — узгоджений, той, за яким і ухвалюється рішення:
<policy_evaluated>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
<auth_results>
<spf><domain>bounces.vendor.net</domain><result>pass</result></spf>
</auth_results>
SPF pass у сирому результаті, домен — чужий. Це і є неузгодженість у чистому вигляді. Як читати такі звіти повністю, розібрано у статті «Як читати зведені звіти DMARC».
Що з цим робити
- Перелічіть усі системи, які надсилають пошту від вашого імені: CRM, білінг, служба підтримки, маркетингові розсилки.
- Для кожної перевірте, який домен стоїть у
d=підпису DKIM і в зворотному шляху. - Там, де це чужий домен, налаштуйте власний піддомен і власний ключ DKIM.
- Переконайтеся за звітами, що узгодження з'явилося, і лише потім посилюйте політику.
Поточний стан записів свого домену можна подивитися безкоштовною перевіркою.