Настройка DMARC: собрать запись и выбрать политику

DMARC не настроена: что показывает эта надпись

Строку «для домена не настроена DMARC» показывают почтовые сервисы и сервисы проверки, когда по адресу _dmarc.ваш-домен в DNS ничего не опубликовано. Это не поломка, а именно отсутствие: домен просто не сказал получателям, что делать с письмами, которые не прошли проверку.

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

Порядок починки такой. Сначала SPF и DKIM: без них DMARC проверять нечего, и включать его смысла нет. Затем запись с политикой p=none и адресом для отчётов. Через две-три недели, когда по отчётам станет ясно, что вся ваша почта проходит проверку, политику ужесточают.

Какую политику ставить: none, quarantine или reject

Тег p принимает три значения, и разница между ними в том, что получатель делает с письмом, не прошедшим проверку.

Значение none не меняет ничего. Письма доставляются как обычно, а вам приходят отчёты. Это режим наблюдения, и начинать надо именно с него, потому что до первых отчётов вы не знаете, какие сервисы отправляют почту от вашего имени.

Значение quarantine отправляет непрошедшие письма в спам. Ставить его стоит тогда, когда по отчётам видно, что легитимные отправители проходят проверку, а непрошедшие письма это чужая активность.

Значение reject отклоняет письмо на входе, до того как оно попадёт хоть в какую-то папку. Это конечная цель и то, чего требуют Google и Yahoo от массовых отправителей. Переходить сюда раньше, чем отчёты покажут чистую картину, опасно: собственные рассылки просто перестанут доходить, и узнаете вы об этом от клиентов.

Отдельно про переходный период. Раньше для него ставили pct=25, и quarantine затрагивал четверть потока. В RFC 9989 (май 2026) этот тег убрали: реализации нового стандарта его пропускают и применяют политику ко всем письмам. Теперь для этого есть флаг t=y, генератор добавляет его переключателем «Тестовый режим». Политика объявлена, отчёты идут, а получателей просят пока её не применять.

Три ступени внедрения

1. p=none. Доставка не меняется, отчёты копятся. Держат две-четыре недели.
2. p=quarantine. Непрошедшие письма уходят в спам. Включают, когда в отчётах не осталось своих отправителей с провалом проверки.
3. p=reject. Непрошедшие письма отклоняются на входе. Конечная цель и требование Gmail с Yahoo для массовых отправителей.

Куда публиковать

TXT-записью на имя _dmarc.ваш-домен. В большинстве панелей в поле имени достаточно вписать _dmarc — домен подставится сам. Подчёркивание в начале обязательно, это самая частая опечатка.

Запись на организационном домене действует и на поддомены, у которых нет собственной. Отдельная запись поддомену нужна только тогда, когда ему требуется своя политика.

Чего DMARC не делает

Он не проверяет содержание письма и не защищает от похожих доменов. Против examp1e.com вместо example.com DMARC бессилен: это другой домен, и политика вашего к нему не относится. Он также не работает без настроенных SPF или DKIM: проверять будет нечего.

Куда слать отчёты

Адрес в rua= — единственная причина, по которой p=none вообще имеет смысл. Без него политика ничего не блокирует и ничего не показывает, то есть не делает вообще ничего.

Объём небольшой: один-два файла в сутки от каждого крупного провайдера. Но формат машинный, поэтому заводите отдельный ящик или разбирайте отчёты сервисом-анализатором. Читать XML руками можно первую неделю, дальше надоедает.

Если отчёты уходят на другой домен, нужна подтверждающая запись на стороне получателя: TXT на имя ваш-домен._report._dmarc.домен-получателя со значением v=DMARC1. Без неё провайдеры молча ничего не присылают, и это выглядит так, будто DMARC не работает.

Теги, которые обычно не нужны

• t=y: тестовый режим. Нужен на время перехода к quarantine или reject, потом убирается.
• pct, ri, rf: теги из RFC 7489, в RFC 9989 их нет. Старые записи с ними продолжают работать, новые реализации эти теги просто пропускают. BIMI по-прежнему не принимает pct меньше 100.
• sp=: отдельная политика для поддоменов. По умолчанию они наследуют p. Указывать стоит, только если поддомены сознательно оставляют мягче, а это обычно временное решение.
• adkim/aspf: строгость выравнивания. Значение по умолчанию нестрогое и подходит почти всем; строгий режим s ломает отправку с поддоменов.
• ruf=: форензик-отчёты. Почти никто их не шлёт из-за персональных данных внутри.
• fo: условия отправки отчётов о сбоях, на практике его не меняют.

Запись публикуется на _dmarc

Имя записи это _dmarc.ваш-домен, в поле имени панели обычно достаточно вписать _dmarc. Подчёркивание обязательно, и это частый источник ошибки: запись, положенная в корень домена рядом с SPF, просто не находится.

Проверять результат сразу после публикации бессмысленно, дайте DNS разойтись по кешам, обычно это от нескольких минут до часа в зависимости от TTL. Первые отчёты придут в течение суток, и по ним уже видно, все ли отправители учтены.

Поддомены наследуют политику

В отличие от SPF и DKIM, DMARC действует и на поддомены: политика с example.com распространяется на news.example.com, даже если у того нет своей записи. Это удобно с точки зрения защиты и опасно с точки зрения доставки, потому что при переходе на p=reject рассылки с поддоменов, у которых не настроена аутентификация, начнут отклоняться.

Тег sp= позволяет задать поддоменам отдельную, более мягкую политику. Пользоваться им стоит как временной мерой на время настройки: оставленный надолго, он превращает поддомены в открытую дверь для подделки, ради закрытия которой DMARC и внедряли.