Тільки починаєте з DMARC? Почніть з основ →
У більшості організацій доменів більше, ніж тих, з яких реально йде пошта. Захисні реєстрації поруч із брендом, старі назви продуктів, домени для інших країн, домен, на якому живе лише сайт. Жоден із них не надсилає листів. Але будь-який може з'явитися в заголовку From фішингового листа.
Отримувач не знає, що домен не використовується, доки про це не скаже DNS. Домен без SPF, без DMARC і без MX не виглядає покинутим. Він виглядає неавтентифікованим, а неавтентифіковану пошту фільтрують за вмістом і репутацією, а не відхиляють за політикою.
Рекомендації M3AAWG щодо захисту припаркованих доменів і настанова уряду Великої Британії для доменів, які не надсилають пошту описують той самий набір записів. Нижче — кожен із них, як він працює і на чому зазвичай спотикаються.
Чотири записи
Для припаркованого example.net, який нічого не надсилає і не приймає:
example.net. TXT "v=spf1 -all"
_dmarc.example.net. TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"
example.net. MX 0 .
*._domainkey.example.net. TXT "v=DKIM1; p="
| Запис | Що він означає | Джерело |
|---|---|---|
v=spf1 -all |
Жодна IP-адреса не має права надсилати пошту від імені домену | RFC 7208, розділ 10.1.2 |
DMARC p=reject |
Відхиляти пошту, що не проходить DMARC, тобто всю | RFC 9989, розділ 4.7 |
MX 0 . |
Домен не приймає пошту | RFC 7505, розділ 3 |
| Порожній ключ DKIM | Усі селектори відкликано | RFC 6376, розділ 3.6.1 |
SPF: лише -all
RFC 7208 називає це усталеною найкращою практикою і наводить для домену, що не надсилає пошту, запис v=spf1 -all. Єдиний механізм у ньому — -all, тож будь-яка IP-адреса відправника отримує fail.
SPF не успадковується. v=spf1 -all на example.net нічого не каже про billing.example.net. Для піддоменів M3AAWG пропонує wildcard: *.example.net TXT "v=spf1 -all". Wildcard спрацьовує лише для імен, які не мають власних записів, тож піддомену із записом A потрібен окремий запис SPF.
DMARC: p=reject, а поруч із np= — sp=
Саме DMARC перетворює результат fail на відхилення. Без узгодженого SPF і без підпису DKIM кожен лист не проходить DMARC, а p=reject просить отримувачів його не приймати. На відміну від SPF, DMARC діє і на піддомени: якщо на _dmarc.billing.example.net запису немає, отримувач бере запис організаційного домену.
Яку політику він застосує далі, залежить від того, чи існує піддомен. За RFC 9989 для наявних піддоменів політику беруть із sp=, для неіснуючих — із np=. «Не існує» тут має вузьке значення: розділ 3.2.13 визначає це як запит, на який повертається NXDOMAIN.
Через це визначення одного np=reject замало:
- Wildcard створює імена. Щойно на
*.example.netз'являється запис TXT, будь-який вигаданий піддомен існує, і отримувачі застосовуютьsp=. - Деякі зони не повертають NXDOMAIN. Зони, підписані із застосуванням compact denial of existence (RFC 9824), на запит про неіснуюче ім'я повертають NOERROR без жодного запису. 20 жовтня 2026 року запит про вигадане ім'я в зоні
example.comдо публічного резолвера Cloudflare повернув NOERROR без жодного запису. Такий самий запит у зоніiana.orgповернув NXDOMAIN.
Тому публікуйте обидва теги. sp=reject закриває всі піддомени, які отримувач вважає наявними, а np=reject — ті, яких, на його думку, немає. І запис GOV.UK, і запис, опублікований для example.com, містять sp=reject.
adkim=s; aspf=s на припаркованому домені необов'язкові: там узагалі нічого не має проходити перевірку. GOV.UK їх додає.
Null MX: MX 0 .
Null MX — це єдиний запис MX із пріоритетом 0 і хостом .. RFC 7505 описує, що він дає обом сторонам:
- Сервер, який надсилає лист на
anyone@example.net, зупиняється на першій спробі й не ставить лист у чергу на повтор. Рекомендована відповідь —556 5.1.10. - Сервер, який отримує пошту від
example.net, може її відхилити, бо відповісти на такий лист неможливо. Рекомендована відповідь —550 5.7.27з текстомSender address has null MX.
Друге — це перевірка, яка ніяк не пов'язана з DMARC. Домен із null MX не повинен (MUST NOT) публікувати жодних інших записів MX. Якщо MX немає взагалі, відправники звертаються до запису A або AAAA (RFC 5321, розділ 5.1), тож на домені, де є лише сайт, спроби доставки йшли б на вебсервер. GOV.UK зазначає, що деякі DNS-хостинги не дають створити null MX. Якщо ваш серед них, решту записів однаково опублікуйте.
DKIM: порожній ключ для будь-якого селектора
За RFC 6376 порожній p= означає, що цей публічний ключ відкликано. Wildcard на *._domainkey дає таку відповідь для будь-якого селектора, який назве зловмисник. Підпис, що не пройшов перевірку, отримувач вважає відсутнім, тож до DMARC цей запис додає небагато. Проте M3AAWG і GOV.UK його радять, а це лише один рядок. GOV.UK також просить прибрати всі справжні селектори, які домен мав раніше, зокрема CNAME на провайдера.
Живий приклад: example.com
Домен example.com зарезервовано для документації в RFC 2606, і він нічого не надсилає. 20 жовтня 2026 року його публічні записи були такими:
example.com. TXT "v=spf1 -all"
example.com. MX 0 .
_dmarc.example.com. TXT "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"
<any>._domainkey.example.com TXT "v=DKIM1; p="
Тегу rua= у записі немає, тож звітів про пошту, яка підробляє цей домен, ніхто не отримує. Для власного домену такі звіти потрібні.
Куди надходять звіти
Припаркований домен із null MX не може приймати власні зведені звіти, тож rua= має вказувати на домен, який приймає пошту. Якщо ця адреса лежить поза доменом, про який звітують, RFC 9990, розділ 4 вимагає від отримувачів переконатися, що домен звітів згоден їх приймати. RFC 9989 прямо називає цей випадок: звіти про домени, які взагалі не можуть приймати пошту. Дозвіл публікує домен звітів:
example.net._report._dmarc.example.com. TXT "v=DMARC1;"
Сервіс звітності DMARC публікує цей запис на своєму боці. Якщо ж звіти йдуть у вашу скриньку на example.com, запис публікуєте ви — або wildcard *._report._dmarc.example.com для всього портфеля доменів.
Звіти тут і є головною метою. На припаркованому домені легітимного трафіку бути не повинно, тож кожне джерело у звітах — або підробка, або система, про яку забули. Про обидва випадки варто знати.
Багато доменів, один запис
Коли заради зміни однієї адреси звітів доводиться редагувати сорок записів DMARC, записи припаркованих доменів швидко застарівають. M3AAWG пропонує CNAME:
_dmarc.example.net. CNAME _dmarc.parked.example.com.
_dmarc.example.org. CNAME _dmarc.parked.example.com.
_dmarc.parked.example.com. TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com"
Кожен домен посилається на один запис, і зміна в ньому одразу діє для всіх. На тарифі Professional DDMARC розміщує запис DMARC у себе за тією самою схемою: один CNAME на домен.
Винятки
Домени, що лише приймають пошту. Домен, який пошту приймає, але ніколи не надсилає (наприклад, домен для вхідних псевдонімів), залишає справжні записи MX. Null MX тут публікувати не можна: через нього вхідні листи почнуть повертатися. А v=spf1 -all і p=reject публікуються так само.
Піддомени, з яких пошта таки йде. Якщо alerts.example.net надсилає листи, а решта домену — ні, створіть для нього власні записи SPF, DKIM і DMARC. GOV.UK у такому разі радить sp=none на батьківському домені. Окремий запис _dmarc.alerts.example.net дає змогу залишити на батьківському sp=reject.
Домени, які скоро почнуть використовувати. Щойно з припаркованого домену почнуть надсилати пошту, через ці записи жоден лист не пройде перевірку. Замініть їх до першого надсилання, а не після першого повідомлення про недоставку.
TTL у DNS. Зміни починають діяти, коли в кешах спливає TTL. Якщо в старих записів TTL — доба, то цілу добу відповіді будуть змішаними. Для попереднього винятку це важливо, для решти — майже ні.
Перевірте результат: запис DMARC — у перевірці DMARC, а SPF і MX — у перевірці домену.