Только начинаете с 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 — в проверке домена.