menu

Как прописать DMARC: путеводитель с примерами

На самом деле, всё просто

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

Получатель сообщает данные об инфраструктуре проверки подлинности почты. Отправитель — о том, что делать, если сообщение не прошло проверку.

Пока звучит запутанно, но скоро мы во всём разберёмся 😎

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

DMARC разработан так, чтобы с минимальными усилиями внедрить его в любой процесс отправки почты.

Он помогает определить, соответствует ли сообщение тому, что получатель знает об отправителе. Или проще: можно ли доверять этому отправителю. Если да — подписчик получает сообщение. Если нет — срабатывает политика DMARC для неаутентифицированных сообщений.

Приведём пример.

Пример

Допустим, есть две страны (домена), причем пересечение границы первой страны (получателя) гражданами второй страны (отправителя) разрешено второй страной только при наличии паспорта (SPF, DKIM).

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

Вот как выглядит полный цикл отправки-приёма email сообщений с включённой DMARC-политикой.

Как работает политика DMARC

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

Важно отметить, что DMARC основывается на спецификациях DomainKeys Identified Mail (DKIM) и Sender Policy Framework (SPF), которые в настоящее время разрабатываются в IETF (Инженерный совет Интернета (англ. Internet Engineering Task Force, IETF) — открытое международное сообщество проектировщиков, учёных, сетевых операторов и провайдеров, созданное IAB в 1986 году и занимающееся развитием протоколов и архитектуры интернета).

Подробная техническая информация о DMARC

FAQ по DMARC

Как добавить DMARC

Добавить DMARC для вашего домена довольно просто. Для этого надо найти панель управления DNS-записями на вашем хостинге и внести туда новую TXT-запись с хостом _dmarc.

Примерный порядок действий:

  • Вспоминаем, на каком хостинге у нас сайт.
  • Заходим на сайт хостинг-провайдера.
  • Заходим в панель управления хостингом.
  • В настройках находим управление DNS-записями.
  • Вносим новую TXT-запись (ниже покажем, что именно надо написать).
  • Сохраняем изменения.

Вот пример, как это выглядит в хостинге Fornex.

Как добавить DMARC

Рассмотрим пример записи DMARC TXT для домена «sender.example.com»:

v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@example.com

В этом примере отправитель требует, чтобы получатель отклонил все неаутентифицированные сообщения и отправил агрегированный отчёт об отклонении по адресу postmaster@example.com.

Часто используемые записи DMARC

Чтобы вам не ломать голову, приведем ниже четыре самые распространенные DMARC-записи:

v=DMARC1;p=none

Самая простая DMARC-запись. По сути, она не призывает сервер получателя ни к каким действиям по отношению к неаутентифицированным письмам. Мы рекомендуем её внести, чтобы проверить, что всё работает исправно.

v=DMARC1;p=none;rua=mailto:postmaster@yourdomain.com

Показывает получателю, что не надо отклонять никаких писем, но вам на указанный адрес будет отправляться письмо. В письме — агрегированный отчёт об отправленных письмах и серверах, откуда они ушли. Такая запись нужна, если вы хотите увидеть, идёт ли от вас нежелательный трафик. Ещё это промежуточный вариант перед включением политики reject (полного отклонения неаутентифицированных сообщений).

v=DMARC1;p=quarantine;rua=mailto:postmaster@yourdomain.com

Вариант-середнячок, один из самых распространённых. Письма, которые не аутентифицированы, будут помечаться вашим почтовым сервисом как спам или как нежелательные (зависит от сервиса).

v=DMARC1;p=reject;pct=25;rua=mailto:postmaster@yourdomain.com

Это уже строгая политика DMARC относительно неаутентифицированных сообщений. Мы рекомендуем вам постепенно наращивать процент отклонения таких писем: начиная с 25%, понемногу переходить к 100%. Например, когда мы в UniSender вводили DMARC, мы перешли на 100% за полтора месяца.

Ниже описываю синтаксис и значение тэгов.

Синтаксис DMARC и описание тэгов

Начну с таблицы тэгов. Потом подробнее расскажу о каждом из них.

Тэг Назначение Пример Обязательный (да/нет)
v Версия протокола v=DMARC1 Да
pct Процент сообщений, подлежащих фильтрации pct=20 Нет
ruf URI для отправки отчетов ruf=mailto:fail@example.com Нет
rua URI для отправки агрегированных отчетов rua=mailto:aggr@example.com Нет
p Политика домена p=quarantine Да
sp Политика для субдомена sp=reject Нет
adkim Режим аутентификации для DKIM adkim=s Нет
aspf Режим аутентификации для SPF aspf=r Нет
fo Настройки отчетов об ошибках fo=1 Нет
rf Формат для отчетов об ошибках rf=afrf Нет
rf Интервал между отправкой агрегированных отчетов (в секундах). ri=86400 Нет
Тэг: v
Назначение Версия протокола
Пример v=DMARC1
Обязательный (да/нет) Да
Тэг: pct
Назначение Процент сообщений, подлежащих фильтрации
Пример pct=20
Обязательный (да/нет) Нет
Тэг: ruf
Назначение URI для отправки отчетов
Пример ruf=mailto:fail@example.com
Обязательный (да/нет) Нет
Тэг: rua
Назначение URI для отправки агрегированных отчетов
Пример rua=mailto:aggr@example.com
Обязательный (да/нет) Нет
Тэг: p
Назначение Политика домена
Пример p=quarantine
Обязательный (да/нет) Да
Тэг: sp
Назначение Политика для субдомена
Пример sp=reject
Обязательный (да/нет) Нет
Тэг: adkim
Назначение Режим аутентификации для DKIM
Пример adkim=s
Обязательный (да/нет) Нет
Тэг: aspf
Назначение Режим аутентификации для SPF
Пример aspf=r
Обязательный (да/нет) Нет
Тэг: fo
Назначение Настройки отчетов об ошибках
Пример fo=1
Обязательный (да/нет) Нет
Тэг: rf
Назначение Формат для отчетов об ошибках
Пример rf=afrf
Обязательный (да/нет) Нет
Тэг: ri
Назначение Интервал между отправкой агрегированных отчетов (в секундах)
Пример ri=86400
Обязательный (да/нет) Нет

Как вы поняли, все тэги делятся на обязательные и нет. Начнём с обязательных.

Обязательные тэги

p

Политика для приёма сообщений. Обязательный тэг. Определяет политику приёма сообщений для домена и поддоменов (если отдельно не указана политика для поддоменов с помощью тега «sp»).

Принимаемые значения:

  • none: никаких действий предпринимать не требуется.
  • quarantine: владелец домена просит, чтобы сообщения, не прошедшие DMARC проверку, рассматривались как подозрительные. В зависимости от получателя это значит, что сообщения попадут в папку «спам», получат пометку о необходимости быть внимательным или помечены подозрительными.
  • reject: владелец домена просит, чтобы сообщения, не прошедшие проверку DMARС, были отклонены. Отклонение должно производиться во время SMTP-транзакции.

v

Версия. Обязательный тэг. Обязательно должен принимать значение DMARC1. Если это не так, то запись будет проигнорирована.

Необязательные тэги

adkim

Проверка на аутентификацию DKIM-записи. Может принимать значение «r» — relaxed или «s» — strict. По умолчанию принимает значение «r».

В режиме relaxed, если проверяемая DKIM-запись относится к домену d=example.com, а отправка идет от адреса email@news.example.com, проверка будет пройдена. В случае strict проверка будет пройдена только в том случае, если отправка идет от адреса на домене example.com. Поддомены не пройдут проверку.

aspf

Проверка на аутентификацию SPF-записи. Не обязательный тэг. По аналогии с adkim, может принимать значение «r» — relaxed или «s» — strict. По умолчанию принимает значение «r».

fo

Настройки отчетов об ошибках.  По умолчанию принимает значение «0».

Принимаемые значения:

  • 0: генерировать отчёт об ошибках DMARC, если все основные механизмы аутентификации не пройдены.
  • 1: генерировать отчёт об ошибках DMARC, если хотя бы один механизм аутентификации не пройден.
  • d: генерировать отчёт об ошибке DKIM, если сообщение провалило проверку на DKIM, независимо от аутентификации.
  • s: генерировать отчёт об ошибке SPF, если сообщение провалило проверку на SPF, независимо от аутентификации.

pct

Процент сообщений, к которым применяется политика DMARC. Любое целое число от 0 до 100. По умолчанию значение 100.

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

rf

Формат для отчётов об ошибках. По умолчанию значение afrf. На текущий момент поддерживается только это значение.

ri

Интервал между отправкой агрегированных отчетов (в секундах). Значение по умолчанию: 86400 (1 раз в сутки).

rua

Адреса для отправки агрегированных отчётов, разделенные запятой. Возможно указание mailto: ссылки для отправки отчетов по почте.

ruf

Адреса для отправки отчетов об ошибках, разделенные запятой. Указание этого тэга подразумевает, что владелец домена требует от серверов получателей отправлять детальные отчеты о каждом сообщении, не прошедшем проверку DMARC.

sp

Политика DMARC для поддоменов (по аналогии с тегом p).

История DMARC

Пара слов о создании и задачах политики DMARC.

Больше 10 лет назад для аутентификации отправителя были созданы технологии SPF и DKIM. Они помогали отследить мошеннические сообщения, отправленные от имени банков, социальных сетей, почтовых служб.

Казалось бы, SPF и DKIM позволяли легко отличить мошеннические сообщения от нормальных. Но это стало трудным по ряду причин:

  1. Многие отправители имеют сложную систему отправки сообщений. Например, используют сторонних поставщиков услуг. Например, сервисы рассылок.
  2. Если часть отправляемых сообщений аутентифицированы, а часть нет. Получатели вынуждены как-то различать неаутентифицированные и мошеннические сообщения. Иначе мошеннические могут попасть во «Входящие».
  3. Плохая обратная связь. Нет никакого способа определить, сколько неаутентифицированных или мошеннических сообщений отравлено. DMARC решает эту проблему.
  4. Если даже все сообщения аутентифицированы, получатели могут предположить, что неаутентифицированное сообщение — ошибка, а не способ мошенничества. Получатели не могут быть уверены, что не существует легитимных неподписанных ключами сообщений.

Пример

В папку «спам» пришло письмо. Иван открыл этот письмо и видит, что почтовик пишет «Это письмо может быть мошенническим». Отправитель, тема, дизайн письма — всё соответствует тем письмам, которые он получал раньше от, скажем, банка.

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

Если Иван не имеет достаточного опыта, чтобы изучить технические заголовки письма, он не сможет разобраться, на самом ли деле сообщение мошенническое или нет.

В 2007 году PayPal впервые применил этот подход и разработал в сотрудничестве с Yahoo, Google и Microsoft систему обмена данными между отправителем и получателем. Результат был чрезвычайно эффективным. Мошеннических email, предположительно полученных от PayPal, стало намного меньше.

Запомнить главное

DMARC — это политика, благодаря которой получатель письма понимает, можно ли доверять его отправителю. Позволяет бороться со спамом, фишингом и нежелательной почтой.

Чтобы настроить DMARC, зайдите в панель управления хостингом и внесите в настройки DNS-запись формата TXT. Распространённые примеры записей (в порядке нарастания строгости политики):

v=DMARC1;p=none

v=DMARC1;p=none;rua=mailto:postmaster@yourdomain.com

v=DMARC1;p=quarantine;rua=mailto:postmaster@yourdomain.com

v=DMARC1;p=reject;pct=25;rua=mailto:postmaster@yourdomain.com

DMARC — 👍 На текущий момент некоторые почтовые провайдеры, такие как Mail.ru, Yahoo, AOL уже включили строгую политику DMARC p=reject для своих доменов.

Круто, что вы заботитесь о безопасности ваших рассылок. Если возникнут трудности — пишите в комментариях.