Цель данной статьи: настроить бесплатный почтовый сервер 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.

С помощью DKIM-подписи получатель письма может удостовериться в том, что оно действительно пришло от предполагаемого отправителя.

Вы можете установить DKIM-подпись для писем, отправляемых с вашего домена: достаточно создать для вашего домена TXT-запись с публичным ключом подписи. Чтобы подписывать письма, которые вы отправляете не через серверы Яндекса, необходима также TXT-запись с секретным ключом. Настраивать её нужно на том сервере, с помощью которого производится отправление писем.

Если вы делегировали домен на Яндекс, DKIM-подпись с публичным ключом будет настроена автоматически. Вы можете просмотреть и отредактировать ее параметры в DNS-редакторе Почты для домена.

Значения публичного и приватного ключей можно получить с помощью (в интерфейсе доступен только публичный ключ). Управлять TXT-записями обычно можно на странице управления DNS на сайте компании, предоставляющей вам услуги DNS-хостинга.

    Получите TXT-запись с публичным ключом в Почте для домена:

    1. В правой колонке страницы найдите раздел Цифровая подпись DKIM и нажмите ссылку Показать содержимое записи . Этого раздела может не быть, если DKIM-подпись уже была настроена ранее. В этом случае публичный ключ можно увидеть в значении записи в DNS-редакторе.

      Запись состоит из трех частей:

      • Имя записи («mail._domainkey» ). В некоторых панелях управления нужно указывать полное имя поддомена, например, «mail._domainkey.yourdomain.tld».

        Параметры DKIM:

        V=DKIM1; k=rsa; t=s; p=MIGfMA0GCSEBtaCOteH4EBqJlKpe...

        Параметр p содержит публичный ключ DKIM.

        Указание на домен («DKIM key mail for yourdomain.tld» ).

    Скопируйте содержимое записи.

    Откройте страницу редактирования DNS в панели управления на сайте компании, предоставляющей вам услуги DNS-хостинга.

    Создайте TXT-запись со следующими значениями полей:

    • Имя - «mail._domainkey» . В некоторых панелях управления DNS для публичного ключа DKIM необходимо также указывать домен, например, «mail._domainkey.yourdomain.tld» .

      Значение - параметры DKIM с публичным ключом, полученные в Почте для домена.

      Например, «v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSEBtaCOteH4EBqJlKpe...» .

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

    Подождите, пока изменения в DNS вступят в силу. Этот процесс может длиться до 72 часов.

Инструкции по настройке DKIM-подписи у некоторых хостинг-провайдеров

reg.ru

RU-CENTER (nic.ru)

masterhost.ru

Домен на sweb.ru

Домен на majordomo.ru

Панель управления https://control.majordomo.ru/

Пару лет назад, я написала статью « Как сделать, чтобы письма не попадали в спам ящик ».

Вчера мы с коллегами настроили ещё один метод подтверждения писем, под названием DKIM. Его можно использовать вместе с SPF.

Authentication-Results: mxfront7.mail.yandex.net; spf=pass (mxfront7.mail.yandex..85.212.180 as permitted sender) smtp.mail=askme@сайт; dkim=pass header.i=@сайт

Разница в том, что SPF - подтверждает IP адрес отправителя. DKIM же ip-адрес не учитывает, но подтверждает факт того, что конкретно отправитель имеет секретный ключ, который можно проверить публичным ключом, указанным в днс-записи.

Яндекс, судя по всему, считает DKIM более приоритетным средством борьбы со спамом. См. статью « Цифровая подпись — Яндекс.Помощь: Почта ». По этой причине, только письма проверенные через DKIM получают красивенькую медальку рядом с адресом отправителя.

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

В случае же с SPF, процедура проверки сложнее, т.к. надо взять днс запись, из неё взять список разрешённых ip, и ссылки на другие spf записи, которые тоже надо рекурсивно обработать и т.п. Затем сверить ip отправителя с данным списком. В случае, когда письмо проходит через несколько серверов, желательно подписать их все.

А вот отправителю, наоборот, настроить у себя поддержку SPF на порядок проще, чем настроить DKIM. Как я уже писала , для настройки SPF достаточно создать запись:

сайт. IN TXT "v=spf1 a include:_spf.google.com ~all"

Эта строчка разрешает слать почту только с ip указанного в A-записи домена, и с серверов гугл.

Как настроить DKIM в службах для домена от Google

Всё подробно написано вот в этом мануале:
http://support.google.com/a/bin/answer.py?hl=ru&answer=174124
если вкратце, то

  1. Зайти на нужную страницу в панели владельца домена гугл
  2. Выбрать домен и получить код для вставки в днс
  3. Вставить нужный код в TXT запись поддомена. Например, у меня google2._domainkey.сайт
  4. Активировать
  5. Profit. Ваши письма, посланные из Gmail, теперь подписываются ключом домена.

Как настроить подпись писем с сервера, при отправке через PHP

Если вы отправляете письма в PHP через SMTP сервера гугла, то всё уже сделано. Гугл использует подпись при отправке через SMTP.

Если же вы отправляете почту функцией mail , то в системе необходимо установить пакет dkim-filter .

Yum install dkim-filter

Aptitude install dkim-filter

Затем сгенерировать ключ через dkim-genkey. Лентяи вроде нас, могут использовать его для всех доменов на сервере. Сгенерированный в файле.txt публичный ключ нужно добавить в днс записи доменов.

Пользователи линукса могут набрать команду # dig google2._domainkey.сайт TXT

Либо послать письмо на ящик в гугле или яндексе.

В гмайл, если нажать на стрелочку, будет видно что-то типа

Заключение

Хочу обратить внимание на ещё несколько пунктов.

Если вы используете возможность гмайла "Отправлять письма как:" , т.е. не отправлять их напрямую со своего ящика. То гмайл будет подписывать DKIM оригинальным ящиком отправителя, а не вашим доменом.

Если вы абсолютно уверены, что успешно настроили DKIM, то можете запретить другим серверам принимать письма с вашим доменом, но без подписи, добавив ADSP запись:

_adsp ._domainkey IN TXT "dkim=all"

Update

Я совсем забыла рассказать про то как присваивать доменные подписи конкретным email адресам. Дело в том что вы можете отправить почту с домена X, через почтовый сервер домена Y, а подписать его ключом домена Z. И это даже будет работать =). Настройка ключей происходит в файле /etc/mail/dkim-milter/keys/keypath . Здесь стоит обратить внимание на часть строк, задающую sender-pattern , она может содержать звёздочку, как часть или весь домен. В случае указания просто звёздочки, данным ключом и доменом будут подписываться все письма.

# sender-pattern:signing-domain:keypath # *:example.com:selector *@сайт :сайт:/etc/mail/dkim-milter/keys/default # тут всякие остальные домены, а ниже домен для подписи по-умолчанию. * :verytec.ru:/etc/mail/dkim-milter/keys/default

Внимательный читатель заметил, что путь к секретному ключу один на все домены. Это ничуть не мешает работе подписей.

Всего вам доброго =)

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

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

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