HowTo: DMARC
Недавно пришлось столкнуться со спамящим php-скриптом. Виновник был найден и уничтожен, дыра закрыта… Оставался вопрос с блэклистами. В частности перестала доходить почта на Gmail (reject).
Решил я настроить почту «как надо» — SPF, DKIM и попробовать настроить DMARC.
Оговорюсь сразу — я даже не пробовал разобраться с макросами и не настраивал aspf/adkim (хоть и написал о них).
Что такое DMARC?
Настройка DMARC
Можно почитать документацию и постигнуть Дзен, а можно настроить самую базовую политику — настраивается очень просто — к домену добавляется запись
Базовый DMARC
_dmarc.domain.tld IN TXT «v=DMARC1; p=;»
Но такая настройка подходит только в случае единичного сервера и только если вам всё равно доходит почта или нет. Более правильная политика, учитывающая наличие поддоменов с которых может слаться почта и позволяющая получать отчеты:
Простой DMARC
_dmarc.domain.tld IN TXT «v=DMARC1; p=none; sp=none; rua=mailto:postmaster@domain.tld»
Это, разумеется, не всё, но для группы вебсерверов на этом можно и остановиться. А я, пожалуй, продолжу.
Готовим сложный DMARC
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.
Как правильно использовать DMARC?
Тут всё зависит от ваших потребностей:
Для вебсерверов я бы рекомендовал простой DMARC, указанный мною ранее:
_dmarc.domain.tld IN TXT «v=DMARC1; p=none; sp=none; rua=mailto:postmaster@domain.tld»
DMARC: защитите вашу рассылку от подделок
Сталкивались ли вы с проблемой, что письма от вашего сервиса подделываются с целью вымогательства пароля или других конфиденциальных данных? Ежедневно к пользователям пытаются пробиться тысячи спамерских, фишинговых и мошеннических писем, которые злоумышленники маскируют под сообщения от известных сервисов.
Такие письма причиняют ущерб адресатам, что, в конечном счете, сказывается на репутации как самих добропорядочных сервисов, так и почтовых провайдеров.
Теперь мы даем сервисам, которые ведут свои рассылки, возможность защититься от такого рода подделок с помощью технологии DMARC (dmarc.org), которую мы поддержали первыми среди крупных почтовых сервисов в рунете.
Как работает DMARC
Суть технологии проста: вы как владелец домена, с которого ведутся рассылки, можете прописать в DNS своего домена политику, определяющую, что делать с письмами, которые признаны поддельными.
Письма могут быть пропущены, положены в папку «Спам» или вообще не приняты почтовым сервером.
Для работы этой технологии требуется настроить SPF для вашего домена и подписывать каждое письмо DKIM-подписью. При этом домен DKIM должен совпадать с доменом в заголовке From.
При получении письма наш сервер проверит валидность SPF и DKIM. В случае, если проверка и DKIM и SPF не пройдена, к письму будет применена DMARC-политика вашего домена.
Я уже хочу. Что мне делать?
Первое, что необходимо сделать — решить, как будет внедряться DMARC. Мы рекомендуем делать это не сразу, а постепенно:
Такой пошаговый подход позволит вовремя выявить проблемы с DKIM-подписью, если они есть, и исправить их прежде, чем политика будет развернута на 100%.
Для включения политики DMARC нужно разместить в DNS-записи вашего сайта новую TXT-запись вида:
В таком виде запись означает, что все поддельные письма нужно пропускать, а отчеты надо высылать на ящик postmaster@exampledomain.ru; exampledomain.ru необходимо заменить на ваш домен.
Если вы хотите получать отчеты на домен, который не совпадает с доменом DMARC, вам необходимо разместить TXT-запись для почтового домена специального вида. Допустим, ваш домен с DMARC — exampledomain.ru, а получать отчеты вы хотите на домен test.ru. В таком случае необходимо в DNS домена test.ru добавить TXT-запись вида:
В данный момент мы поддерживаем отправку только агрегированных отчетов. Отправка образцов, которые не прошли проверку будет запущена позже.
Как выглядит отчет?
Ежедневные агрегированные отчеты приходят в формате XML с адреса dmarc_support@corp.mail.ru.
Ниже — пример отчета о том, что с одного IP-адреса было отправлено 20 писем, и все они прошли проверку.
Настройка DKIM/SPF/DMARC записей или защищаемся от спуфинга
1. DKIM
DKIM (DomainKeys Identified Mail) — это метод e-mail аутентификации, основанный на проверке подлинности цифровой подписи. Публичный ключ хранится TXT записи домена.
Зачем же он нужен?
DKIM необходим для того, чтобы почтовые сервисы могли проверять, является ли отправитель достоверным или нет. Т.е. защищает получателя письма от различных мошеннических писем (которые отправлены с подменой адреса отправителя).
Настройка DKIM подписи и DNS записей
Для это нам необходимо создать пару ключей:
Или можно воспользоваться онлайн-сервисом, чего я крайне не советую.
Далее необходимо указать путь с секретному ключу в файле конфигурации (для этого лучше почитать документацию) почтового сервера и публичный ключ в DNS.
Так же стоит прописать 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 записей
» — дополнительные проверки, «?» — нейтрально.
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»
В ней не предпринимаются никакие действия, кроме подготовки и отправки отчета.
ruf — отчеты писем, не прошедшие проверку DMARC. В остальном все так же, как и выше.
Эпилог
Мы научились настраивать DKIM/SPF/DMARC и противостоять спуфингу. К сожалению, это не гарантирует безопасность в случае взлома сервера или же отправки писем на серверы, не поддерживающие данные технологии. Благо, что популярные сервисы все же их поддерживают (а некоторые и являются инициаторами данных политик).
Эта статья — лишь инструкция по самостоятельной настройке записей, своего рода документация. Готовых примеров нет намеренно, ведь каждый сервер уникален и требует своей собственной конфигурации.
Полный синтаксис DKIM, DMARC и SPF
Не так давно прописывала записи DKIM, DMARC и SPF для своего домена. Это оказалось сложнее, чем я думала, потому что мне не удалось нигде найти полный синтаксис всех этих записей. Тогда вместе с Яной Лыновой мы собрали материал. Фактически, эта статья дополняет несколько статей с Хабра (внизу вы найдете ссылки).
Для того, чтобы прописать необходимые записи, нам нужен доступ к DNS. DNS расшифровывается как Domain Name System. Обычно доступ к DNS в компании имеют системные администраторы или, на крайний случай, программисты. Для них вы должны написать ТЗ, по которому они смогут добавить записи в DNS.
Итак, что же такое DKIM?
DKIM (Domain Keys Identified Mail) — это цифровая подпись, которая подтверждает подлинность отправителя и гарантирует целостность доставленного письма. Подпись добавляется в служебные заголовки письма и незаметна для пользователя. DKIM хранит 2 ключа шифрования — открытый и закрытый. С помощью закрытого ключа формируются заголовки для всей исходящей почты, а открытый ключ как раз добавляется в DNS записи в виде TXT файла.
Проверка DKIM происходит автоматически на стороне получателя. Если домен в письме не авторизован для отправки сообщений, то письмо может быть помечено подозрительным или помещено в спам, в зависимости от политики получателя.
Записей DKIM может быть несколько — например, если вы пользуетесь одновременно сервисом Mandrill и при этом отправляете письма через Gmail, у вас будет 2 записи DKIM с разными селекторами:
| Название записи | Формат | Содержание |
| для Mandrill (селектор — mandrill): mandrill._domainkey.ваш_домен. (в некоторых панелях управления можно указывать без вашего домена, зависит исключительно от вашего хостинга) | TXT | v=DKIM1; k=rsa; p=(сгенерированный публичный ключ) |
| для Gmail (селектор — google): google._domainkey.ваш_домен. | TXT | v=DKIM1; k=rsa; p=(сгенерированный публичный ключ) |
Синтаксис DKIM
«v» — версия DKIM, всегда принимает значение v=DKIM1;
«k» — тип ключа, всегда k=rsa;
«p» — публичный ключ, кодированный в base64.
Необязательные элементы:
«t=y» — режим тестирования. Нужно только для отслеживания результатов;
«t=s» — означает, что запись будет использована только для домена, к которому относится; не рекомендуется, если используются субдомены;
«h» — предпочитаемый hash-алгоритм, может принимать значения «h=sha1» и «h=sha256»;
«s» — тип сервиса, использующего DKIM. Принимает значения «s=email» (электронная почта) и «s=*» (все сервисы). По умолчанию «*»;
«;» — разделитель.
Помимо этого можно создать необязательную запись, которая подскажет, что делать с неподписанными письмами:
| Название записи | Формат | Содержание |
| _adsp._domainkey.ваш_домен. | TXT | dkim=all |
где «all» — отправка неподписанных сообщений запрещена; «discardable» — все неподписанные сообщения должны быть заблокированы на стороне получателя; «unknown» — отправка неподписанных сообщений разрешена (значение по умолчанию).
Обратите внимание, что некоторые хостинги не поддерживают доменные записи длиннее 255, а то и 200 символов. В таком случае нужно разбить строку переводом. Но у некоторых хостингов и это не работает, обратитесь в поддержку вашего хостинга, чтобы узнать это заранее.
Некоторые хостинги проставляют кавычки для всех записей самостоятельно, об этом тоже можно спросить у поддержки или проставить по аналогии с другими TXT-записями домена, если они присутствуют.
Проверить DKIM можно здесь.
SPF (Sender Policy Framework) — это подпись, содержащая информацию о серверах, которые могут отправлять почту с вашего домена. Наличие SPF снижает вероятность попадания вашего письма в спам.
Важно помнить, что SPF запись может быть только одна для одного домена. В рамках одной SPF может быть несколько записей (например, если письма отправляются с нескольких ESP — маловероятно, но все же, чуть позже будет пример). Для поддоменов нужны свои записи.
Синтаксис SPF
» — «мягкое» отклонение (письмо будет принято, но будет помечено как спам);
«?» — нейтральное отношение;
«mx» — включает в себя все адреса серверов, указанные в MXзаписях домена;
«ip4» — позволяет указать конкретный IP-адрес или сеть адресов;
«a» — IP-адрес в A-записи;
«include» — включает в себя хосты, разрешенные SPF-записью указанного домена;
«all» — все остальные сервера, не перечисленные в SPF-записи;
«ptr» — проверяет PTR-запись IP-адреса отправителя (разрешено отправлять всем IP-адресам, PTR-запись которых направлена на указанный домен) (не рекомендуется к использованию согласно RFC 7208);
«exists» — выполняется проверка работоспособности доменного имени;
«redirect» — указывает получателю, что нужно проверять SPF запись указанного домена, вместо текущего домена.
Так как запись должна быть всего одна, через include необходимо прописывать все возможные сервера, через которые вы отправляете письма.
Пример записи SPF, если вы пользуетесь одновременно сервисом Mandrill и при этом отправляете письма через Gmail (несколько записей в рамках одной SPF, как я упоминала ранее):
Проверить SPF можно здесь.
DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) — это подпись, которая позволяет принимающему серверу решить, что делать с письмом. DMARC использует DKIM и SPF. Если отправленное сообщение не прошло проверку DKIM и SPF, то оно не пройдет и DMARC. Если же сообщение успешно прошло хотя бы одну проверку (DKIM или SPF), то и проверку DMARC сообщение пройдет успешно. DMARC добавляется только после того, как настроены записи SPF и DKIM.
Пример записи DMARC (не имеет значения, какими сервисами для рассылки вы пользуетесь):
| Название записи | Формат | Содержание |
| _dmarc.ваш_домен. | TXT | v=DMARC1; p=reject; sp=reject; ruf=mailto:postmaster@your.tld; fo=1 |
Синтаксис DMARC
«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 через запятую без пробелов.
«ruf» — отчеты для писем, не прошедших проверку DMARC.
Тег «fo» служит для генерации отчетов, если один из механизмов сломается. «fo=0» (используется по умолчанию) — присылать отчет, если не пройден ни один этап аутентификации; «fo=1» — присылать отчет, если не пройден хотя бы один этап аутентификации; «fo=d» — присылать отчет, если не пройдена аутентификация DKIM; «fo=s» — присылать отчет, если не пройдена аутентификация SPF.
Запись DMARC может быть одна для домена и поддоменов, т.к. в ней можно явно указать действия для тега «sp». Если вам требуется специфическая запись для поддоменов, можно создать отдельную запись с наименованием «_dmarc.ваш_поддомен.ваш_домен.».
Проверить DMARC можно здесь.
Надеюсь, что эта статья помогла вам разобраться в синтаксисе записей, и теперь вы с легкостью сможете написать ТЗ для системного администратора или программиста на внесение этих записей в DNS.
Как попасть в Inbox: всё о DMARC
Рассказываем о протоколе DMARC (Domain-based Message Authentication Reporting and Conformance) — зачем он нужен, как настраивать, какие есть особенности в использовании и как читать отчёты. Это третья статья цикла о доставляемости, и в ней мы используем понятия предыдущих публикаций, поэтому перед чтением рекомендуем вспомнить про SPF и DKIM.
Что такое DMARC и зачем он нужен?
DMARC — один из механизмов защиты компании от фишинга с использованием имени её домена. Такая проблема актуальна для любого бренда, работающего с личными данными пользователей и платёжными аккаунтами, наиболее часто она касается банков, платёжных систем, сотовых операторов, социальных сетей, крупных интернет-магазинов. Смысл фишинговой атаки заключается в отправке мошеннического письма как бы от лица известной компании, фактически загружающей вирус на устройство пользователя или ведущего его на сайт, где будут украдены личные данные, — логины и пароли, данные кредитных карт, номера телефона. Сами письма маскируются под легальные рассылки, и важную роль тут играет использование основного домена атакуемой компании.
На примере ниже — скриншот фишингового письма, маскирующегося под рассылку от Сбербанка. Оно оформлено полностью корректно и использует почту отправителя fomin.s@sberbank.ru — что похоже на реальный корпоративный адрес сотрудника Сбербанка. В действительности при клике по ссылке юзера уводит на сайт, где скачивается zip-архив с вирусом.
Результат такой атаки — заражённые компьютеры пользователей, украденные личные данные и репутационный ущерб для компании, чьим именем домена пользуются мошенники.
Уберечься от такой рассылки Сбербанк мог, настроив политику reject для DMARC, — тогда почтовый провайдер отклонит фишинговое письмо ещё на этапе анализа на спам и письмо просто не попадёт в ящики пользователей.
Как это работает?
DMARC работает на основе протоколов аутентификации SPF и DKIM и проверяет корректность прохождения письмом проверок на SPF и DKIM, а также факт, что данные письма действительно были отправлены с доменов под контролем организации. Ключевые функции DMARC — проверка аутентификации и отправка отчётов.
По результатам проверки обновляется информация в отчётах:
DMARC позволяет отправителю указать, как поступать с письмом по результатам проверки. Это делается через указание политики DMARC, которая бывает трёх видов:
Если совсем кратко — то при использовании DMARC получатель может быть уверен, что письмо действительно отправлено именно с того емейла, который указан в поле From-email.
Синтаксис записи
DMARC имеет собственный синтаксис, который говорит почтовому провайдеру о необходимости проверки и определяет действия по её результатам. При этом есть два параметра, обязательных к использованию, для остальных будут использованы значения по умолчанию, если явно не указать ваши значения параметров.
На основе этих параметров мы получаем минимально рабочую запись:
Следующий блок параметров имеет значения по умолчанию, которые используются, если параметр явно не указан в записи DMARC:
Как итог, у вас может получиться следующая запись, если использовать все доступные параметры:
Как читать агрегированные отчёты?
Агрегированные отчёты дают информацию о том, какие емейлы прошли проверки по SPF, DKIM и DMARC, а какие нет. В этих отчётах нет информации о каждом конкретном письме, но есть возможность оценить весь поток писем, идущий от имени вашего домена. Каждый почтовый провайдер, который поддерживает DMARC, генерирует и отправляет свой собственный отчёт.
Отчёты отправляются на емейл, указанный вами в параметре rua=mailto:email@domain.com.
Сам отчёт состоит из нескольких стандартных блоков.
