Настройки DNS для доменной почты

Для нормальной доставки доменной почты необходимо корректно настроить:

• PTR (обязательно)
• SPF (обязательно)
• Заголовок Return-Path

Также для защиты от несанкционированного использования домена можно настроить:

• DKIM (условно обязательно для защиты)
• ADSP
• DMARC (условно обязательно для защиты)

PTR (обратная dns запись)

У любого домена в dns есть A записи, которые связывают домен с IP сервера, на котором находится сам сайт. А PTR запись делает то же самое, но наоборот, связывает IP сервера с доменом.

PTR запись очень важна для почтовиков. Когда на почтовый сервер приходит письмо, он берет IP, откуда пришло письмо, затем смотрит значение этой записи. Если значение этой записи совпадает с именем сервера, откуда пришло письмо, то почтовик пропускает письмо. Если не совпадает, то в большинстве случаев кидает в спам или вообще не пропускает.

На физическом сервер нужно самому прописывать эту запись в панели управления сервером. Название поля для PTR может быть разным — ptr, reverse dns, имя сервера и т.д. Также в имени сервера в самой ОС должен быть указан домен в файле /etc/hostname.

Проверка PTR записи

Проверка PTR записи, должно возвращаться доменное имя вашего сервера:

dig -x IP_вашего_сервера +short

SPF

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

SPF запись прописывается в dns записях домена и представляет собой TXT запись в DNS:

v=spf1 ip4:176.57.223.0/24 ip4:92.53.116.0/22 ip4:ip_вашего_сервера/32 ~all

Такая запись означает, что письма с данного домена могут отправляться из подсетей 176.57.223.0/24 и 92.53.116.0/22, а письма, пришедшие с других серверов all, должны проходить дополнительную проверку ~.

Любая SPF-запись начинается с v=spf1, этот параметр не изменяется. Он указывает на версию записи, и в настоящее время поддерживается только spf1.

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

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

• + принимать почту, прописывать этот параметр необязательно, он установлен по умолчанию (т.е.значения «+a +mx» и «a mx» — идентичны)
• - отклонять почту
• ~ мягко отклонять (принимать почту, но помещать ее в «Спам»)
• ? нейтрально (обрабатывать как обычное письмо)

all

Параметр all подразумевает все серверы, не упомянутые отдельно в SPF-записи. all задает обработку полученных с них писем и указывается в конце записи.

Например принимать почту только с A-записи домена, письма с других адресов должны отвергаться:

v=spf1 a -all

ip4 / ip6

Используется для указания конкретных адресов и подсетей, из которых могут отправляться письма. Синтаксис для IPv4 и IPv6 идентичен.

Например принимать почту из подсети 176.57.223.0/24:

v=spf1 ip4:176.57.223.0/24 ~all

a

IP отправителя проверяется на соответствие A-записи домена.

Например принимать почту с A-записи текущего домена:

v=spf1 a ~all

mx

IP отправителя проверяется на соответствие IP-адресам серверов, указанных в MX-записях домена. На текущий день для многих современных сервисов эта директива уже не так важна, так как серверы входящей и исходящей почты зачастую имеют разные IP.

Например принимать почту с MX-серверов текущего домена и домена sub.domain.com:

v=spf1 mx mx:sub.domain.com -all

include

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

Например принимать почту с A-записи текущего домена и серверов, указанных в SPF-записи домена other-domain.com:

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

redirect

Технически, redirect является модификатором, а не механизмом. Он выполняет одну основную функцию: сообщает, что необходимо применять настройки SPF другого домена.

Например почта должна приниматься или отклоняться согласно настройкам домена other-domain.com:

v=spf1 redirect=other-domain.com

Проверка SPF записи

SPF можно проверить в заголовках исходника письма. Заголовки письма можно посмотреть на большинстве почтовых программ и веб-версий почтовиков.

Пример удачной проверки:

Authentication-Results: mxfront10o.mail.yandex.net; spf=pass (mxfront10o.mail.yandex.net: domain of domain.com designates 123.123.123.123 as permitted sender, rule=[ip4:123.123.123.123]) smtp.mail=info@domain.com

Пример неудачной проверки:

Authentication-Results: mxfront12g.mail.yandex.net; spf=softfail (mxfront12g.mail.yandex.net: transitioning domain of domain.com does not designate 123.123.123.123 as permitted sender, rule=[~all])

Валидность SPF записи можно проверить вот здесь.

Заголовок Return-Path

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

Сам заголовок должен быть передан сайтом/приложением и содержать в адресе тот же домен, что и в заголовке From.

DKIM

DKIM это цифровая подпись писем. Она гарантирует, что письмо отправлено именно от того домена, который указан в email отправителя. Логика такая: сервер отправляет заранее подписанное письмо почтовому серверу. Почтовый сервер сверяет подпись с публичным ключом, который указан в DNS домена. Если подпись не совпадает, то почтовый сервер следует правилам в записях DMARC и ADSP, а при их отсутствии руководствуется своими политиками.

Несмотря на исключительную пользу стандарта, в большинстве случаев внедрить его возможно только путем установки дополнительных компонентов. Я использую Postfixи в его функционал DKIM не включен, но зато он реализуется с помощью пакета OpenDKIM. Весь процес подробно расписан тут.

ADSP

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

ADSP запись прописывается в TXT записи в DNS записях домена.

Поддерживаемые значения:

• all все письма должны быть подписаны (рекомендуется)
• discardable отклонять все неподписанные письма (не рекомендуется, т.к. в некоторых случаях может навредить)
• unknown аналогично отсутствию записи (бесполезное значение)

DMARC

DMARC политика обработки писем для почтовых серверов. Она задает политику проверки приходящей доменной почты и указывает, что делать, если письма не проходят проверку SPF или DKIM. Для этой записи необходимо предварительно настроить SPF и DKIM. Если DMARC записи нет, то принимающий почтовый сервер следует своим политикам обработки писем.

Основные параметры записи:

• v версия записи, должно быть DMARC1 (наличие обязательно)
• p (policy) — политика домена, может быть:
  none — не принимать никаких особых действий, всё на усмотрение почтовика
  quarantine — отправить в спам
  reject — не принимать письмо
• sp (subdomain policy) — политика поддоменов, может принимать те же значения, что и p (policy)
• pct (percentage) — процент писем, которые подвергаются политикам. Например, при политике v=DMARC1; p=quarantine; pct=50; половина писем не прошедших аутентификацию пойдет в спам. По умолчанию pct=100
• rua (reporting URI for aggregate reports) — почтовый адрес в формате mailto:user@domain.com, на который раз в сутки будут приходить отчеты в XML

В примере отправитель требует, чтобы получатель отклонил все неаутентифицированные сообщения и отправил агрегированный отчёт об отклонении по адресу postmaster@example.com:

v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@example.com