Как самому настроить SPF-запись?

Установка своего почтового сервера, как правило, не вызывает особых трудностей. В Сети доступно большое количество готовых инструкций. Буквально одна команда, и 25-й порт уже готов к работе. Весело становится, когда отправленные письма начинают возвращаться, а получатели жаловаться, что сообщения не доходят. Здесь уже хочешь не хочешь, но придется искать причины и вникать в технологии.

Используемые термины: DKIM, DNS, SPF, DMARC, FreeBSD, Ubuntu, CentOS.

Все примеры по настройке DKIM в данной инструкции выполнены на базе систем FreeBSD, Ubuntu / Debian / Astra Linux и Rocky Linux / CentOS / Red Hat.

Устанавливаем opendkim
Настраиваем OpenDKIM и Postfix
Создаем сертификат для первого домена и настраиваем его
Настраиваем DNS
Проверяем настройку
Настройка дополнительных записей для новых доменов
Что еще можно настроить для почты
Диагностика ошибок

SPF-запись выглядит, например, так:

v=spf1 ip4:176.57.223.0/24 -all

где v — версия SPF, всегда принимает значение v=SPF1;

Данная SPF-запись простая и весьма строгая. Она разрешает отправку писем только с указанного IP. Все остальные письма должны быть заблокированы, так как указан механизм «-all».

В этой статье мы поможем разобраться в настройках цифровой подписи для вашего домена, чтобы письма были доставлены и не попали в «Спам». 

Технология DKIM — это метод e-mail аутентификации. Заголовок DKIM-Signature прикрепляется к письму, в DKIM зашифрована информация о домене отправителя. Так DKIM-Signature подтверждает его.

На стороне получателя система проверяет подпись и определяет репутацию отправителя. После этого письмо или доставляется, или отправляется в «Спам» / на дополнительную проверку. Бывает и такое, что сервер получателя сам отклоняет письмо.

Содержание статьи

Электронная почта — один из самых популярных каналов распространения спама, малвари и фишинговых ссылок. Существует куча софта, который защищает почтовые серверы от этих напастей, да вот незадача: большинство таких программ стоит денег, и порой немалых. В этой статье я расскажу, как усилить безопасность корпоративных почтовых серверов (MS Exchange и Postfix) с помощью доступных штатных средств — DKIM-, SPF- и DMARC-записей, не требующих использования дорогостоящих коммерческих продуктов.

Разбираемся с SPF

Несмотря на то что для SPF придуман отдельный тип записи, он так и остался опциональным (при наличии поля его лучше тоже создать, хуже не будет), TXT обязательна.

example.org TXT "v=spf1 a mx ip4:1.2.3.4 ~all"

Если домен может отправлять почту с нескольких адресов, все их прописываем здесь или указываем в MX-записи. Если VDS имеет IPv6-адрес, обязательно прописываем его здесь в ipv6:. Расшифруем:

• v=spf1 — используемая версия SPF;
• a — прием писем от узла с IP-адресом, указанным в A-записи домена;
• mx — подключает адреса, указанные в MX-записях;
• all — что делать с серверами, не перечисленными в SPF. Причем все указанное после all проверяться не будет, оно должно стоять последним.

Если ip4:1.2.3.4 есть в MX или A, его можно явно не прописывать и сократить запись до v=spf1 mx ~all. Можно подключать другие домены. Например, a:smtp.example.org разрешит сообщения с этого домена. Еще вариант — использовать параметр include, подключающий хосты, разрешенные SPF-записью указанного домена (например, include:_spf.yandex.net). Почти аналогичный параметр redirect перенаправляет проверку SPF на другой домен. Например, redirect:example.com. Администратор устанавливает политику SPF для домена:

• None — означает, что в этом домене нет опубликованных SPF-записей, поэтому определить разрешения невозможно;
• Neutral (?) — владелец домена явно указал, что он не хочет устанавливать разрешения, обрабатывается аналогично None и служит больше для информационных целей;
• Pass (+) — прошедшему проверку разрешено отсылать сообщения. Установлен по умолчанию;
• Fail (-) — клиент не уполномочен отсылать почту из этого домена, и принимающая сторона вправе пометить такое сообщение или отвергнуть. Например, v=spf1 -all указывает, что домен вообще не отправляет почту;
• SoftFail (~) — отправитель не имеет права посылать сообщение, но принимающая сторона должна не отвергать сообщение, а провести дальнейшую проверку.

Fail и SoftFail обычно используются в all. То есть при -all все сообщения, не попадающие под правила, следует однозначно отвергать.

Проверить SPF-запись можно при помощи онлайн-сервисов SPF Record Testing Tools, mxtoolbox.com или утилиты spfquery.

$ apt install spfquery
$ spfquery -ip=1.2.3.4 -sender=mail@example.org -helo=example.org

В 2004 году в MS предложили схожую с SPF технологию, названную Sender ID и использующую DNS-записи spf2.0/pra, или spf2.0/mfrom, или spf2.0/mfrom,pra. Проверяется MAIL FROM, а не адрес возврата. Технология в настоящее время не получила широкого распространения, и MS рекомендует при отсутствии явных записей spf2.0 рассматривать v=spf1 как эквивалент spf2.0/mfrom,pra и использовать его при анализе. Вот, собственно, и все, что нужно о ней знать.

В принципе, если выполнить все рекомендации, можно уже смело отправлять письма, застревать они не должны. Но некоторые сервисы требуют обязательного подписывания сообщений.

Настраиваем DKIM

В основу DKIM (DomainKeys Identified Mail) легли две разработки — технология DomainKeys от Yahoo и система Internet Identified Mail от Cisco. Новый проект был подан на утверждение в качестве стандарта IETF в 2005 году. Принцип DKIM очень прост. Каждое сообщение снабжается цифровой подписью, которая удостоверяет отправителя и гарантирует, что подписанная часть не изменялась. Сам процесс напоминает работу любой системы с открытым ключом. Владелец домена создает пару ключей — открытый и приватный. Приватный используется на SMTP-сервере для подписи сообщения, которая передается в заголовке DKIM-Signature. Домен указывается в поле d=, список подписанных заголовков перечисляется в ключе h:

h=From:Subject:Reply-To:List-Unsubscribe:To:Message-Id:Date:MIME-Version:Content-Type; i=info@example.org;

Открытый ключ добавляется в TXT-поле DNS-записи и при поступлении письма запрашивается получателем, который проверяет, действительно ли подпись была сгенерирована для домена, указанного в адресе отправителя. При положительном результате в сообщении появляется подзаголовок Authentication-Results: dkim=pass.

Если принимающая сторона не умеет проверять подпись, то на прохождении сообщения это никак не сказывается. Также нужно отметить, что правильный DKIM обычно не служит для антиспам-систем указанием на дальнейшее прохождение проверок. Но по опыту его наличие обычно поднимает его рейтинг насколько, что он редко застревает в фильтрах. Некоторые сервисы вроде postmaster.mail.ru требуют обязательного наличия подписанных DKIM-сообщений в привязанном домене, иначе статистика показываться не будет.

DKIM подписывают сообщения основные почтовые сервисы, и если привязать домен к Яндексу или Google, выполнив все инструкции, то больше ничего делать не нужно. Яндекс подключает DKIM обычно не сразу, а через день-два.

Настроим Postfix, чтобы он подписывал сообщения. Будем считать, что он установлен и сконфигурирован. Далее нам понадобится пакет OpenDKIM.

$ sudo apt install opendkim opendkim-tools

Демон будет работать с правами opendkim:opendkim. Генерируем ключи для селектора mail.

$ sudo mkdir -p /etc/mail/example.org
$ cd /etc/mail/example.org
$ sudo opendkim-genkey -s mail -d example.org

В текущем каталоге появятся два файла: mail.private — закрытый ключ и mail.txt — открытый. Добавляем в DNS-запись типа TXT из mail.txt.

mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS....ViwIDAQAB"

Domain example.org
KeyFile /etc/mail/example.org/mail.private
Selector mail
# По умолчанию подпись только проверяется, нужно изменить на sv (signer, verifier)
Mode sv

После установки демон opendkim слушает сокет /var/run/opendkim/opendkim.sock, но при необходимости можно указать сетевой порт и интерфейс. После правки файла перезапускаем демон:

$ sudo service opendkim restart

Добавляем в /etc/postfix/main.cf данные сокета:

milter_default_action = accept
milter_protocol = 2
smtpd_milters = /var/run/opendkim/opendkim.sock
non_smtpd_milters = /var/run/opendkim/opendkim.sock
$ sudo service postfix restart

Коротко это все настройки.

Проверить DKIM можно с помощью утилиты opendkim-testkey:

$ opendkim-testkey -d example.org -s mail -vvv

Мир быстро меняется, VDS переносятся на другой IP. Но антиспам-технологии, в частности SPF и DKIM, не совсем четко указывают, что делать при несоответствии правилам, например письмо проходит только DKIM или только SPF. Кроме того, владелец домена не знает, если с его адресов происходит рассылка. Эти проблемы призвана решить технология DMARC (Domain-based Message Authentication, Reporting, and Conformance, описана в RFC 7489), указывающая, как проверять почту домена. DMARC тоже прописывается в виде DNS-записи. Обязательны поля v (версия) и p (политика). Как минимум можно собирать статистику по неправильным сообщениям:

_dmarc.example.org TXT "v=DMARC1; p=none; rua=mailto:mail@example.org"

Доступны три варианта политик:

• none — без рекомендаций, регистрировать сообщения, не прошедшие проверку (отчет отсылается по адресу, указанному в rua);
• quarantine — помечать как спам;
• reject — отклонить сообщение.

Собственно, в указанном примере и вся суть DMARC. Остальные параметры доступны в RFC.

Практика и еще раз практика

В практической части мы рассмотрим конфигурирование описанных выше настроек безопасности на примере двух наиболее популярных почтовых серверов — опенсорсного Postfix на Debian (ну, или Ubuntu Server) и проприетарного Microsoft Exchange Server 2013+. Предполагается, что почтовые серверы у тебя уже установлены и настроены под твой домен, поэтому рассматривать будем только само конфигурирование фич на обезличенных данных.

Настраиваем SPF, DKIM и DMARC на Postfix (Debian)

Общий принцип работы нашего почтового сервера будет таков:

1. Принимающий сервер получает письмо с адреса info@example.com, отправленное с сервера mx.example.com.
2. Сервер получателя делает запрос к DNS для домена example.com и ищет записи SPF и DKIM.
3. В случае если записей нет, письму проставляется статус neutral (конкретно по этим проверкам) и письмо проверяется дополнительными фильтрами.
4. В случае если записи обнаружены, проверяется, разрешено ли серверу mx.example.com отправлять почту домена example.com.
5. Если домен mx.example.com не найден в списке разрешенных, то или письмо отбрасывается, или ему устанавливается статус neutral.
6. Если домен mx.example.com таки найден в списке разрешенных, письму устанавливается статус Pass и повышается его рейтинг при прохождении других фильтров.

Ну что, погнали!

Механизмы SPF-записи

Любая SPF-запись начинается с v=spf1, это значение не меняется.

Далее указываются параметры, или механизмы. Чаще всего используют следующие: all, ip4, ip6, a, mx, include, redirect.

Параметры «ip4/ip6» указывают конкретные адреса, с которых можно отправлять письма. Параметр «a» проверяет A-запись домена, «mx» — МХ-запись  домена.

Механизмы include, redirect позволяют применять настройки SPF другого домена. Их используют компании, у которых несколько доменов и почтовых серверов. Тогда можно прописать настройки SPF один раз и тем самым упростить работу.

Параметр «all» задает обработку всех писем с адресов, не указанных в SPF-записи. Как именно почтовик будет поступать с этими письмами, зависит от префикса, прописанного перед параметром.

Префиксы (или определители) диктуют действия, которые следует применить к письмам отправителя:

«+» — pass, принимать почту.

«-» — fail, отклонять почту.

«~» — softFail, принимать почту, но помещать ее в спам.

«?» — обрабатывать как обычное письмо.

Пара примеров для закрепления:

v=spf1 a include:other-domain.com -all

Принимать почту с А-записи текущего домена и серверов, указанных в SPF-записи домена other-domain.com.  Остальные письма отклонять.

v=spf1 ip6:2002:db7 ~all

Принимать почту с указанного адреса, остальные письма отправлять в спам.

Что дальше

Чтобы отправка сообщений стала еще надежнее, сделайте следующее:

1. Убедитесь, что для домена отправки существует правильная запись SPF. Данная запись прописывается как TXT-запись в системе DNS и говорит, с каких почтовых серверов может быть отправлена почта для домена.
2. Настройте DMARC. Это политики, которые говорят почтовому серверу, что нужно делать с письмами. Требует настроенных SPF и DKIM.

Как проверить SPF

При настройке SPF через сервисы рассылок достаточно проверить статус записи в разделе email-аутентификации. Например, в Unisender корректно настроенная SPF-запись будет отмечена зеленым цветом.

Еще один способ проверить SPF-запись — специальные сервисы, например MailTester.com.

Отправьте ваше письмо на указанный адрес, а сервис проверит, каковы его шансы попасть во входящие.

После отправки сервис покажет общий рейтинг, а также статус настроек email-аутентификации.

Итак, SPF-запись помогает предотвратить спуфинг-атаку на домен, улучшить доставляемость писем и защитить ваших подписчиков от спама.

Для чего нужна SPF-запись

Часто владельцы доменов пренебрегают SPF. А зря. Настройка этой записи займет несколько минут, но убережет от многих проблем.

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

email-маркетолог, основатель блога «Практичный email маркетинг» и автор книг по email-маркетингу

Защита домена от спуфинга. Главная причина настроить SPF — это обеспечить безопасность вашего домена.

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

Если вам пришло подобное письмо, проверьте, с какого адреса оно отправлено и сверьте его с официальным. А лучше позвоните на горячую линию компании. Банки обычно не пишут такие сообщения

Схема, при которой отправитель письма пытается выдать себя за другого, использует чужой логотип и похожий email-адрес, называется спуфинг-атакой. Чтобы защитить корпоративную почту и домен от блокировки, а ваших подписчиков от мошенников, нужно настроить SPF. Тогда подмена отправителя будет уже менее страшна.

Доставка писем во входящие. Почтовые провайдеры лояльны к отправителям, которые настроили email-аутентификацию, в том числе прописали SPF. Почтовики с большей вероятностью пропускают письма таких компаний во входящие.

Дополнительные возможности. Если вы добавили SPF-запись, то сможете подключить сервисы расширенной статистики по отправленным рассылкам — постамстеры. Правда, для этого еще потребуется настроить DKIM.

Немного теории о том, что мы будем настраивать

Итак, прежде чем мы приступим непосредственно к изменению настроек безопасности нашего почтового сервера, нужно разобраться с тем, что именно мы собираемся настраивать. Если тебя не пугают страшные на вид аббревиатуры, состоящие из трех и более заглавных букв латинского алфавита, ты можешь пропустить этот раздел. Остальных приглашаю освежить свои знания, ибо повторение, как гласит народная мудрость, мать учения.

Кто отправляет письма

Сегодня возможность привязать свой домен к сервису предлагают многие веб-службы. Особо популярно размещение почты на Gmail или Яндексе. Все сообщения будут идти через предоставленный ими SMTP-сервер, проверенный поставщик услуг сам сформирует все необходимые заголовки и подписи, которые позволят пройти через любой спам-фильтр. Но такой вариант не всегда возможен. Например, организация имеет большое количество пользователей, нужны особые настройки для почты, недоступные в облачных сервисах. Или используется свой сервер с порталом, CMS или интернет-магазин, с которых нужно отправлять сообщения.

По умолчанию все PHP-приложения используют для отправки почты функцию mail(), которая, в свою очередь, отправляет их через локальный SMTP-сервер, описанный в php.ini.

[mail function]
sendmail_path = /usr/sbin/sendmail -t -i

Или в виртуальном хосте:

php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f webmaster@example.org"

И хотя там в 100% случаев написан sendmail, на самом деле это может быть симлинк, а почту отсылает Postfix или Exim. Чтобы отправить почту из приложения, можно выбрать один из трех вариантов:

• Сам движок иногда позволяет указать внешний SMTP-сервер (в дефолтных настройках или через плагин, в WordPress это WP Mail SMTP или Easy WP SMTP). Достаточно просто указать данные аккаунта, и все проблемы решены.
• Использование программы-прокладки, которая эмулирует работу локального SMTP-сервера и отправляет сообщения через почтовый аккаунт на стороннем сервере. Здесь очень популярна SSMTP.
• Использование своего почтового сервера. Придется, конечно, его настроить, зато больше возможностей конфигурации.

Нас интересует последний вариант. Разберем, как пробиться через антиспам-технологии и гарантированно доставить получателю сообщение. Сами фильтровать спам не будем. Это тема другой статьи. В качестве подопытного SMTP-сервера выберем Postfix и Exim, они популярны на хостингах, просты и понятны в настройках, хотя основные вопросы будут касаться всех SMTP-серверов.

Как настроить SPF для рассылок

Если вы отправляете письма только через почтовые провайдеры, сделайте SPF-запись в настройках аккаунта. У Яндекс, Google и Mail.ru есть подробные инструкции.

Если вы используете сервис рассылок, то для настройки SPF вам потребуется доступ к хостингу вашего сайта. Мы написали пошаговую инструкцию, как настроить SPF с нуля в Unisender.

email-маркетолог, основатель блога «Практичный email маркетинг» и автор книг по email-маркетингу

Создание сертификата и настройка домена

Для создания сертификата можно воспользоваться бесплатным онлайн инструментом на сайте dkimcore.org. Однако, в данном примере, мы воспользуемся opendkim-genkey и сформируем его самостоятельно. Мы будем работать с доменом dmosk.ru (Вам необходимо его заменить своим). Для удобства ввода команд, создадим переменную, в которую запишем имя нашего домена:

И так, создаем каталог для размещения ключей домена:

И генерируем их следующей командой:

В папке /etc/opendkim/dmosk.ru должно появиться два файла с расширениями .private и .txt. Первый — закрытый ключ (храним его у себя на сервере), второй — готовая txt-запись для DNS.

После создания пользователя, задаем группу владельца opendkim для созданных ключей.

Это выполняется командой:

Если система выдаст ошибку, что группы opendkim не существует (chown: opendkim: illegal group name), необходимо сначала создать учетную запись.

Задаем права для группы владельца:

Открываем созданный нами ранее TrustedHosts:

В ранее созданный файл TrustedHosts добавляем домен:

Создаем таблицу KeyTable. В ней хранится список соответствий между селекторами, доменами и файлами с закрытыми ключами. Формат записей:
<селектор>._domainkey.<домен> <домен>:<селектор>:<путь к закрытому ключу>

И напоследок, создаем SigningTable. В данной таблице хранятся соответствия между определенными email-адресами и записями в KeyTable.

systemctl restart opendkim

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

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

• через SMTP-сервер;
• через функцию PHP mail(), он же sendmail.

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

Проверка

Стоит учитывать, что записи в DNS могут обновляться на протяжении длительного времени, например, от 15 минут до 24 часов. Если проверка дала отрицательный результат, пробуем повторить тест через час.

Отправляем письмо

Отправляем электронное сообщение на различные почтовые системы — mail.ru, gmail.com, yandex.ru.

Для удобства, создадим переменную:

* где вместо domain.zone ставим наш домен.

Способов отправки несколько, например, можно выполнить следующие команды.

а) на Red Hat / CentOS:

yum install mailx

* данная команда установит утилиту для отправки почты из командной строки, если ее нет. 

б) на Debian / Ubuntu:

* данная команда установит утилиту для отправки почты из командной строки, если ее нет. 

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

Проверяем заголовки

Открываем наше письмо и смотрим заголовки (в mail.ru: Еще — Служебные заголовки).

Среди них мы должны увидеть следующую строчку:

Проверка домена на базе DKIM настроена успешно.

Присоединяйся к сообществу «Xakep. ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку!
Подробнее

Настройка DNS

Смотрим содержимое файла txt, который был сформирован при генерировании сертификата для домена:

И используя данное содержимое, в панели управления нашим DNS создаем TXT-запись следующего формата:

Дополнительные необязательные записи

* где o=~ означает, что не все сообщения подписываются для домена (o=- — говорит, что все письма используют DKIM).

_adsp._domainkey IN TXT «dkim=all»

* all запрещает принимать письма от домена без цифровой подписи. Другие варианты: discardable — блокировать сообщения на стороне получателя, unknown — по умолчанию (такую запись создавать не обязательно).

Правильная DNS

При получении сообщения удаленный SMTP-сервер анализирует прежде всего его заголовок. Почтовая программа отправляет только From, To, Date, Subject и X-Mailer. Они в общем понятны и просто указывают, от кого и куда слать. Остальной заголовок формируется как SMTP-сервером, так и приложением, его отправляющим. Это, кстати, тоже нужно учитывать, потому что письма, отправляемые через Telnet, могут уходить, а с Roundcube — нет, просто потому, что у них разный заголовок. Roundcube, например, подставляет свой HELO/EHLO на основании переменной server_name или localhost, если она не определена. Поэтому иногда нужно просто задать его явно:

$rcmail_config['smtp_helo_host'] = 'example.org';

То же касается и самописных PHP-скриптов.

При передаче письмо будет проходить минимум через два SMTP-сервера, каждый из которых тоже добавляет что-то от себя в заголовок. В первую очередь каждый сервер добавляет свой Received: from. Читать их лучше снизу вверх. Самое нижнее сообщение — это сервер отправителя, самый верхний — сервер получателя. Хотя на самом деле серверов может быть больше, особенно это актуально при работе с крупными провайдерами услуг, которые, приняв письмо, перебрасывают его дальше, или при использовании на пути SMTP-прокси. Для анализа пути сообщения можно использовать сервис от Google, который покажет в понятной форме все SMTP-серверы, время прохождения и тесты SPF, DKIM и DMARC (о них дальше).

Заголовки Received отличаются, хотя есть общие правила. Типичный выглядит так:

Received: from server.example.org [1.2.3.4] (helo=server.example.org) by st15.provider.com with esmtps (Exim 4.80.1) (envelope-from <mail@example.org>)

В нашем примере за IP 1.2.3.4 должен быть закреплен server.example.org. DNS-запись выглядит так:

1.2.3.4.in-addr.arpa. IN PTR server.example.org

Для IPv6 используется ip6.arpa. В принципе, знать об особенностях PTR необязательно, так как PTR, за редким исключением, настраивает только хостинг-провайдер. И если оно не устраивает, то нужно просто обратиться в поддержку. Проверить PTR можно при помощи запроса:

$ dig -x 1.2.3.4

По факту PTR-запись после развертывания VDS может указывать на технический домен, представленный провайдером, вроде srv01.provider.net, в шаблоне VDS hostname вписан как Ubuntu1604 (меняется в /etc/hostname), в HELO/EHLO SMTP-сервер пишет вообще localhost.localdomain, а письмо идет от домена example.org. Вероятность доставки письма при таких условиях будет стремительно приближаться к нулю. Хотя некоторые сервисы отмечают подобные несоответствия как ошибку и проводят полную проверку.

Особо хочется обратить внимание, что VDS обычно имеет два IPv4 и v6. Поэтому все сказанное касается обеих версий, так как письмо к одному серверу может идти по IPv4 и доставляться, а другой предпочитает использовать IPv6, и письмо может не доходить до получателя. При этом очень много провайдеров, предоставляя IPv6, абсолютно не утруждают себя настройкой PTR-записи, и ее проверка возвращает ошибку. Но Google, например, предпочитает IPv6 и сразу отбрасывает письмо, если PTR не совпадает с именем сервера. В ответном сообщении сервиса это выглядит так:

Our system has detected that this message does
550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and
550-5.7.1 authentication.

Как вариант — можно отключить IPv6 и отправлять только по IPv4. В /etc/postfix/main.cf Postfix для этого следует использовать всего одну строку:

inet_protocols = ipv4

После чего перезапустить сервис.

$ sudo service postfix restart

В Exim в /etc/exim/exim.conf

disable_ipv6 = true

Идеально, когда имя сервера в заголовке и адрес отправителя сообщения совпадают. Если планируется отслеживать свои рассылки через сервис postmaster.mail.ru, то другого варианта и нет. Там это требование проверяется жестко. Он поэтому и не видит рассылки с unisender.com и ему подобных, даже если домен закреплен и подтвержден. Просто потому, что в unisender.com используется собственный SMTP-сервер со своими заголовками и письмо идет не от example.org, а от

Received: from smtp26.emlone.com (smtp26.emlone.com [146.0.246.220])

То есть пишем провайдеру, чтобы поменял PTR на example.com, меняем hostname и проверяем, что сервер отвечает правильным HELO/EHLO. В Postfix за это ответственен параметр myorigin, указывающий имя домена, которое используется в почте, отправляемой с этой машины. По умолчанию myorigin = $myhostname, указывающее на имя хоста. Поэтому

myhostname = example.org

Иногда используется значение $mydomain, которое по умолчанию содержит доменную часть полного имени машины.

Exim в HELO/EHLO использует значение переменной primary_hostname, которая по умолчанию совпадает с именем хоста. Но можно задать его вручную:

primary_hostname = example.org

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

WARNING

Перед любыми операциями по конфигурированию системы не забывай сделать бэкап! Даже одна неправильно включенная опция может отрезать всех пользователей от получения и отправки почтовой корреспонденции. И обязательно тестируй все изменения перед переносом в их продакшен!

Настройка SPF-записи

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

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

WARNING

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

Что такое DKIM?

DKIM (Domain Keys Identified Mail) — это, условно говоря, цифровая подпись, которая подтверждает подлинность отправителя и гарантирует целостность доставленного письма. Подпись добавляется в служебные заголовки сообщения и остается незаметной для самого пользователя. Поскольку в DKIM используется асимметричная система шифрования, репозиторий сервера всегда хранит два ключа шифрования — открытый (сертификат) и закрытый. С помощью закрытого ключа формируются заголовки для всей исходящей почты, а открытый ключ как раз добавляется в DNS-записи в виде TXT-файла.

Статус DKIM проверяется автоматически на стороне получателя при сохранении письма в контейнер (именной почтовый ящик). И если домен в письме не авторизован для отправки сообщений, то письмо может быть помечено подозрительным или же сразу помещено в папку «Спам», в зависимости от настроенной политики безопасности. Кстати, это одна из ключевых причин, почему письма определенных отправителей постоянно попадают в спам, даже несмотря на валидность домена отправителя.

Для работы с DKIM требуется выполнение следующих условий:

• поддержка DKIM почтовым сервером (а она есть у всех современных почтовиков);
• создание приватного и публичного ключа шифрования (это нужно сделать ручками);
• занесение в DNS домена записей, связанных с DKIM (и это тоже ручками).

Что такое SPF?

SPF (Sender Policy Framework) — это еще одна специальная подпись, содержащая информацию о серверах, которые могут отправлять почту с твоего домена. То есть SPF позволяет владельцу домена указать в TXT-записи для DNS-домена специальным образом сформированную строку, содержащую весь список серверов, которые имеют право отправлять email-сообщения с обратными адресами в этом домене. А если сказать то же самое понятными словами, то в этой записи мы сообщаем, с каких почтовых серверов можно посылать письма от имени сотрудников нашей компании. Воу! Вот так просто! В общем, наличие SPF снижает вероятность, что твое письмо попадет в спам.

Важно помнить, что SPF-запись должна быть только одна для одного домена, хотя уже в рамках одной SPF может содержаться несколько записей. И надо сказать, что для поддоменов будут нужны свои записи. И никак иначе! Безопасность требует времени и усердия. 🙂

Что такое DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) — это еще одна подпись, которая позволяет серверу получателя принять решение, что делать с пришедшим письмом. Важно заметить, что DMARC — это скорее дополнительная фича к уже используемым DKIM и SPF. Например, если отправленное сообщение не прошло проверку DKIM и SPF, то оно не пройдет и DMARC. Все логично. А вот если письмо успешно прошло хотя бы одну проверку (DKIM или SPF), то и проверку DMARC оно тоже преодолеет. Также при помощи DMARC можно получать репорты от почтовых систем с информацией, сколько через них пыталось пройти или прошло поддельных сообщений на ваш домен. Из сказанного становится понятно, что DMARC добавляется только после того, как уже настроены записи SPF и DKIM.

От чего нельзя защититься с помощью DKIM, SPF и DMARC

С использованием DKIM, SPF и DMARC можно противостоять email-спуфингу и распространению малвари. Однако важно понимать, что это не гарантирует безопасности в случае взлома сервера, например путем компрометации админки или применения эксплоита, а также если письма форвардятся через иные почтовые сервисы с сомнительной репутацией или с полностью отсутствующими записями DKIM, SPF и DMARC.

Некоторые полезные ссылки для проверки корректности настройки DKIM- и SPF-записей, а также репутации домена:

Также не стоит забывать о регистрации своего сервера в службах постмастера для публичных почтовых серверов (если ты, конечно, администрируешь такой сервер). Это позволит тебе не только получать статистику по рассылкам, но и заработать чуть больше доверия от этого почтового сервиса. Вот самые известные и часто используемые постмастеры: Mail.RU, Yandex и Gmail.

Как работает SPF-запись

А вот если SPF не прописан, велика вероятность, что письмо будет доставлено. И тогда мошенники легко могут написать сообщение от вашего имени и украсть личные данные подписчиков.

Если письмо не доставляется

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

Способ обращения в службу поддержки у разных сервисов отличается, найти их на сайте не всегда просто.

У Google нет поддержки бесплатных продуктов, в том числе и почты Gmail. Но те, кто занимается рассылками, могут отправить запрос через специальную форму. Может, повезет и тебе ответят. Там же есть ссылки на документацию.

Как не попасть в спам

Борьба со спамом — это головная боль всех администраторов почты. Причем в последнее время актуальна как раз обратная сторона медали: спам-фильтры буквально зверствуют. Поэтому спам в приходящей почте практически отсутствует, но вот нормальные сообщения постоянно куда-то пропадают, клиенты и руководство нервничают, и приходится дополнительно убеждаться, что сообщение дошло до адресата. И после установки SMTP-сервера с большой вероятностью придется еще повозиться, чтобы сообщения вообще хоть куда-то доходили. В частности, чтобы оценить настройки, следует посмотреть, доставляются ли письма в ящики основных почтовых систем Gmail, Яндекс, Mail.Ru. Обычно на этом этапе появляются первые сложности, и приходится решать все проблемы персонально.

Почтовые сервисы используют многоуровневую систему фильтрации спама, причем настолько серьезную и засекреченную, что о принципах не знает даже их собственная техподдержка. И у каждого сервиса свои приоритеты. Хотя обычно некая подсказка о причине недоставки содержится в ответном письме сервиса. Также в анализе причин помогает сервис mail-tester.com, достаточно отправить письмо на указанный там адрес и затем после анализа получить результат и перечень проблем. Некоторые из них можно проверить и решить, еще не настраивая SMTP-сервер.

Борьба со спамом породила множество технологий. Самая старая из них — blacklist, в который заносятся все IP и домены, занимавшиеся рассылкой спама, сюда же могут попасть открытые релеи, прокси и Dialup-адреса, используемые для удаленного доступа (то есть они теоретически не должны рассылать почту). Организованы такие blacklist по-разному. Популярностью пользуются DNSBL (DNS blacklist) — черные списки в формате DNS, которые легко опрашивать. На сегодня доступно множество баз, не все они популярны и используются. Проблема в том, что списка для конкретного почтового сервиса нет, сколько и какие они опрашивают — это тайна.

Проверить IP или домен можно самостоятельно, отослав DNS-запрос к выбранному DNSBL-серверу при помощи утилиты dig:

$ host -tA xakep.ru.ex.dnsbl.org
Host xakep.ru.ex.dnsbl.org not found: 3(NXDOMAIN)

Главные мысли

Добавление новых записей dkim

Разберем процесс быстрого добавления дополнительных записей dkim на примере Linux (во FreeBSD будут другие пути до файлов).

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

* где вместо domain.zone ставим наш домен.

Создаем каталог для размещения ключей домена:

mkdir -p /etc/opendkim/$DKIM_DOMAIN

opendkim-genkey -D /etc/opendkim/$DKIM_DOMAIN/ —domain $DKIM_DOMAIN —selector relay

Задаем нужные права:

chown :opendkim /etc/opendkim/$DKIM_DOMAIN/*

chmod g+rw /etc/opendkim/$DKIM_DOMAIN/*

Смотрим содержимое файла txt:

Добавляем соответствующие настройки в файлы TrustedHosts, KeyTable, SigningTable:

а) если Linux:

systemctl reload opendkim

б) если FreeBSD:

service milter-opendkim restart

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

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

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

1. Смотрим настройки DKIM, SPF и DNS на сервисе рассылок:

Если уже есть TXT-запись v=spf1, просто добавляем в нее новый сервер (без создания новой записи).

В нашем примере для работы с spf2-записью ее нужно только включить, используем форму быстрого добавления:

В итоге мы добавили нужные TXT-записи:

Можно пойти другим путем и редактировать уже существующую TXT-запись с параметрами SPF. Лучше, если она будет одна (SPF-запись может объединять все сервера и сервисы, с которых вы отправляете письма). 

Для этого к существующей записи «v=spf1 redirect=_spf.beget.com» (если использовался наш хостинг) нужно добавить «include:spf.unisender.com», а «redirect=» заменить на «include:». В конце ставим «~all». 

3. Затем создаем подзону _domainkey и проводим работу с записью — вносим ее в это поле. Нажимаем «добавить подзону» и вводим название подзоны в поле name через форму быстрого добавления, выбираем тип TXT в поле type, и в поле data вставляем нужную нам:

4. Аналогично нужно создать подзону us._domainkey и внести в неё запись, где отображена сама DKIM-подпись:

После внесения записи все выглядит так:

У нас DNS-записи обычно обновляются 15 минут, в других сервисах может быть дольше. После этого можно проверить наличие в системе и корректность DKIM. Это покажет G Suite, например. В качестве имени нужно ввести имя подзоны: us._domainkey.вашдомен.ru

Чтобы проверить работу, отправьте письмо с ящика домена, для которого проводились настройки цифровой подписи, и на принимающем ящике в графе «Служебные заголовки» найдите заголовок DKIM-Signature, над ним должна быть строка dkim=pass. 

Проверку доступности публичного ключа можно осуществить на сайте DNSWatch. Если такой же технический заголовок есть, значит DKIM работает — вы смогли верно настроить подпись. Но если письмо оказалось не подписано, обратитесь в поддержку к нам или того сервиса, где вы работаете — это поможет настроить DKIM заново.

Для проверки мы отправили рассылку через Unisender. Видно, что заголовок DKIM-Signature есть в технических заголовках письма:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=us; d=доменотправителя.ru; h=From:To:Message-Id:Subject:MIME-Version:Content-Type:List-Help:List-Id: List-Unsubscribe:Date:no; i=info@доменотправителя.ru; bh=bXvoaXR+a1NFSNkUPp9bw+sm5KA=; b=Nel1LTDx3EMy9oPXgrnkVJSk7ZdWUKhuZiynSC5Voi9e/PY/46VF+CBgHD3I8fDdcOlKmsr1dbbo 9sYcRmIKFSTVG8PfYvEUUHeqC2K1BsvW+c8IStUGi1uAbISl2mP8di/wkoija+eBPZmPyov1/aYw Mq3HWOr7jBTH0x9RHbI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=jul2015; d=topeml.com; h=From:To:Message-Id:Subject:MIME-Version:Content-Type:List-Help:List-Id: List-Unsubscribe:Date; bh=bXvoaXR+a1NFSNkUPp9bw+sm5KA=; b=eIDPgMsW3iZmHhoDEFebsbgubtxeLvMCgfu68bfvZ65pYs6PryApPXwJjdev4/2bwcYW3UybQ4oi CSowVihgzRP1bab6ZatiGHwVOQfJ04W1qafl2X0NQ/vkorP5ZdyA7V+k8tQNxdp1uL3Ce32kIk2M 1eORNohPUf9qbpOACLc=

Значит, DKIM работает.

А проверить корректность работы SPF вы можете, например, через сервис PowerDMARC. Просто введите имя вашего домена в поле поиска и нажмите кнопку «Поиск».

Удачи! Если возникнут вопросы по работе с DKIM — напишите нам, пожалуйста, тикет из Панели управления аккаунта, раздел «Помощь и поддержка».

Настройка OpenDKIM и Postfix

OpenDKIM

Переносим старый конфигурационный файл opendkim и создаем новый.

Создаем новую конфигурацию.

Добавим следующие строки:

* все параметры можно оставить, как в данном примере, за исключением Socket — можно указать любой другой порт, вместо 12301.

Создаем каталог /etc/opendkim (например, в Debian он не создается автоматически):

* если увидим сообщение mkdir: cannot create directory ‘/etc/opendkim’: File exists, то значит, каталог и так создан.

И вносим следующее:

Создаем остальные конфигурационные файлы (если их нет):

Запускаем службу opendkim.

а) На Linux:

systemctl enable opendkim

б) На FreeBSD:

Сначала добавляем демона в rc.conf:

* первая команда разрешает запуск демона, вторая — принудительно заставляет его запускаться от пользователя opendkim.

И запускаем его:

service milter-opendkim start

Postfix

Открываем конфигурационный файл.

Добавляем или редактируем:

milter_protocol = 2
milter_default_action = accept
smtpd_milters = inet:localhost:12301
non_smtpd_milters = inet:localhost:12301

* если smtpd_milters и non_smtpd_milters присутствуют в конфигурационном файле, то приведенные в данном примере значения нужно дописать к имеющимся.
** 12301 — порт работы opendkim, который был задан в opendkim.conf.

systemctl restart postfix

service postfix restart

Решение проблем

Большинство трудностей решается чтением логов. Для opendkim они будут попадать в общий log-файл почты. Включить его непрерывный просмотр можно следующей командой.

а) для Red Hat / CentOS / FreeBSD:

tail -f /var/log/maillog

б) для Debian / Ubuntu:

tail -f /var/log/mail.log

Также, очень часто, проблемы возникают из-за неправильной настройки прав на ключи. Нужно иметь ввиду, что некоторые системы, из соображений безопасности, выдают ошибку, если на файлы выданы слишком широкие права на чтение. То есть, если разрешить читать файлы всем (chmod 644), система будет возвращать ошибку. Если в логах видим «error loading key», скорее всего, проблема с правами. Внимательно выполните повторно рекомендации 2-о пункта данной инструкции.

Еще одно часто появляющееся сообщение — «opendkim no signing table match for». Оно говорит, что для домена, от которого отправляется почта, нет соответствий в файле SigningTable. Либо была допущена опечатка, либо, на самом деле, для домена отправки не нужно использовать DKIM.

Установка OpenDKIM

Для начала, устанавливаем пакет OpenDKIM. Он выполняет операции шифрования заголовков для DKIM, а также содержит набор утилит для формирования ключей.

Для его установки вводим следующее.

а) Для Ubuntu / Debian / Astra Linux:

б) Для Rocky Linux / CentOS:

в) Для FreeBSD:

pkg install opendkim

или из портов:

make install clean

Заключение

Вот и все! Если проделать все описанное, то о проблемах с доставкой почты можно забыть.