Что такое DMARC
Оглавление
DMARC (Domain-based Message Authentication Reporting and Conformance) — это протокол для проверки подлинности отправителя, который защищает адресатов от фальшивых писем. Это инструкция для почтовых серверов адресата с правилами для писем, которые не прошли проверки по SPF и DKIM.
Как работает DMARC
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 — мягкая (по умолчанию).
v=DMARC1; p=quarantine; rua=reports@company.ru; ruf=errors@company.ru; pct=50; adkim=s |
Расшифруем:
- 50% писем, которые не прошли проверки, будут помещены в «Спам» на стороне адресата.
- Отчёты об ошибках придут на errors@company.ru, а полные отчёты — на reports@company.ru.
Обязательно ли настраивать DMARC
Да. С февраля 2024 года Yahoo и Gmail требуют не только SPF и DKIM, но и DMARC для массовых отправителей.
Для отправки писем через Mailganer запись DMARC тоже нужна. О том, как её добавить и настроить верификацию домена, мы написали в статье Верификация домена отправителя ›
RUA и RUF: как читать отчеты DMARC
Переменные RUA и RUF, как было упомянуто ранее, не являются обязательными в DMARC. При добавлении этих элементов в запись, пользователь будет регулярно получать общий отчет в формате XML с аналитикой и активностью DMARC (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>
Как читается:
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 (none, quarantine, reject).
* <sp>: Политика DMARC для поддоменов (none, quarantine, reject).
* <pct>: Процент писем, к которым применяется политика (обычно 100).
3. <record>: Содержит информацию о каждом источнике IP, отправлявшем письма от имени вашего домена.
* <row>: Информация об одном источнике IP.
* <source_ip>: IP-адрес отправителя.
* <count>: Количество писем, отправленных с этого IP-адреса.
* <policy_evaluated>: Результаты проверки DMARC.
* <disposition>: Действие, предпринятое почтовым сервером (none, quarantine, reject).
* <dkim>: Результат проверки DKIM (pass, fail, policy).
* <spf>: Результат проверки SPF (pass, fail, neutral, softfail, temperror, permerror).
1. <report_metadata>: Метаданные отчета (аналогично RUA).
2. <policy_published>: Опубликованная DMARC-политика (аналогично RUA).
3. <record>: Информация о письме, не прошедшем проверку.
* <row>: Данные о письме.
* <source_ip>: IP-адрес отправителя.
* <count>: Всегда 1, так как RUF относится к одному письму.
* <policy_evaluated>: Результаты проверки.
* <disposition>: Действие, предпринятое сервером (none, quarantine, reject).
* <dkim>: Результат DKIM.
* <spf>: Результат SPF.
* <reason>: Дополнительная информация о причине неудачи.
* <identifiers>: Идентификаторы письма.
* <header_from>: Значение заголовка From.
* <auth_results>: Детальные результаты аутентификации.
* <dkim>: Информация о проверке DKIM.
* <domain>: Домен, использованный для DKIM-подписи.
* <result>: Результат проверки.
* <selector>: Селектор DKIM.
* <spf>: Информация о проверке SPF.
* <domain>: Домен, использованный для проверки SPF.
* <result>: Результат проверки.
Расшифруем:
• Отчет показывает данные для домена 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 ›
Технический специалист поддержки Mailganer
