DMARC-запись: как настроить DMARC пошагово (p=none → quarantine → reject)

DMARC-запись — одна строка в DNS, но именно она решает, что произойдёт с письмом, которое выдаёт себя за ваш домен и не прошло проверку. Настроить её небрежно — значит либо ничего не защитить, либо заблокировать собственные счета клиентам. Ниже — все теги, готовые примеры и план перехода от p=none к p=reject.

Если SPF, DKIM и выравнивание для вас новые понятия, начните со статьи SPF, DKIM и DMARC: что это и как настроить — DMARC опирается на обе проверки.

Где находится DMARC-запись

DMARC — TXT-запись на поддомене _dmarc того домена, который стоит в адресе «От кого»:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

На одном имени должна быть только одна DMARC-запись: если получатель найдёт две, он проигнорирует DMARC для домена. Поддомен без собственной записи наследует запись основного домена (example.com).

Теги DMARC

Мягкое и строгое выравнивание. При мягком домены должны лишь иметь общий основной домен: подпись с d=news.example.com совпадает с «От кого» example.com. Строгое требует точного совпадения. Почти всем подходит мягкое.

Примеры DMARC-записей

Только наблюдение — безопасный старт:

v=DMARC1; p=none; rua=mailto:[email protected]

Карантин для четверти непрошедших писем:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

Полная защита вместе с поддоменами:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

Домен, который вообще не отправляет почту (вместе с v=spf1 -all):

v=DMARC1; p=reject; sp=reject

После публикации проверьте запись в проверке DMARC: она покажет ошибки синтаксиса и то, как прочитан каждый тег.

Как настроить DMARC пошагово

1. Сначала убедитесь, что работают SPF и DKIM. Проверьте их в проверке SPF и проверке DKIM. Без них DMARC будет собирать только отчёты о провалах.
2. Выберите адрес для отчётов. Сводные отчёты — XML-файлы, у активного домена их десятки в день. Заведите отдельный ящик или подключите сервис разбора отчётов, а не личную почту.
3. Опубликуйте p=none с rua в панели DNS-провайдера: имя _dmarc, тип TXT.
4. Собирайте отчёты 2–4 недели, чтобы проявились отправители, которые пишут раз в неделю или месяц: счета, зарплатные ведомости, рассылки.
5. Исправьте каждый настоящий источник, который не проходит: включите в нём DKIM с вашим доменом или добавьте в SPF с выровненным Return-Path.
6. Переходите на p=quarantine, при желании с pct=25, затем 50 и 100, проверяя отчёты после каждого шага.
7. Переходите на p=reject, когда карантин несколько недель работает без сюрпризов.

Как читать сводные отчёты

Каждый отчёт — от одного почтового сервиса за один период, обычно сутки. Внутри строки вроде этих (упрощённо):

• Обе проверки выровнены — ваш основной сервер, всё в порядке.
• SPF прошёл, но не выровнен, DKIM провален — типичный сторонний сервис со своим Return-Path и без вашего DKIM-ключа. Выясните, чей это IP, и включите там DKIM с вашим доменом. При p=reject эти письма были бы заблокированы.
• Всё провалено с незнакомого IP — забытая система или подделка. Ловить подделки DMARC и создан, но сначала убедитесь, что это не ваш забытый сервер.

Кроме строк, у каждого отчёта есть шапка: кто его прислал (Google, Yahoo, Microsoft и другие), за какой период и какую политику сервис увидел в вашем DNS. Последнее — полезная сверка: если через неделю после публикации quarantine в отчёте всё ещё p=none, получатель видит старую или задвоенную запись. Отчёты приходят сжатыми вложениями (zip или gzip), по одному от сервиса в сутки, так что у активного домена быстро набираются сотни файлов.

Сырой XML в больших объёмах читать тяжело, поэтому обычно используют сервисы разбора. Но даже без них открыть несколько отчётов вручную в первую неделю достаточно, чтобы увидеть незнакомых отправителей.

Политика для поддоменов

Тег sp задаёт политику для поддоменов без собственной DMARC-записи. Два типичных варианта:

• p=reject; sp=reject — всё закрыто, когда вы уверены в настройке.
• p=reject; sp=none — основной домен защищён, поддомены ещё проверяются. Не оставляйте так надолго: подделывать billing.example.com злоумышленникам ничуть не хуже.

Поддомен, который сам отправляет почту, например news.example.com, может иметь свою запись _dmarc.news.example.com — она важнее sp.

Отчёты на адрес другого домена

Если адрес в rua находится на другом домене — обычно это сервис разбора отчётов, — этот домен должен подтвердить, что согласен их получать. Иначе почтовые сервисы пропустят такой адрес. Разрешение — TXT-запись на стороне получателя отчётов:

example.com._report._dmarc.reports-provider.net.  TXT  "v=DMARC1"

Сервисы отчётов обычно публикуют её сами или ставят общую запись со звёздочкой для всех клиентов. Проверка DMARC смотрит эту запись для каждого внешнего адреса в rua и ruf.

Частые ошибки в DMARC-записи

• Неверное имя. Запись ставится на _dmarc, а не на сам домен. Если DNS-панель сама дописывает домен, вводите только _dmarc, иначе получится _dmarc.example.com.example.com.
• v=DMARC1 не первым тегом или с опечаткой, например v=DMARC 1 с пробелом. Получатели считают, что записи нет.
• Нет mailto: в rua. Значение должно быть адресом-URI: rua=mailto:[email protected], а не просто ящиком.
• Две DMARC-записи, оставшиеся после смены сервиса отчётов. Оставьте одну, а несколько адресов перечислите в rua через запятую.
• Политику ужесточили, а отчёты никто не читает. Запись с p=reject и переполненным или заброшенным ящиком rua — значит, вы не заметите, когда новый сервис начнёт проваливать проверку.

После каждого изменения дайте DNS обновиться (обычно от минут до нескольких часов, в зависимости от TTL записи) и проверьте результат в проверке DMARC. Первые сводные отчёты обычно приходят в течение суток-двух: большинство почтовых сервисов отправляет их раз в день.

Что ломается при p=reject

• Списки рассылки, которые добавляют подпись или метку в тему, ломают DKIM, а IP сервера списка ломает SPF. Многие списки теперь переписывают адрес «От кого»; помогает и ARC — механизм, который сохраняет результаты проверок при пересылке.
• Простая пересылка ломает SPF, но сохраняет DKIM, если письмо не изменено. Ещё одна причина сделать DKIM основной выровненной проверкой.
• Формы на сайте, которые отправляют письмо «от посетителя» или от вашего домена через почту хостинга. Отправляйте их через сервис с аутентификацией вашего домена.

Перед такими изменениями проверьте и MX-записи в проверке MX: отчёты приходят по почте, и им нужно куда-то доходить.