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

В наших прошлых материалах мы уже рассматривали настройку DNS-зоны для правильной работы почтового сервера, а также роль отдельных DNS-записей. Однако, как показывает практика, не все администраторы правильно понимают механизм работы систем электронной почты с DNS-записями. Поэтому мы решили посвятить этому вопросу отдельную статью, в которой разберем его более глубоко и расскажем о сравнительно новой технологии SPF.

Основная проблема современных почтовых систем — спам. Существует много разных методик борьбы с ним, но основная — анализ отправителя, учитывая что вся необходимая информация в письме имеется.

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

Допустим вы получили на почте крайне подозрительного вида посылку, якобы от любимого дедушки Константина Макаровича, но почему то штемпель отправителя указывает не на почтовое отделение села Макаровки, а на хутор Гадюкино совсем в другом конце страны. Будете вы открывать такую посылку, рискуя обнаружить вместо банки варенья из райских яблочек споры сибирской язвы, или отправите ее назад, от греха подальше?

Точно также и в системах электронной почты. Если вам пришло письмо от дедушки konstantin-makarovich@example.com, но сервер отправитель почему-то mail.spam.com, то это повод не принимать такое письмо, так как оно с большой долей вероятности является спамом.

Каким образом мы осуществили данную проверку? Очень просто, посмотрели на штемпель почтового отделения отправителя и сравнили его с обратным адресом. Например на конверте написано, что отправитель находится в городе Москва, однако на штемпеле отделения-отправителя стоит индекс 683000, который указывает на Петропавловск-Камчатский. Следовательно такое письмо мы принимать не будем, так как оно не прошло проверку отправителя.

Аналогично обстоит дело и с электронным письмом, только вместо индекса отделения-отправителя используется PTR-запись. Так получив письмо от дедушки, мы сделаем PTR-запрос и выясним, что сервер отправитель у нас mail.spam.com, в то время как согласно переданной при соединении информации должен быть mail.example.com. Все понятно, письмо падает в спам.

Однако если в заголовке будет указано, что сервер отправитель у нас mail.spam.com, то такое письмо успешно пройдет проверку по PTR-записи, не смотря на то, что домен сервера отправителя не совпадает с почтовым доменом письма.

Почему так происходит? Потому что проверка по PTR-записи позволяет определить лишь то, что сервер-отправитель действительно тот, за кого себя выдает. Но никоим образом не определяет подлинность самого отправителя. Т.е. обращаясь к примеру обычной почты мы проверяем лишь то, что обратный адрес и индекс отделения отправителя совпадают, если место отправления Москва, а индекс указывает на Петропавловк-Камчатский, то проверку по PTR такое письмо не прошло, а если место отправления и индекс совпадают, то все нормально и теперь уже ваша задача думать, что делает ваш любимый дедушка в Петропавловске-Камчатском.

Непонимание этого момента приводит к тому, что PTR-запись оказывается настроена неправильно и, как результат, большая часть отправляемой почты не доходит до адресата. Особенно важно это понимать при настройке серверов обслуживающих несколько доменов. В этом случае PTR-запись должна указывать на имя почтового хоста (которое он передает в рамках SMTP-сессии), даже если он расположен в другом домене.

Разберем простой пример.

Сервер mail.example.com отправляет письмо для обслуживаемого им домена eхample.org. Сервер-получатель делает запрос PTR-записи и убеждается, что по адресу 123.123.123.123 действительно находится mail.example.com, следовательно такое письмо будет принято, хотя домен отправителя письма и домен сервера-отправителя не совпадают.

А теперь иная ситуация.

Администратор неправильно настроил DNS-зону, указав неправильный хост в PTR-записи. Cервер-получатель, проверив PTR-запись отклонит наше письмо, так как сервер отправитель не совпадает с результатом обратного DNS-запроса.

Отсутствие PTR-записи практически всегда ведет к отклонению письма, потому как существует негласное соглашение о том, что добросовестный отправитель имеет правильно настроенную обратную зону.

Вернемся к нашему дедушке. Допустим он сообщил вам, что летом собирается выезжать из села Макаровки в соседнее село Ивановка, к некой Марфе Васильевне и намерен оттуда посылать вам корреспонденцию. В таком случае вы без опаски будете принимать письма от дедушки как из Макаровки, так и из Ивановки, но откажетесь от якобы дедушкина письма из Петропавловска-Камчатского.

Подобная технология в системах электронной почты реализуется с помощью технологии SPF. Если коротко, то данная технология позволяет создать специальную DNS-запись, которая будет указывать, кто именно имеет право отправлять почту от имени вашего домена. В самом простом варианте запись будет иметь вид:

example.com. IN TXT "v=spf1 +a +mx -all"

Что она означает? То, что для домена example.сom почту могут отправлять узлы указанные в А-записи (+а) и MX-записях (+mx), всю остальную почту следует отклонять (-all).

Однако не все так радужно. Во первых, поддержка SPF все еще не является стандартом де-факто и отсутвие SPF-записи у домена отправителя не повод отклонять письмо. Вторая проблема — сервера пересылки или случаи когда почту отправляют сервера не указанные в А или MX записях, а то и вообще находящиеся в других доменах. Это может быть обусловлено как архитектурой IT-системы предприятия, так и использованием для отправки чужих серверов, когда вы привязываете свой домен к провайдерскому или публичному сервису. В последнем случае нужно быть особо осторожным и крайне желательно проконсультироваться с поддержкой сервиса.

Рассмотрим еще одну ситуацию.

Ваша компания, кроме своего основного почтового сервера mail.example.com, использует услуги сторонних сервисов, которые могут отправлять почту клиентам компании от ее имени. Это может быть сервис экспресс-почты, который от вашего имени будет уведомлять клиентов о статусе доставки и т.п.

В нашем примере такая почта будет отправляться от имени zakaz@example.com с сервера mail.web-service.com, так как данный сервер не указан в MX-записях домена example.com, то, согласно указанному нами в SPF-записи правилу, такое письмо будет получателем отклонено.

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

example.org. IN TXT "v=spf1 +a +mx ~all"

В отличие от -all (fail), ~all (soft fail) обозначает, что отправители, кроме указанных явно, не имеют права отправлять почту, но не содержит требования отклонять такие письма. Чаще всего такая почта принимается, помечаясь как нежелательная.

Можно также использовать нейтральный префикс:

example.org. IN TXT "v=spf1 +a +mx ?all"

В этом случае правило сообщает о том, что отправлять почту от имени нашего домена имеют право хосты указанные в A- и MX- записях, насчет остальных узлов никакой информации нет. Прием почты с явно не разрешенных узлов производится на усмотрение сервера-получателя, чаще всего такая почта будет принята без каких либо пометок.

Как быть в нашем случае? Самым правильным решением будет добавить в SPF-запись еще одно правило:

example.org. IN TXT "v=spf1 +a +mx +mx:web-service.com -all"

или

example.org. IN TXT "v=spf1 +a +mx +a:mail.web-service.com -all"

в первом случае мы разрешим прием почты также от всех серверов, перечисленных в MX-записях домена web-service.com, во втором случае только для сервера mail.web-service.com.

В завершение рассмотрим случай, когда почта для вашего домена обслуживается сервером находящимся в другом домене. Например mail.example.com отправляет также почту для домена example.org. В этой ситуации будет правильно использовать для домена example.org те же самые правила, что и для example.com. Для этого используйте специальный вид записи:

example.org. IN TXT "v=spf1 redirect=example.com"

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

Чем мы можем помочь?ДоменыРегистрация доменовSPF-запись нужна для указания списка серверов, которые имеют право на отправку писем от имени email-адресов этого домена. Она используется для защиты от спама и фишинговых сообщений от имени вашего домена.Какой вид должна иметь SPF-запись? В записи необходимо перечислить все сервера, которые могут отправлять электронную почту. В этот список могут входить сервер сайта, сервера, обслуживающие ваши почтовые ящики, и другие, если вы отправляете с них почту.

В этом примере:

v=spf1 — определяет версию используемой записи SPF, параметр обязателен;include:_spf.majordomo.ru — включает в запись SPF значение SPF записи другого домена. То есть для домена будут действовать в том числе все значения записи SPF для домена «_spf.majordomo.ru»;ip4:185.84.108.14 — разрешает приём почты с IP-адреса 185.84.108.14;a — разрешает приём почты с сервера, IP-адрес которого указан в ресурсной A-записи домена. Проще говоря с сервера, где расположен сайт. Обратите внимание, что, если вы используете различные реверс-прокси, например, CloudFlare, ip-адрес сервера, где расположен сайт и ip-адрес в A-записи не будут совпадать;mx — разрешает прием почты, если отправляющий сервер указан в одной из MX-записей домена;~all — если письмо пришло с сервера, который не входит в вышеперечисленный список, его стоит проанализировать более тщательно. Также иногда используется -all — в этом случае письмо не проходит дополнительных проверок и сразу отвергается. После проверки работы почты для всех серверов и отсутствия отчетов, что письмо не прошло соответствующую проверку, следует указать -all для блокировки писем со всех остальных серверов.

Была ли статья вам полезна? Да Нет

Ещё остались вопросы?

Просто напишите на support@majordomo.ru и мы ответим Вам в течение двух часов. Приветствую, Хабр! В этой статье будет инструкция по настройке DKIM/SPF/DMARC записей. А побудило меня написать эту статью полное отсутствие документации на русском языке. Все статьи на эту тему, которые были мной найдены, были крайне не информативны.

1. DKIM

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

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

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

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

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

openssl genrsa -out private.pem 1024 //генерируем секретный ключ длинной 1024

openssl rsa -pubout -in private.pem -out public.pem //получаем публичный ключ из секретного

Или можно воспользоваться онлайн-сервисом, чего я крайне не советую. Далее необходимо указать путь с секретному ключу в файле конфигурации (для этого лучше почитать документацию) почтового сервера и публичный ключ в 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=sha256s — Тип сервиса, использующего 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 записей

Примером обычной SPF записи является your.tld. TXT "v=spf1 a mx ~all" Здесь:v=spf1 является версией, всегда spf1a — разрешает отправляет письма с адреса, который указан в A иили AAAA записи домена отправителяmx — разрешает отправлять письма c адреса, который указан в mx записи домена (для a и mx можно указать и другой домен, например, при значении a:example.com, будет разрешена а запись не домена отправителя, а example.com) Так же можно добавлять и отдельные ip адреса, используя ip4: и ip6:. Например, ip4:1.1.1.1ip6: 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 отвечает за субдомены и принимает такие же значения, как и paspf и 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)Пример отчета

<record><row>  1.1.1.1  <count>1</count><policy>sition>none    </policy></row><identities>

</identities><auth><dkim><domain>ld</domain><result>pass</result><human></dkim><domain>your.tld</domain><result>pass</result></auth></record><record><row> 1.1.1.1 <count>1</count><policy><dispoone><reason><type>forwarded</type></reason></dispoone></policy></row><identities>

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

Эпилог

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

• https://interface31.ru/tech_it/2013/10/pochtovyy-server-dlya-nachinayushhih-ptr-i-spf-zapisi-kak-sredstvo-bor-by-so-spamom.html
• https://www.majordomo.ru/help/instructions/config-spf
• https://habr.com/post/322616/