Необходимые настройки для беспроблемной доставки доменной почты
В последнее время встречаю много вопросов по поводу недоставки доменной почты или попадания ее в спам. Почтовики все ужесточают и ужесточают политики обработки писем. Обычные владельцы сайтов отправляют вполне безобидные письма своим клиентам используя свою же доменную почту, но письма улетают в спам или вообще не доходят. Что же нужно настроить, чтобы не было проблем?
Для нормальной доставки доменной почты необходимо корректно настроить:
- PTR
- SPF
- Заголовок Return-Path
Также для защиты от несанкционированного использования Вашего домена можно настроить:
- DKIM
- ADSP
- DMARC
Что это за непонятные штуковины и как их настроить, опишу ниже.
PTR (обратная dns запись)
У любого домена в dns есть A записи, которые связывают домен с IP сервера, на котором находится сам сайт. А PTR запись делает то же самое, но наоборот, связывает IP сервера с доменом.
PTR запись очень важна для почтовиков. Когда на почтовый сервер приходит письмо, он берет IP, откуда пришло письмо, затем смотрит значение этой записи. Если значение этой записи совпадает с именем сервера, откуда пришло письмо, то почтовик пропускает письмо. Если не совпадает, то в большинстве случаев кидает в спам или вообще не пропускает. Также высока вероятность бана IP сервера Gmail’ом, если записи нет или она некорректно настроена (даже при корректной настройке остальных параметров).
Где настроить PTR запись?
На нормальных обычных хостингах PTR уже настроен, ничего делать не нужно. Если же у Вас виртуальный или физический сервер, то, как правило, нужно самому прописывать эту запись в панели управления сервером. Название поля для PTR может быть разным — ptr, reverse dns, имя сервера и т.д. Также в имени сервера (в самой ОС) должен быть указан этот домен (Linux — /etc/hostname, FreeBSD- /etc/rc.conf).
Что указывать в PTR записи, если на сервере несколько доменов?
Если на сервере хостится несколько доменов, то нужно взять один из них и прописать его в имени сервера и в PTR записи.
Как проверить PTR запись?
PTR можно проверить на соответствующих сервисах, например, тут. Также можно проверить консольными утилитами, например, dig:
dig -x 123.123.123.123 +short
Команда выше выведет значение PTR записи.
SPF
SPF (Sender Policy Framework) — это ещё одна важная запись. Необходима для того, чтобы указать почтовым серверам, с каких ресурсов будут приходить письма, т.е. верификация источника. Сама запись практически никак не влияет на несанкционированное использование домена, она больше нужна как требование большинства принимающих почтовых серверов. Также, если если нет этой записи или она некорректно настроена, то отправляемые письма скорее всего попадут в спам или будут отмечены как поддельные:
Как и где прописать SPF запись?
SPF запись прописывается в dns записях домена и представляет собой TXT запись в DNS, например:
В начале записи должна быть указана версия SPF записи v=spf1. Рекомендуется использовать только эту версию.
Затем через пробел идут источники. Они могут быть следующими:
- Обычные IP адреса / подсети адресов с префиксами
ip4:(для IPv4 адресов) иip6:(для IPv6 адресов). Например,ip4:123.123.123.123. Могут использоваться в записи несколько раз. Это предпочтительный тип источника, и они не создают дополнительные DNS запросы; - Ссылки на другие записи в DNS домена / других доменов. Например,
a,mx. Такой тип не рекомендуется, т.к. значения неявные, и создаются дополнительные запросы к DNS; - Подключение внешних валидных SPF записей через
include:. Например,include:somedomain.com. Обычно такой тип используется, чтобы подключить в основную запись записи удаленного почтового сервиса или сервиса рассылки. Каждое такое подключение создает от одного дополнительного запроса в DNS, в зависимости от того, сколько подключений идет внутри. Поэтому не стоит этим злоупотреблять.
Также возможны еще более сложные вариации источников, но не буду их описывать, т.к. в большинстве случаев они не требуются. Подробнее можно узнать в RFC 7208.
Обратите внимание на то, что в SPF допускается до 10 дополнительных запросов в DNS. Если будет больше, то запись будет невалидной. Проверить вложенность и колличество DNS запросов в SPF записи можно здесь.
В конце записи указывается политика для неуказанных в записи источников и может быть:
-all(hardfail) — отклонять (не рекомендуется, т.к. в некоторых случаях может только навредить доставке писем);~all(softfail) — не следует отклонять, но обратить внимание (рекомендуется);?all— относиться нейтрально (не рекомендуется);allили+all— принимать (не рекомендуется).
Иногда возможны случаи, когда нужно полностью взять всю SPF запись с другого домена. Для этого существует redirect=. Например, redirect=domain.com. В этом случае больше никакие записи не указываются, в т.ч. и all.
Еще обратите внимание на то, что, если сервер и MTA (exim4, sendmail и т.д.) умеют работать по IPv6 и указан только IPv4, то IPv6 тоже нужно указать в SPF записи, т.к. на некоторые почтовые сервера письма будут уходить через IPv6.
Давайте приведу простой пример. У нас есть сайт на сервере с IP 123.123.123.123, подключена доменная почта на том же сервере, плюс ко всему используем сервис рассылки responder.com, с которого идет рассылка от Вашей доменной почты. Такие сервисы обычно предоставляют адрес, который нужно добавить в SPF запись. Например это будет spf.responder.com. SPF запись получится такой:
v=spf1 ip4:123.123.123.123 include:spf.responder.com ~all
SPF запись для одного домена должна быть только одна и она не распространяется на поддомены. Для поддоменов должна быть отдельная SPF запись.
Как проверить 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 записи можно проверить вот здесь.
DKIM
DKIM (DomainKeys Identified Mail) — это цифровая подпись писем. Она гарантирует, что письмо отправлено именно от того домена, который указан в email отправителя.
Логика такая: сервер отправляет заранее подписанное письмо почтовому серверу. Почтовый сервер сверяет подпись с публичным ключом, который указан в DNS домена. Если подпись не совпадает, то почтовый сервер следует правилам в записях DMARC и ADSP, а при их отсутствии руководствуется своими политиками.
Как настроить DKIM?
Если у Вас обычный хостинг и используете их же почтовый сервер, то DKIM скорее всего уже работает из коробки. Ничего делать не нужно.
Если же у Вас виртуальный или физический сервер, то DKIM необходимо настраивать самостоятельно. На стороне сервера Вам необходим приватный ключ для подписи писем и публичный ключ для DNS. Эти ключи генерируются самостоятельно, либо выдаются почтовыми сервисами или сервисами рассылки. Также нужно включить подпись писем в MTA (отправщике писем) на сервере.
После того, как подписывание писем на стороне сервера настроено, необходимо создать TXT запись в DNS вида:
В поле хоста должен быть указан селектор и ._domainkey на конце. Например, mail._domainkey.
Важно: селектор в DNS записи должен соответствовать селектору DKIM подписи.
В значении записи указываем через точку с запятой:
v— версия DKIM (всегдаv=DKIM1);k— алгоритм шифрования (всегдаk=rsa);p— публичный ключ (p=публичный_ключ).
Дополнительные параметры:
t=y— режим тестирования;t=s— использование записи только для домена, для поддоменов запись использоваться не будет;h— предпочитаемый hash-алгоритм, может бытьh=sha1иh=sha256;s— тип сервиса, использующего DKIM, может бытьs=email(электронная почта) иs=*(все сервисы, по умолчанию).
Как проверить DKIM?
Для проверки наличия самой подписи можно глянуть заголовки письма. Должно быть что-то типа такого:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=domain.com; h=date
:from:to:message-id:subject:mime-version:content-type; s=
dc-smart1; bh=sM8mwMa+DhlFNAT/Q85vxxnJ9PAemdLfkhxQbVXajbs=; b=NG
MBJ9qrrJSyCqQ9p8nFkBBDK+86d/QKOYAsQbL3V6fVdwqtJwyKAq2LNlmSagSQwp
1yBEeS88rtA6aVSoRg4pyJ/vwFYaP8LYqD8DfL5dXSzUFyEqPAgmI08qmBafPFrC
jhDVyKDbJrpCIo2i6HJ8to3gcArB2GGxdXTMM/th0=
Корректность связки подписи и публичного ключа можно можно так же увидеть в заголовках письма:
Authentication-Results: mx.google.com; ... ; dkim=pass header.i=@domain.com
Если проверка DKIM не пройдет, то увидим dkim=fail.
Как прописать в DNS несколько DKIM ключей?
Иногда необходимо прописать в DNS домена несколько публичных DKIM ключей, когда письма от доменной почты идут не только с сервера, но и, например, с сервиса почтовой рассылки. Для добавления дополнительной записи необходимо создать еще одну TXT запись. При этом селектор в хосте должен быть другой:
ADSP
ADSP (Author Domain Signing Practices) — политика, которая позволяет сообщать принимающим почтовым серверам, что делать с письмом пришедшим с нашего домена, но не имеющее подписи. Если этой записи нет, то принимающий почтовый сервер следует своим политикам обработки писем. Эту запись нужно указывать после настройки DKIM.
ADSP запись признана устаревшей и не нужна при использовании DMARC.
Как прописать ADSP запись?
ADSP запись прописывается в TXT записи в DNS записях домена:
Поддерживаемые значения:
all— все письма должны быть подписаны (рекомендуется);discardable— отклонять все неподписанные письма (не рекомендуется, т.к. в некоторых случаях может навредить);unknown— аналогично отсутствию записи (бесполезное значение).
DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) — ещё одна политика обработки писем для почтовых серверов. Она задает политику проверки приходящей доменной почты и указывает, что делать, если письма не проходят проверку SPF или DKIM. Для этой записи необходимо предварительно настроить SPF и DKIM. Если DMARC записи нет, то принимающий почтовый сервер следует своим политикам обработки писем.
Как настроить DMARC?
DMARC — это обычная TXT запись. Прописывается в DNS домена:
Основные параметры записи:
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.
Остальные параметры можно посмотреть в RFC 7489.
Что же указать в DMARC?
Рекомендую указать p=none, sp=none и rua=mailto:user@domain.com (если хотите получать отчеты). В этом случае принимающий почтовый сервер будет руководствоваться своими политиками.
Если же Вы на 100% уверены, что все Ваши письма проходят проверку DKIM и SPF, то можете использовать quarantine или reject, при этом поднимая процент обрабатываемых писем через параметр pct.
Заголовок Return-Path
По сути этот заголовок нужен для указании адреса, куда будут отсылаться сообщения об ошибках доставки. Но этот заголовок так же важен для отправляемых писем, т.к., если он не передан или в нем передана почта с другим доменом, то отправляемые письма скорее всего попадут в спам или будут отмечены как поддельные (аналогично некорректной SPF записи):
Сам заголовок должен быть передан сайтом/приложением и содержать в адресе тот же домен, что и в заголовке From.
Рекомендации
- В первую очередь проверьте/настройте PTR запись, пропишите корректную SPF запись и проверьте наличие корректного заголовка Return-Path в отправляемых письмах. Этого будет достаточно для нормальной отправки писем.
- Не помешает еще проверить наличие IP адреса сервера, откуда идет почта, в спамлистах, например, здесь. Если же Вы обнаружили, что IP в спамлистах, то желательно его сменить. Обычно на хостингах это решается покупкой выделенного IP, на виртуальных серверах пересозданием сервера, на физических серверах сменой сервера или покупкой дополнительного IP адреса.
- Для дополнительной защиты от несанкционированного использования Вашего домена корректно настройте DKIM, ADSP и DMARC.
- Не отправляйте слишком большие письма. Заголовки письма тоже учитаваются. Можно упереться в лимит размера.
- Не отправляйте письмо большому количеству получателей. Можно так же упереться в лимиты.
- В письме не должно быть очень длинных строк. Можно упереться в лимиты длины строки (да, такое тоже бывает).
- Следите за контентом самих писем, чтобы у получателей не было желания, отправить их в спам.
- Не занимайтесь рассылкой писем с Вашего хостинга/сервера. Для этого существуют грамотно настроенные сервисы рассылки.
- Если Вы не занимаетесь рассылкой, но частота отправки писем очень большая, то шлите почту через сервисы рассылки. Иначе принимающие почтовые серверы могут временно ограничить прием писем от Вашей доменной почты.
Полезные ссылки
- mxtoolbox.com — сервис проверки различных параметров настройки почты. На этом сервисе можно добавить свой домен для мониторинга параметров, на почту будут регулярно приходить отчеты;
- easydmarc.com — еще один сервис с утилитами для проверки;
- mail-tester.com — сервис проверки качества писем и корректности параметров. Отправляете на указанный адрес письмо — получаете развернутую информацию о письме.
