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

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

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

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

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

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

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

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

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

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

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

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

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

FAQ по DMARC

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

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

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

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

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

Важно! С 2024 года Google начал следить за доменами, которые рассылают более 5000 сообщений в сутки на ящики Gmail. Поэтому владельцы рассылок теперь обязаны прописывать SPF, DKIM и DMARC. О таких же требованиях рассказали и в Yahoo.

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

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

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

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

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

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

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

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

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

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

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

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. Распространённые примеры записей (в порядке нарастания строгости политики):

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