Цель данной статьи: настроить бесплатный почтовый сервер Hmailserver (Windows) так, чтобы письма отправляемые вашим сервером от имени вашего домена не попадали в СПАМ на других серверах, в том числе на MAIL.RU, YANDEX.RU и GMAIL.COM

Исходные данные

Имеется корпоративный домен вида domainname.tld и локальный почтовый сервер Hmailserver под Windows. С почтовых адресов домена ведется только деловая переписка, общее количество отправляемых писем не превышает 100 штук в сутки, массовые рассылки отсутствуют как класс.

В последнее время все больше и больше получателей стали жаловаться, что отправляемые нами письма у них попадают в СПАМ. При этом у пользователей MAIL.RU попадание в СПАМ было 100% вне зависимости от содержимого письма.

Официальное обращение в MAIL.RU

Я написал письмо в поддержку MAIL.RU. В ответе мне сообщили, что причиной блокировки писем является массовый спам, который отправляется от имени моего домена.

Ответ службы поддержки MAIL.RU

Необходимые условия

Для того, чтобы настроить SPF, DKIM и DMARC нам понадобиться доступ к NS серверам управляющими записями для вашего домена и доступ к Windows серверу на котором работает Hmailserver.

Как настроить SPF

Напомню, что SPF-запись указывает список серверов, которые имеют право отправлять письма от имени домена.

Чтобы настроить SPF необходимо добавить TXT запись для вашего домена. Для большинства доменов подойдет следующая универсальная запись:

Хост Тип Значение
domainname.tld TXT v=spf1 +a +mx -all
  • domainname.tld — имя вашего домена;
  • v=spf1 — обязательный параметр;
  • +a — разрешать письма от серверов указанных в A-записи;
  • +mx — разрешать письма от серверов указанных в MX-записи;
  • -all — блокировать письма с остальных серверов.

Опубликовав такую запись для своего домена вы даете четкие инструкции всем почтовым серверам в интернете как поступать с письмами с отправителями из вашего домена. Письма отправленные с серверов, IP адреса которых не указаны в записях A и MX, не являются легитимными и могут получателями трактоваться как SPAM письма.

Как настроить DKIM

DKIM-подпись позволяет получателю проверить, что письмо действительно было отправлено с заявленного домена. Для определения отправителя сообщения DKIM добавляет в него цифровую подпись, связанную с именем домена организации. Эта подпись автоматически проверяется на стороне получателя.

При этом используются пары публичных (открытых) и частых (закрытых) ключей шифрования. Открытый ключ указывается в соответствующей TXT записи домена и используется получателями при декодировании подписи, а закрытый ключ используется на стороне почтового сервера для шифрования подписи.

Таким образом, для настройки DKIM нужно сделать следующее:

  • Сгенерировать пару ключей;
  • Добавить открытый (публичный) ключ в TXT запись вашего домена;
  • Добавить закрытый (частный) ключ на почтовый сервер Hmailserver.

Генерация пары ключей

Самый простой способ сгенерировать пару необходимых нам ключей для DKIM — это воспользоваться сервисом https://port25.com/dkim-wizard/

Поле DomainKey Selector позволяет привязать к одному домену несколько DKIM записей для разных нужд, например если у вас несколько почтовых серверов. У меня только один почтовый сервер и в роли селектора я выбрал просто «mail». Нажмите кнопку и вы получите пару ключей.

Настройка DKIM в Hmailserver

Не забывайте указать Selector , который вы назначили при генерации ключа.

Настройка DKIM подписи домена

Добавьте подобную TXT запись для вашего домена:

Хост Тип Значение
mail._domainkey.domainname.tld TXT v=DKIM1; k=rsa; t=s; p=MIIBIjANBg
  • domainname.tld — имя вашего домена;
  • mail в имени хоста — селектор выбранный при генерации ключей и указанный в настройках Hmailserver;
  • p=MIIBIjANBg — открытый ключ.

Настройка политики DMARC

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

Привет! Недавно я проводил вебинар на тему E-mail-маркетинга и уловил нотки непонимания, когда речь зашла о DKIM и SPF. Это не удивительно, поскольку многие владельцы бизнесов и даже интернет-маркетологи ещё не слышали об этом феномене 😃 Но время идет, правила «игры» меняются и нам жизненно необходимо им соответствовать.

Постараюсь максимально просто и доступно объяснять, что такое DKIM/SPF и как их внедрять для корректной работы с E-mail-рассылками.

DKIM и SPF - это записи в DNS настройках вашего домена, которые почтовые сервисы используют для аутентификации ваших рассылок. Иными словами, при отправке письма Подписчику сервисы вроде Gmail/Mail/Яндекс производят проверку этого самого письма на подлинность. Подлинность подтверждается, если сервисы обнаруживают в настройках вашего домена соответствующую запись, включающую в себя электронную подпись.

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

На самом деле, ничего сложного в добавлении txt-записей и цифровой подписи в настройки домена нет.

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

У меня на хостинге все интуитивно понятно:
Домены → Управление доменами → Настройки → DNS → Новая DNS-запись

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

Настройка DKIM

DKIM — это DomainKeys Identified Mail

То есть, это и есть те самые ключи, которые нам нужны для аутентификации. Их можно создать самостоятельно, если рассылка производится через ваш сервер, либо (более частый и удобный вариант) взять в сервисе, которые используется для рассылок (например, Unisender или Mailchimp).

Вот такую запись нас просит создать Mailchimp, что мы и делаем, в моем случае, на хостинге


Unisender просит добавить две записи несколько иного содержания.

Domainkey TXT o=~ us._domainkey TXT k=rsa; p=XXXXXXXXXXXXXXXXXXXXX

Где XXXXXXXXXXXXXXXXXXXXX — это ваш уникальный ключ, которые генерируется в личном кабинете сервиса.

SPF – Sender Policy Framework, то есть проверка отправителя.

Это необходимо, поскольку при использовании SMTP в качестве отправителя можно указать любой адрес. SPF-запись позволяет внести адреса серверов, с которых разрешается отправка писем от Вашего имени. Таким образом, сервисы вроде Яндекс и Mail смогут понять санкционирована ли рассылка и исходит ли она от владельца домена.

Настраивается SPF также легко, путем добавления записей в DNS-домена.

Пример записи от MailChimp:
Идем в настройки и добавляем соответствующую запись в домене:

SPF в Unisender

Сервис для рассылок Юнисендер просит добавить 2 txt-записи в настройки домена

@ TXT v=spf1 include:spf.unisender.com ~all @ TXT spf2.0/mfrom,pra include:senderid.unisender.com ~all

где;
@ — это имя хоста (то есть при указании символа запись будет внесена на основной домен, в моем случае сайт)
TXT — это тип записи
Значение/Текст — само содержание записи

Внимание! Если у вы уже используется какой-то сервис для рассылок, то у вас, возможно, есть текстовая запись SPF с v=spf1 .
В таком случае, просто добавьте в конец этой записи (но перед выражением~all или -all ) значение

Include:spf.unisender.com (для Unisender) или include:servers.mcsv.net (для Mailchimp)

Поздравляю! Настройка завершена, теперь ждем от 24 до 48 часов, чтобы DNS обновились и проверяем аутентификацию в сервисе.

У меня время еще не прошло, поэтому я вижу ошибку 😃


Проверил через несколько часов и вуаля:


Сейчас пойду и сделаю первую рассылку с этой статьей по своей немногочисленной (пока еще) базе. Надеюсь, было полезно 🙂

В этой статье будет рассмотрена настройка цифровой подписи для Вашего домена.

Технология DomainKeys Identified Mail (DKIM) - это метод e-mail аутентификации: к отправленному письму добавляется заголовок DKIM-Signature , в котором содержится зашифрованная информация о домене отправителя. Таким образом, содержимое заголовка DKIM-Signature подтверждает отправителя письма. На стороне получателя подпись автоматически проверяется, после чего для определения репутации отправителя применяются "белые списки " и "черные списки ". После оценки репутации отправителя письма это письмо может быть принято, помещено в папку "Спам ", либо отправлено на дополнительную проверку.

Настройка DKIM при отправке рассылок через хостинг Beget

На хостинге Beget можно настроить DKIM-подпись для следующих способов отправки писем:

Для создания DKIM-подписи для писем, отправляемых средствами PHP mail() , потребуется выделенный IP-адрес - его стоимость составляет 660 руб./год, подключить можно из , в разделе . Далее для настройки DKIM-подписи необходимо написать тикет из раздела , указав в нём домен сайта.

Для создания DKIM-подписи для писем, отправляемых средствами SMTP , необходимо написать тикет из , раздел , указав в нём домен сайта. Настройка DKIM для SMTP возможна только на оплаченных аккаунтах (минимум на месяц по текущему тарифному плану). Настройка DKIM-подписи с нашей стороны возможна только в том случае, когда рассылки отправляются через наш хостинг и почта работает через нас, то есть, в качестве MX записи у домена, будут значения:

mx1.сайт mx2.сайт

Настройка DKIM при отправке рассылок через сторонний сервис (на примере unisender.com)

Рассмотрим внесение нужных записей на примере сервиса unisender.com . Для других сервисов рассылки инструкция будет похожей.

SPF-запись — проверка отправителя.

Как всем известно, протокол отправки электронной почты SMTP, подразумевает, что в качестве отправителя можно указать любой почтовый ящик. Таким образом можно послать письмо, подставив в поле «From» вымышленное значение. Процесс такого почтового обмана называется Спуфинг (e-mail spoofing). Чтобы бороться с этим явлением, был разработан и введен в действие стандарт SPF – Sender Policy Framework (структура политики отправителя).

SPF позволяет владельцу домена указать в TXT-записи домена специальным образом сформированную строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.

Рассмотрим простой пример SPF-записи:

example.org. IN TXT «v=spf1 +a +mx -all»

Теперь более детально о допустимых опциях. Рассмотрим варианты поведения получателя, в зависимости от используемых опций:

  • «v=spf1» — используемая версия SPF.
  • «+» — принимать корреспонденцию (Pass). Этот параметр установлен по умолчанию. Тоесть, если никаких параметров не установлено, то это «Pass»;
  • «-» — Отклонить (Fail);
  • «~» — «мягкое» отклонение (SoftFail). Письмо будет принято, но будет помечено как СПАМ;
  • «?» — нейтральное отношение;
  • «mx» — включает в себя все адреса серверов, указанные в MX-записях домена;
  • «ip4» — опция позволяет указать конкретный IP-адрес или сеть адресов;
  • «a» — указываем поведение в случае получения письма от конкретного домена;
  • «include» — включает в себя хосты, разрешенные SPF-записью указанного домена;
  • «all» — все остальные сервера, не перечисленные в SPF-записи.

Итак, попробуем разобраться, что же значит SPF-запись, указанная выше.

  • «+a» — разрешает прием писем от узла, IP-адрес которого совпадает с IP-адресом в A-записи для example.org;
  • «+mx» — разрешает прием писем, если отправляющий хост указан в одной из MX-записей для example.org;
  • «-all» — все сообщения, не прошедшие верификацию с использованием перечисленных механизмов, следует отвергать.

Для лучшего понимания того, как работает SPF, рассмотрим еще один, более сложный пример:

example.org. IN TXT «v=spf1 mx ip4:78.110.50.123 +a:mail.ht-systems.ru include:gmail.com ~all»

Теперь более подробно о используемых опциях...

  • «mx» — принимать письма от серверов, указанных в MX-записях;
  • «ip4:78.110.50.123» — принимать письма, отправленные с IP-адреса 78.110.50.123;
  • «+a:mail.ht-systems.ru» — то же, что и a:mail.ht-systems.ru. Принимать от mail.ht-systems.ru;
  • «include:gmail.com» — принимать письма с серверов, разрешенных SPF-записями gmail.com;
  • «~all» — принимать письма со всех остальных серверов, но помечать их как СПАМ

А теперь рассмотрим еще более «экзотичный» пример. В описании возможных опций указывалось, что возможно указание сетей ip-адресов. Стоит отметить, что это применимо и к записям «a» и «mx». Рассмотрим следующий пример:

example.org. IN TXT «v=spf1 mx/24 a:hts.ru/24 -all»

«mx/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и MX-ы домена;
«a:hts.ru/24» — в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и А-записи домена hts.ru;
«-all» — всех остальных отправителей — блокируем.

Иногда можно встретить следующие записи (очень редко):

«ptr» — проверяет PTR-запись IP-адреса отправителя. Если она сходится с указаным доменом, то механизм проверки выдает положительный результат. Тоесть, разрешено отправлять всем IP-адресам, PTR-запись которых направлены на указанный домен. Серьезным недостатком даного метода есть то, что генерируется очень большое количество DNS-запросов;
«exists» — выполняется проверка, резолвится ли домен на какой-либо IP-адрес. Тоесть, по существу, выполняется проверка работоспособности доменного имени. Кстати, не имеет значения, на какой IP-адрес резолвится домен, даже если это «серые» сети (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) или loopback (127.0.0.1).

Пример использования:

example.org. IN TXT «v=spf1 ptr:example.org exist:example.org -all»

Также не будет излишним ознакомиться со следующими опциями: redirect и exp.

«redirect» — указывает получателю, что нужно проверять SPF-запись указаного домена, вместо текущего домена. Пример:

example.org. IN TXT «v=spf1 redirect:example.com ~all»

В даном примере будет проводится проверка SPF-записи домена example.com, а не example.org.

«exp» — использование даной опции позволяет задать сообщение о ошибке, которое будет передано отправителю при возникновении таковой. Размещается в конце SPF-записи, даже после опции all. Рассмотрим более детально механизм работы опции exp.

Допустим, что у домена example.org следущая SPF-запись:

example.org. IN TXT «v=spf1 +a +mx -all exp=spf.example.org»

Теперь содаем TXT-запись для домена spf.example.org:

spf.example.org. IN TXT «You host not allowed e-mail to me»

В результате этих шаманских действий SPF-запись будет контролировать, чтобы почта доставлялась только от валидных хостов, а всем остальным будет отправляться сообщение о ошибке, прописанное в TXT-записи домена spf.example.org.

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

Приветствую, Хабр! В этой статье будет инструкция по настройке 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 //получаем публичный ключ из секретного
Или можно воспользоваться онлайн-сервисом, чего я крайне не советую.

Примером записей является
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 записей

Примером обычной SPF записи является your.tld. TXT "v=spf1 a mx ~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:[email protected]"
В ней не предпринимаются никакие действия, кроме подготовки и отправки отчета.

Теперь подробнее о тегах:
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:[email protected] , так же можно указать несколько email через пробел (rua=mailto:[email protected] mailto:[email protected])

Пример отчета

1.1.1.1 1 none your.tld your.tld pass your.tld pass 1.1.1.1 1 none forwarded your.tld your.tld pass your.tld pass


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

Эпилог

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

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

Буду рад конструктивной критике и правкам.