Как настроить dmarc для домена

HowTo: DMARC

Недавно пришлось столкнуться со спамящим php-скриптом. Виновник был найден и уничтожен, дыра закрыта… Оставался вопрос с блэклистами. В частности перестала доходить почта на Gmail (reject).
Решил я настроить почту «как надо» — SPF, DKIM и попробовать настроить DMARC.
Оговорюсь сразу — я даже не пробовал разобраться с макросами и не настраивал aspf/adkim (хоть и написал о них).

Что такое DMARC?

Настройка DMARC

Можно почитать документацию и постигнуть Дзен, а можно настроить самую базовую политику — настраивается очень просто — к домену добавляется запись

Базовый DMARC

_dmarc.domain.tld IN TXT «v=DMARC1; p=;»

p — policy — политика, может быть:
none — не принимать никаких особых действий, всё на усмотрение почтовика;
quarantine — отпарвить в спам;
reject — не принимать письмо.

Но такая настройка подходит только в случае единичного сервера и только если вам всё равно доходит почта или нет. Более правильная политика, учитывающая наличие поддоменов с которых может слаться почта и позволяющая получать отчеты:

Простой DMARC

_dmarc.domain.tld IN TXT «v=DMARC1; p=none; sp=none; rua=mailto:postmaster@domain.tld»

sp — subdomain policy — может принимать значения те же что и policy;

rua — reporting URI for aggregate reports — задает почтовый адрес в формате mailto:mbox@domain.tld на который раз в сутки будут приходить отчеты в XML

Есть также такой параметр как ri — requested interval — интервал отправки агрегированных отчетов, задается в секундах, по умолчанию 86400. На практике зачастую игнорируется и отчеты присылаются раз в сутки.

Такая политика:
— позволяет получателям почты самим принимать решения что с ней делать;
— охватывает как основной домен ( @domain.tld ) так и все поддомены (например @srv1.domain.tld , @srv2.domain.tld );
— устанавливает почтовый адрес для принятия ежедневных отчетов о доставке почты ( postmaster@domain.tld ).

Это, разумеется, не всё, но для группы вебсерверов на этом можно и остановиться. А я, пожалуй, продолжу.

Готовим сложный DMARC

Сам по себе DMARC прост, сложности наступают с применением политик quarantine и reject , поэтому прежде чем перейти к применению таких политик нужно рассказать об остальных полях:
pct — percentage — процент писем, которые подвергаются политикам, не влияет на forensic report. Например, при политике «v=DMARC1; p=quarantine; pct=50;» половина писем не прошедших аутентификацию пойдет в спам. По умолчанию pct=100 .

aspf — alignment mode for SPF — режим аутентификации SPF:
r — relaxed — аутентификацию могут проходят письма у которых RFC5322.From и SPF-аутентифицированный домен находятся в пределах одного организационного домена (о них ниже, под спойлером). Например, в этом режиме будут аутентифицированы письма у которых в домене, указанном в RFC5321.MailFrom, «some.sub.domain.tld», а поле RFC5322.From — «mbox@domain.tld»;
s — strict — домен из RFC5321.MailFrom и RFC5322.From должен плностью совпадать.

adkim — alignment mode for DKIM — режим аутентификации DKIM, может принимать следующие значения:
r — relaxed — аутентификация производится следующим образом: организационный домен из поля RFC5322.From в письме и организационный домен из поля d= в подписи должны совпадать, Что такое организационный домен и как он определяется — под спойлером:

Organizational Domain:
The domain that was registered with a domain name registrar. In the absence of more accurate methods, heuristics are used to determine this, since it is not always the case that the registered domain name is simply a top-level DNS domain plus one component (e.g., «example.com», where «com» is a top-level domain). The Organizational Domain is determined by applying the algorithm found in Section 3.2.
.
The Organizational Domain is determined using the following algorithm:

1. Acquire a «public suffix» list, i.e., a list of DNS domain names reserved for registrations. Some country Top-Level Domains (TLDs) make specific registration requirements, e.g., the United Kingdom places company registrations under «.co.uk»; other TLDs such as «.com» appear in the IANA registry of top-level DNS domains. A public suffix list is the union of all of these. Appendix A.6.1 contains some discussion about obtaining a public suffix list.
2. Break the subject DNS domain name into a set of «n» ordered labels. Number these labels from right to left; e.g., for «example.com», «com» would be label 1 and «example» would be label 2.
3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be «x».
4. Construct a new DNS domain name using the name that matched from the public suffix list and prefixing to it the «x+1″th label from the subject domain. This new name is the Organizational Domain.

Thus, since «com» is an IANA-registered TLD, a subject domain of «a.b.c.d.example.com» would have an Organizational Domain of «example.com».

The process of determining a suffix is currently a heuristic one. No list is guaranteed to be accurate or current.

1. Получается список «публичных суффиксов», за объяснениями что это такое лучше пойти сюда publicsuffix.org
2, Из письма извлекается почтовый домен, разбивается и нумеруется справа налево на части. В терминологии этой статьи — sub.domain.tld превратится в #3 — sub , #2 — domain , #1 — tld .
3. В списке публичных суффиксов найти такой суффикс, чтобы с ним совпадало наиболшее число частей, пусть это будет Х.
4. Собрать новый домен из Х+1 частей — это и будет организационный домен.

Пример:
Письмо от info@a.sub.domain.tld
Части: tld — #1, domain — #2, sub — #3, a — #4
Далее в списке публичных суфиксов находится tld , поэтому Х=1
Соответственно новый домен для письма будет из 2х частей — domain.tld

s — strict — FQDN из поля d= в подписи и RFC5322.From из письма должны полностью совпадать для прохождения проверки.

ruf — reporting URI for forensic reports — почта для немедленных отчетов об ошибках аутентификации. К сожалению не все почтовые сервисы поддерживают отсылку этих отчетов (например, Gmail на момент написания этой статьи).

fo — failure report options — контролирует в каком случае присылается forensic report:
0 — используется по умолчанию — присылать отчет если не пройден ни один этап аутентификации;
1 — присылать отчет если не пройден хотя бы один этап аутентификации;
d — присылать отчет если не пройдена аутентификация DKIM;
s — присылать отчет если не пройдена аутентификация SPF.

Как правильно использовать DMARC?

Тут всё зависит от ваших потребностей:
Для вебсерверов я бы рекомендовал простой DMARC, указанный мною ранее:
_dmarc.domain.tld IN TXT «v=DMARC1; p=none; sp=none; rua=mailto:postmaster@domain.tld»

В любом случае начинать нужно с такой политики и какое-то время нужно мониторить чтобы все письма приходили. Далее можно сменить политику на quarantine , применить её к 5% (указав pct=5 ) почты и с интервалом в, например, одну неделю поднимать процент до 10-20-35-50-75-100%, а потом так же перейти на политику reject .

При перенастройках SPF/DKIM также неплохо выставлять ruf=mailto:your-mbox@domain.tld и fo=1 для получения отчетов о поломках.

На этом всё, об опечатках прошу сообщать в личку, а о неточностях и ошибках — в комментариях, я внесу исправления в статью.

Источник

Настройка DKIM/SPF/DMARC записей или защищаемся от спуфинга

1. DKIM

DKIM (DomainKeys Identified Mail) — это метод e-mail аутентификации, основанный на проверке подлинности цифровой подписи. Публичный ключ хранится TXT записи домена.

Зачем же он нужен?

DKIM необходим для того, чтобы почтовые сервисы могли проверять, является ли отправитель достоверным или нет. Т.е. защищает получателя письма от различных мошеннических писем (которые отправлены с подменой адреса отправителя).

Настройка DKIM подписи и DNS записей

Для это нам необходимо создать пару ключей:

Или можно воспользоваться онлайн-сервисом, чего я крайне не советую.

Далее необходимо указать путь с секретному ключу в файле конфигурации (для этого лучше почитать документацию) почтового сервера и публичный ключ в DNS.

Примером записей является
mail._domainkey.your.tld TXT «v=DKIM1; k=rsa; t=s; p= »

где
mail — селектор. Можно указать несколько записей с разными селекторами, где в каждой записи будет свой ключ. Применяется тогда, когда задействовано несколько серверов. (на каждый сервер свой ключ)
v — версия DKIM, всегда принимает значение v=DKIM1 . (обязательный аргумент)
k — тип ключа, всегда k=rsa . (по крайней мере, на текущий момент)
p — публичный ключ, кодированный в base64. (обязательный аргумент)
t — Флаги:
t=y — режим тестирования. Такие отличают отличаются от неподписанных и нужны лишь для отслеживания результатов.
t=s — означает, что запись будет использована только для домена, к которому относится запись, не рекомендуется, если используются субдомены.
возможные:
h — предпочитаемый hash-алгоритм, может принимать значения h=sha1 и h=sha256
s — Тип сервиса, использующего DKIM. Принимает значения s=email (электронная почта) и s=* (все сервисы) По-умолчанию «*».
; — разделитель.

Так же стоит прописать ADSP запись, которая позволяет понять, обязательно должно быть письмо подписано или нет.
_adsp._domainkey.example.com. TXT «dkim=all»

Значений может быть три:
all — Все письма должны быть подписаны
discardable — Не принимать письма без подписи
unknown — Неизвестно (что, по сути, аналогично отсутствию записи)

2. SPF

SPF (Sender Policy Framework) — расширение для протокола отправки электронной почты через SMTP. SPF определен в RFC 7208 (Wiki). Если простым языком, то SPF — механизм для проверки подлинности сообщением, путем проверки сервера отправителя. Как по мне, данная технология полезна в связке в другими (DKIM и DMARC)

Настройка SPF записей

all»
Здесь:
v=spf1 является версией, всегда spf1
a — разрешает отправляет письма с адреса, который указан в A и\или AAAA записи домена отправителя
mx — разрешает отправлять письма c адреса, который указан в mx записи домена
(для a и mx можно указать и другой домен, например, при значении a:example.com , будет разрешена а запись не домена отправителя, а example.com)
Так же можно добавлять и отдельные ip адреса, используя ip4: и ip6: . Например, ip4:1.1.1.1 ip6: 2001:0DB8:AA10:0001:0000:0000:0000:00FB . Еще есть include: ( include:spf.example.com ), позволяющий дополнительно подключать spf записи другого домена. Это все можно комбинировать через пробел. Если же нужно просто использовать запись с другого домена, не дополняя её, то лучше всего использовать redirect: ( redirect:spf.example.com )
-all — означает то, что будет происходить с письмами, которые не соответствуют политике: «-» — отклонять, «+» — пропускать, «

» — дополнительные проверки, «?» — нейтрально.

3.DMARC

Domain-based Message Authentication, Reporting and Conformance (идентификация сообщений, создание отчётов и определение соответствия по доменному имени) или DMARC — это техническая спецификация, созданная группой организаций, предназначенная для снижения количества спамовых и фишинговых электронных писем, основанная на идентификации почтовых доменов отправителя на основании правил и признаков, заданных на почтовом сервере получателя (Wiki). То есть почтовый сервер сам решает, хорошее сообщение или плохое (допустим, исходя из политик выше) и действует согласно DMARC записи.

Настройка DMARC записей

Типичная запись выглядит так: _dmarc.your.tld TXT «v=DMARC1; p=none; rua=mailto:postmaster@your.tld»
В ней не предпринимаются никакие действия, кроме подготовки и отправки отчета.

Теперь подробнее о тегах:
v — версия, принимает значение v=DMARC1 (обязательный параметр)
p — правило для домена. (Обязательный параметр) Может принимать значения none , quarantine и reject , где
p=none не делает ничего, кроме подготовки отчетов
p=quarantine добавляет письмо в СПАМ
p=reject отклоняет письмо
Тэг sp отвечает за субдомены и принимает такие же значения, как и p
aspf и adkim позволяют проверять соответствиям записям и могут принимать значения r и s , где r — relaxed более мягкая проверка, чем s — strict.
pct отвечает за кол-во писем, подлежащих фильтрации, указывается в процентах, например, pct=20 будет фильтровать 20% писем.
rua — позволяет отправлять ежедневные отчеты на email, пример: rua=mailto:postmaster@your.tld , так же можно указать несколько email через пробел ( rua=mailto:postmaster@your.tld mailto:dmarc@your.tld )

ruf — отчеты писем, не прошедшие проверку DMARC. В остальном все так же, как и выше.

Эпилог

Мы научились настраивать DKIM/SPF/DMARC и противостоять спуфингу. К сожалению, это не гарантирует безопасность в случае взлома сервера или же отправки писем на серверы, не поддерживающие данные технологии. Благо, что популярные сервисы все же их поддерживают (а некоторые и являются инициаторами данных политик).

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

Источник

Как настроить dmarc для домена

DMARC (Domain-based Message Authentication, Reporting and Conformance) — это техническая спецификация, созданная группой организаций для борьбы со спамерами, подделывающими адреса отправителей.

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

Подготовка к настройке DMARC

Перед настройкой DMARC необходимо:

Это связано с тем, что технология DMARC использует данные средства. Если отправленное сообщение не прошло проверку DKIM и SPF, то оно не пройдет и DMARC. Если же сообщение успешно прошло хотя бы одну проверку (DKIM или SPF), то и проверку DMARC сообщение пройдет успешно.

Настройка DMARC

Чтобы настроить политику DMARC:

1. Перейдите на сайт провайдера, у которого находится DNS-зона управления вашим доменом;
2. Введите логин и пароль для входа в «Панель управления»;
3. Перейдите в раздел управления DNS-зонами необходимого домена.
4. Добавьте новую TXT-запись вида _dmarc.example.com (где вместо example.com должен быть ваш домен), соответствующую выбранной политике.

Пример записи: «v=DMARC1;p=none;rua=mailto:rua@example.com;ruf=mailto:ruf@example.com;fo=s»

Некоторые провайдеры ставят кавычки для TXT-записи самостоятельно. Вы можете уточнить необходимость кавычек у хостинг-провайдера или взять за образец другую ТХТ-запись домена, если она есть.

В TXT-записи можно использовать следующие теги:

Источник