DMARC — что это такое, обязательно ли настраивать

Оглавление

DMARC (Domain-based Message Authentication Reporting and Conformance) — это протокол для проверки подлинности отправителя, который защищает адресатов от фальшивых писем. Это инструкция для почтовых серверов адресата с правилами для писем, которые не прошли проверки по SPF и DKIM.

Как работает DMARC

DMARC не работает сам по себе — только в связке с SPF и DKIM. Эта запись отвечает на вопрос «Что делать с письмом отправителя, у которого некорректно настроены SPF и DKIM?». Есть три варианта:

None = ничего не делать, если проверка не пройдена = положить во Входящие
Quarantine = доставить, но с осторожностью = поместить в Спам
Reject = отклонить = вернуть ответ с ошибкой недоставки

Политика reject выглядит самой безопасной. Но её стоит использовать только если:

  • Вы точно знаете, что прямо сейчас от вашего имени шлют спам.
  • Вы перепроверили белый список и включили туда все нужные домены и сервисы — софт для рассылок, CRM-системы, SMTP для транзакционных писем, платёжные системы и др.

В противном случае reject приведёт к ложным срабатываниям — например, до клиентов не дойдут важные уведомления.

Из чего состоит запись DMARC

Рассмотрим обязательные и опциональные элементы записи DMARC.
Переменная
Обязательно ли добавлять?
Зачем нужна?
Возможные значения
v
Да
Это номер версии DMARC.
v=DMARC1
p
Да
Политика — что делаем с письмами, которые не прошли проверку?
none, quarantine или reject
rua или ruf
Только если вам нужны отчёты
Если добавить эту переменную, на указанный адрес будут каждый день приходить отчёты о проверках SPF/DKIM и действиях согласно политике DMARC. rua — для полных отчётов, ruf — для отчётов только с ошибками верификации.
rua=reports@company.ru
pct
Нет
Если добавить эту переменную, то под политику DMARC будут подпадать не все письма с неверными SPF/DKIM, а указанный процент.
От 1 до 100, например, pct=45%
adkim
Нет
Задаёт строгость совпадений по DKIM.
s — только точные совпадения, частичные попадают под политику DMARC.
r — частичные совпадения проходят проверку. Это значение по умолчанию.
adspf
Нет
Задаёт строгость совпадений по SPF.
По аналогии с adkim, s — строгая проверка, r — мягкая (по умолчанию).
Пример записи DMARC:

v=DMARC1; p=quarantine; rua=reports@company.ru; ruf=errors@company.ru; pct=50; adkim=s


Расшифруем:
  • 50% писем, которые не прошли проверки, будут помещены в «Спам» на стороне адресата.
  • Отчёты об ошибках придут на errors@company.ru, а полные отчёты — на reports@company.ru.
Включена строгая проверка DKIM — даже частичные совпадения отправятся в спам.

Обязательно ли настраивать DMARC

Да. С февраля 2024 года Yahoo и Gmail требуют не только SPF и DKIM, но и DMARC для массовых отправителей.

Для отправки писем через Mailganer запись DMARC тоже нужна. О том, как её добавить и настроить верификацию домена, мы написали в статье Верификация домена отправителя ›

RUA и RUF: как читать отчеты DMARC

Переменные RUA и RUF, как было упомянуто ранее, не являются обязательными в DMARC. При добавлении этих элементов в запись, пользователь будет регулярно получать общий отчет в формате XML с аналитикой и активностью DMARC (RUA) или отчет, содержащий только информацию об отдельных отклоненных письмах и возникших при верификации ошибках (RUF).

Пример отчета:
RUA
RUF
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
 <report_metadata>
 <org_name>Example.com</org_name>
 <email>dmarc_reports@example.com</email>
<extra_contact_info>http://example.com/
dmarc/
</extra_contact_info>
 <report_id>1 234 567 890</report_id>
 <date_range>
 <begin>1 678 886 400</begin>
 <end>1 679 059 199</end>
 </date_range>
 </report_metadata>
 <policy_published>
 <domain>example.com</domain>
 <adkim>r</adkim>
 <aspf>r</aspf>
 <p>none</p>
 <sp>none</sp>
 <pct>100</pct>
 </policy_published>
<record>
 <row>
 <source_ip>192.0.2.1</source_ip>
 <count>100</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>pass</dkim>
 <spf>pass</spf>
 </policy_evaluated>
 </row>
 <row>
 <source_ip>198.51.100.1</source_ip>
 <count>5</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>fail</dkim>
 <spf>fail</spf>
 </policy_evaluated>
 </row>
 </record>
</feedback>
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
 <report_metadata>
 <org_name>Example Receiving Domain</org_name>
<email>forensic@example.net</email>
 <report_id>87654321</report_id>
 <date_range>
 <begin>1679145600</begin>
 <end>1679145600</end>
 </date_range>
 </report_metadata>
 <policy_published>
 <domain>example.com</domain>
 <adkim>r</adkim>
 <aspf>r</aspf>
 <p>quarantine</p>
 <sp>none</sp>
 <pct>100</pct>
 </policy_published>
 <record>
<row>
 <source_ip>192.0.2.2</source_ip>
 <count>1</count>
 <policy_evaluated>
<disposition>quarantine</disposition>
 <dkim>fail</dkim>
 <spf>fail</spf>
 <reason>
 <type>dmarc</type>
 <code>001</code>
 <comment>dmarc fail, see other results</comment>
 </reason>
 </policy_evaluated>
 <identifiers>
<header_from>example.com</header_from>
 </identifiers>
 <auth_results>
 <dkim>
 <domain>example.net</domain>
 <result>fail</result>
 <selector>selector1</selector>
 </dkim>
 <spf>
 <domain>example.org</domain>
 <result>fail</result>
 </spf>
 </auth_results>
 </row>
 </record>
</feedback>
Как читается:
RUA
RUF
1. <report_metadata>: Метаданные отчета.
 * <org_name>: Название организации, отправляющей отчет.
 * <email>: Адрес электронной почты отправителя отчета.
 * <report_id>: Уникальный идентификатор отчета.
 * <date_range>: Период, за который собран отчет. <begin> и <end> - это временные метки Unix (количество секунд с 1 января 1970 года).
2. <policy_published>: Опубликованная DMARC-политика для домена.
 * <domain>: Домен, для которого применяется политика.
 * <adkim>: Выравнивание DKIM (r - relaxed, s - strict).
 * <aspf>: Выравнивание SPF (r - relaxed, s - strict).
 * <p>: Политика DMARC (nonequarantinereject).
 * <sp>: Политика DMARC для поддоменов (nonequarantinereject).
 * <pct>: Процент писем, к которым применяется политика (обычно 100).
3. <record>: Содержит информацию о каждом источнике IP, отправлявшем письма от имени вашего домена.
 * <row>: Информация об одном источнике IP.
 * <source_ip>: IP-адрес отправителя.
 * <count>: Количество писем, отправленных с этого IP-адреса.
 * <policy_evaluated>: Результаты проверки DMARC.
 * <disposition>: Действие, предпринятое почтовым сервером (none, quarantine, reject).
 * <dkim>: Результат проверки DKIM (passfailpolicy).
 * <spf>: Результат проверки SPF (passfailneutralsoftfailtemperrorpermerror).
1. <report_metadata>: Метаданные отчета (аналогично RUA).
2. <policy_published>: Опубликованная DMARC-политика (аналогично RUA).
3. <record>: Информация о письме, не прошедшем проверку.
 * <row>: Данные о письме.
 * <source_ip>: IP-адрес отправителя.
 * <count>: Всегда 1, так как RUF относится к одному письму.
 * <policy_evaluated>: Результаты проверки.
 * <disposition>: Действие, предпринятое сервером (nonequarantinereject).
 * <dkim>: Результат DKIM.
 * <spf>: Результат SPF.
 * <reason>: Дополнительная информация о причине неудачи.
 * <identifiers>: Идентификаторы письма.
 * <header_from>: Значение заголовка From.
 * <auth_results>: Детальные результаты аутентификации.
 * <dkim>: Информация о проверке DKIM.
 * <domain>: Домен, использованный для DKIM-подписи.
 * <result>: Результат проверки.
 * <selector>: Селектор DKIM.
 * <spf>: Информация о проверке SPF.
 * <domain>: Домен, использованный для проверки SPF.
 * <result>: Результат проверки.
Расшифруем:
RUA
RUF
• Отчет показывает данные для домена example.com за определенный период.

• DMARC — политика для домена — p=none (мониторинг).

• С IP-адреса 192.0.2.1 было отправлено 100 писем, которые прошли проверки SPF и DKIM.

• С IP-адреса 198.51.100.1 было отправлено 5 писем, которые не прошли проверки SPF и DKIM.
• Письмо от 192.0.2.2 с заголовком From: example.com не прошло DMARC-проверку.

• DMARC-политика — p=quarantine, поэтому письмо, вероятно, было помечено как спам.
• Проверки DKIM и SPF завершились неудачно.

• DKIM-подпись была с доменом example.net, а SPF-проверка проводилась для example.org. Это указывает на то, что письмо, скорее всего, поддельное.
Для облегчения восприятия отчетов DMARC лучше использовать специализированное ПО, которое конвертирует данные из XML в нативный формат, а также помогает советами по «лечению» ошибок. Ссылка на рекомендованный тул от DMARC.
Помогает перевести клиентские запросы на язык, понятный команде разработки. Отслеживает баги и тестирует новые фичи. Собирает идеи по улучшению продукта — и следит, чтобы они доехали до прода
Виктор Русин
Технический специалист поддержки Mailganer
13.03.2025
дата публикации
10.12.2025
дата последнего обновления