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

О чём будем говорить:

• Как работает DMARC
• Как добавить DMARC
• Часто используемые записи DMARC
• Синтаксис 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

FAQ по DMARC

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

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

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

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

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

Рассмотрим пример записи 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 — ? На текущий момент некоторые почтовые провайдеры, такие как Mail.ru, Yahoo, AOL уже включили строгую политику DMARC p=reject для своих доменов.

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