DMARC связывает SPF и DKIM с адресом, который видит получатель в поле «От», и говорит серверам, что делать с письмами, не прошедшими проверку. Кроме того, DMARC присылает отчёты о том, кто отправляет почту от имени вашего домена. Разберём теги записи, выравнивание и то, как внедрить DMARC, не потеряв нужные письма.
Какую проблему решает DMARC
SPF проверяет домен из адреса конверта (Return-Path), DKIM — домен из тега d= подписи. Ни один из них сам по себе не проверяет адрес в поле From, который видит человек. Мошенник может отправить письмо со своего домена с корректным SPF, но поставить в From адрес director@example.uz.
DMARC требует, чтобы хотя бы одна из проверок прошла и её домен совпадал с доменом в From. Это совпадение называется выравниванием (alignment).
Выравнивание: adkim и aspf
Письмо проходит DMARC, если выполняется хотя бы одно условие:
- SPF = pass, и домен из Return-Path выровнен с доменом From;
- DKIM = pass, и домен
d=выровнен с доменом From.
Режим выравнивания задаётся тегами aspf (для SPF) и adkim (для DKIM):
| Режим | Значение | Пример для From: example.uz |
|---|---|---|
r (relaxed, по умолчанию) | Достаточно совпадения организационного домена | d=mail.example.uz — выровнено |
s (strict) | Требуется точное совпадение | d=mail.example.uz — не выровнено |
Для большинства компаний подходит режим по умолчанию r. Строгий режим имеет смысл, только если вы точно знаете, что все источники отправляют с точным доменом.
Типичный случай: сервис рассылок проходит SPF, но для своего домена, а не для вашего. SPF при этом pass, а DMARC — fail, потому что нет выравнивания. Решение — настроить в сервисе DKIM-подпись с d=example.uz.
Запись DMARC и её теги
DMARC публикуется TXT-записью на поддомене _dmarc:
_dmarc.example.uz. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.uz"| Тег | Значения | Назначение |
|---|---|---|
v | DMARC1 | Версия, обязательна и стоит первой |
p | none, quarantine, reject | Политика для домена, обязательна |
sp | те же | Политика для поддоменов; если не указана, действует p |
pct | 0–100, по умолчанию 100 | Доля непрошедших писем, к которым применяется политика |
rua | mailto:-адреса | Куда присылать агрегированные отчёты |
ruf | mailto:-адреса | Отчёты по отдельным письмам; большинство крупных получателей их не присылает |
adkim, aspf | r или s | Режим выравнивания |
fo | 0, 1, d, s | Когда формировать отчёты по отдельным письмам |
Политики
p=none— только мониторинг: письма доставляются как обычно, вы получаете отчёты.p=quarantine— непрошедшие письма помещаются в спам или карантин.p=reject— непрошедшие письма отклоняются на этапе приёма.
Политика — это просьба к получателю, а не приказ. Крупные почтовые сервисы её учитывают, но окончательное решение принимает принимающая сторона.
Отчёты rua
Агрегированные отчёты — это XML-файлы (обычно в архиве), которые получатели присылают, как правило, раз в сутки. В них указано: с каких IP-адресов приходили письма от имени вашего домена, сколько их было, прошли ли они SPF и DKIM и было ли выравнивание.
- Создайте для отчётов отдельный ящик или алиас, например
dmarc@example.uz: при активной переписке отчётов бывает много. - Читать XML вручную неудобно — используйте сервис или программу для разбора DMARC-отчётов.
- Если отчёты должны приходить на адрес в другом домене, этот домен должен разрешить приём записью вида
example.uz._report._dmarc.reports.exampleс текстом"v=DMARC1". Без неё получатели не будут отправлять туда отчёты.
В отчётах вы, скорее всего, найдёте источники, о которых не знали: сайт, CRM, бухгалтерскую программу, рассылки. Каждый из них нужно либо настроить (SPF и DKIM с выравниванием), либо перестать использовать от имени домена.
Поэтапное внедрение
- Подготовка. Убедитесь, что для основной почты настроены SPF и DKIM и они проходят.
- Мониторинг. Опубликуйте
p=noneсrua. Собирайте отчёты 2–4 недели. - Исправление. Настройте все легитимные источники так, чтобы они проходили DMARC.
- Карантин частично. Перейдите на
p=quarantine; pct=25, затем увеличьтеpctдо 50 и 100, следя за отчётами и жалобами коллег. - Отклонение. Когда непрошедших легитимных писем не остаётся, установите
p=reject.
Этап 2: "v=DMARC1; p=none; rua=mailto:dmarc@example.uz"
Этап 4: "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.uz"
Этап 5: "v=DMARC1; p=reject; rua=mailto:dmarc@example.uz"Учтите, что получатели применяют pct приблизительно, а в обновлённой редакции стандарта (DMARCbis) этот тег предлагается заменить флагом t. Поэтому не стоит надолго оставаться на промежуточных значениях.
Не начинайте сразу с p=reject. Если какой-то сервис отправляет письма от вашего имени без выравнивания, эти письма перестанут доходить — и вы узнаете об этом только по жалобам клиентов.
Частые ошибки
- Запись не на том имени: DMARC должен быть на
_dmarc.example.uz, а не на самом домене. - Две записи DMARC: как и у SPF, запись должна быть одна, иначе DMARC игнорируется.
- Ошибки синтаксиса: теги разделяются точкой с запятой, адреса в
ruaпишутся с префиксомmailto:. - Забытые поддомены: если поддомены не используются для почты, добавьте
sp=reject. - Политика none навсегда:
p=noneзащиты не даёт, это только этап наблюдения.
DMARC стал обязательным требованием для массовых отправителей у ряда крупных почтовых сервисов, и даже для небольшой компании он заметно снижает риск подделки адреса и попадания в спам. В MCMail SPF, DKIM и DMARC для вашего домена настраиваем мы. Подробнее о других причинах проблем с доставкой — в статье почему письма попадают в спам.