DKIM — это просто
Хочу поделиться своим небольшим опытом прикручивания DKIM (DomainKeys Identified Mail) к своему домену и почтовому серверу.
DomainKeys Identified Mail метод E-mail аутентификации.
Технология DomainKeys Identified Mail (DKIM) объединяет несколько существующих методов антифишинга и антиспама с целью повышения качества классификации и идентификации легитимной электронной почты. Вместо традиционного IP-адреса, для определения отправителя сообщения DKIM добавляет в него цифровую подпись, связанную с именем домена организации. Подпись автоматически проверяется на стороне получателя, после чего, для определения репутации отправителя, применяются «белые списки» и «чёрные списки».
В технологии DomainKeys для аутентификации отправителей используются доменные имена. DomainKeys использует существующую систему доменных имен (DNS) для передачи открытых ключей шифрования.
Теперь необходимо найти, как сформировать пару секретного и публичного ключа. После перебора нескольких вариантов я остановился на web-утилите сервиса port25.com которая, кроме формирования необходимых ключей, так же генерирует и подсказку по DNS записям:
www.port25.com/support/support_dkwz.php
Небольшое пояснение по поводу некого поля «domain selector». Данное поле позволяет привязать к одному домену несколько DKIM записей для разных нужд (например для разных почтовых серверов). В моём случае у меня только один почтовый сервер и у меня нет необходимости в селекторе, так что в роли селектора я выбрал просто «mail».
Полученный приватный ключ сохраняем на сервер в папку, к которой имеет доступ почтовый сервер. Публичный ключ в принципе можно не сохранять в виде файла. Он нам пригодится только для внесения необходимой записи в DNS. В конфигурации домена в hMailServer нам необходимо указать путь к приватному файлу ключа, а так же указать выбранный селектор (напомню, я в виде селектора взял «mail»).
В файле DNS-зоны нам необходимо указать записи вида:
;»
mail._domainkey.example.com. TXT «k=rsa\; t=s\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQmO9AuWRbWPgl/jzDPQodrLfFLFqYYi6bCBnsTOCOJQrFbGgiR1C01j4zLw8XgG3rQ0WAaeg6Z/y39Ah7IONfs5gQuK6eGZMmYwIsZyz2dQoUDmDLCb1WygpkrqsCbyPw3SWGihM4iChOwo7Ovo2mTOWOf5ejeZcP2qqNb9nRMQIDAQAB»
Где «mail» перед _domainkey во второй записи — это не что иное, как наш выбранный селектор, а длинный набор символов в той же записи идущий после «p=» — это наш публичный ключ.
Вроде бы всё. Теперь попробуем отправить письмо с нашего почтового сервера на почту gmail, так как доподлинно известно, что gmail проверяет DKIM. Смотрим в полученное письмо в gmail и видим заветные строки:
Authentication-Results: mx.google.com; spf=pass (google.com: domain of example@example.com designates 123.123.123.123 as permitted sender) smtp.mail=example@example.com; dkim=pass header.i=@example.com
Поздравляем меня с успешным покорением DKIM ))), чего и вам желаю. Удачи.
UPD: Для получения пары ключей без использования внешних сервисов можно воспользоваться OpenSSL:
Спасибо lorc за дополнение.
UPD 2: Небольшое дополнение от nshopik:
Так же можно у домена прописать ADSP запись (RFC5617) — это позволит принимающему серверу понять, должно ли ваше письмо быть подписано или нет.
Запись выгладит таким образом:
_adsp._domainkey.example.com. TXT «dkim=all»
Полный синтаксис 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.
Что такое DKIM подпись: все, что нужно о ней знать
Что значит DKIM – подпись?
Внешне DKIM подпись выглядит так:
В этом рандомном (на первый взгляд) наборе цифр, букв и математических знаков скрыт тайный смысл, который разшифровывается следующим образом:
Зачем нужна DKIM подпись?
DKIM защищает от интернет-преступлений
На уровне почтового сервера заменить адрес отправителя – проще пареной репы. Этим часто промышляют мошенники. Выдав себя за компанию с хорошей репутацией, они прикарманивают личные данные и деньги пользователей. Этот процесс называется фишингом, и считается популярным видом интернет-преступления.
DKIM улучшает репутацию домена
Уровень доверия к отправителю влияет на Open Rate. Open Rate влияет на репутацию домена. Настроенный DKIM репутацию домен «обеляет».
По подписи сервер-получатель определяет не только подлинность, но и его общий рейтинг отправителя. Если подписи нет – кредит лояльности к домену уменьшается, как и вероятность доставки сообщения.
Скрывает домен отправителя (при использовании email сервисов для рассылок)
Визуально это выглядит следующим образом:
Эта опция дополнительная, но выгодная для интернет-магазинов. «Палиться», что каждое индивидуальное предложение создано автоматически в рамках массовой рассылки через email сервис не хочется. DKIM подпись в этом случае выручает 🙂
Как работает DKIM?
Условно, сфера влияния DKIM делится на 2 части: то, что происходит на сервере-отправителе, и то, что происходит на сервере-получателе. Всем процессом заправляют приватный и публичный ключ.
Приватный ключ (private key) – секретный уникальный код, который хранится под семью печатями на сервере или под надзором email сервиса.
Этап #1: на сервере-отправителе.
При отправке каждое сообщение подписывается цифровой подписью, используя ваш приватный ключ DKIM. Он прячется в заголовке письма, и выглядит примерно так (см.пункт «Подписан» на рисунке). В графе должно находиться имя домена-отправителя: по нему происходит идентификация.
Этап #2: на сервере-получателе.
Затем делает запрос в своеобразную библиотеку доменных имен – DNS: подлинный ли домен отправителя?
Ответ положительный – email не меняется и идет дальше в почтовый ящик получателя. Если нет – отправляется в СПАМ.
Как настроить DKIM подпись?
Каждый сервис рассылок имеет свою процедуру настройки DKIM подписи. Обычно их можно найти в инструкциях, справочниках или мануалах. В Estismail, к примеру, это “Настройка DKIM записи на домене”. Если у вас возникают вопросы – спрашивайте в службы поддержки.
Как проверить DKIM?
Почтовые сервисы делают проверку DKIM незаметно для пользователя. Некоторые же, не скрывают работу в этом направлении: Google подтверждает надежность отправителя знаком ключа возле адреса:
Включить поддержку этой функции можно в Настройки (Settings)→ Лаборатория (Labs)→ «Значок проверенного сообщения» (Authentication icon for verified senders).
Как попасть в Inbox: технология DKIM
В цикле статей «Как попасть в Inbox» рассказываем о SPF-записи, протоколе DMARC, чёрных списках, тактиках прогрева и многом другом. Эта статья цикла посвящена DKIM‑технологии. Рассказываем, как она работает, зачем её использовать и как настраивать.
Что такое DKIM
DKIM — это технология, объединяющая несколько существующих методов антифишинга и антиспама с целью повышения качества классификации и идентификации легитимной электронной почты.
Проще говоря, DKIM, на ряду с SPF, является ещё одним методом емейл-аутентификации.
Принцип работы
Принцип работы базируется на двух ключах: публичном и приватном. Публичный ключ размещается в DNS‑записи в txt-поле. Приватный ключ размещается на стороне отправляющего сервера. В заголовки каждого отправляемого емейла с помощью приватного ключа в зашифрованном виде добавляются: тело письма, служебные заголовки, время отправки и другие параметры.
Почтовый провайдер обращается к домену отправителя сразу, как только получит подписанное емейл‑сообщение. С помощью публичного ключа расшифровывает заголовок и проверяет соответствие письма и информации в заголовке.
Зачем нужен DKIM
Наличие подписи в массовых емейл-рассылках является обязательным для большинства почтовых провайдеров. Она идентифицирует отправителя, и ISP считает его добросовестным. DKIM в совокупности с SPF-записью делает фишинг-атаки намного более сложными.
Как создать ключи
Пару ключей можно сгенерировать с помощью онлайн-сервисов, например, DKIM Core.
Либо без использования сторонних сервисов — с помощью OpenSSL:
Структура DKIM-заголовка
Заголовок, добавляемый сервером-отправителем, называется DKIM-Signature. Он состоит из списка тегов вида «тег=значение».
Основные теги и их значения:
Таким образом, получив письмо с заголовком из примера, почтовый провайдер обратится к DNS-записи expertsender1k._domainkey.news.emailmatrix.ru для получения публичного ключа. Содержимое данной записи следующее:
Как настроить
В большинстве платформ для емейл-рассылок настройки подписи включены по умолчанию, в таком случае технически рассылки ведутся от имени сервиса рассылок. Для крупных кампаний рекомендуется вести рассылки от имени своего домена для формирования репутации и снижения возможности фишинговых атак.
Крупные ESP предоставляют возможность настройки подписи для вашего домена. В некоторых это является стандартной процедурой при открытии аккаунта, в некоторых дополнительной опцией. В обоих случаях платформа предоставляет сгенерированный публичный ключ, который необходимо разместить в DNS‑записи. После чего подпись писем настроится автоматически.
Если вы используете собственную платформу для рассылок, то воспользуйтесь дополнительными средствами для настройки подписи писем.
Как проверить настройку
После того как настройка подписи произведена и добавлена DNS-запись с ключом, проверим доступность публичного ключа. Сделать это можно известным нам www.dnswatch.info.
Для этого после перехода на сайт введите адрес по следующей структуре — *селектор*._domainkey.*рассылающий домен* и выберите тип записи TXT.
Если содержимое данной записи отображается верно, приступайте к живому тесту подписи, а именно к отправке тестового письма. Рассмотрим на примере веб-интерфейса Mail.ru.
Получив тестовое емейл-сообщение, открываем его. В меню ищем пункт «Служебные заголовки».
Открыв его, вы увидите все служебные заголовки письма. Среди них будет DKIM-Signature.
Немного выше над ним в блоке Authentication-Results при успешной проверке должна быть строка dkim=pass:
Если вместо значения pass там будет fail, проверьте правильность ключей.
Что будет, если не настроить DKIM
Наличие настроенного DKIM является обязательным требованием большинства почтовых провайдеров.
Несмотря на это, емейл-сообщения, не подписанные DKIM, могут быть доставлены, но придут они в папку «Спам». Поэтому не стоит игнорировать данное требование, тем более что, единожды настроив его, вы также обезопасите себя и своих подписчиков от действий злоумышленников.
Кроме того, на основе DKIM работает протокол DMARC, о котором рассказали в одной из статей цикла.
Настройка 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 и противостоять спуфингу. К сожалению, это не гарантирует безопасность в случае взлома сервера или же отправки писем на серверы, не поддерживающие данные технологии. Благо, что популярные сервисы все же их поддерживают (а некоторые и являются инициаторами данных политик).
Эта статья — лишь инструкция по самостоятельной настройке записей, своего рода документация. Готовых примеров нет намеренно, ведь каждый сервер уникален и требует своей собственной конфигурации.
