DKIM, SPF, PTR, DMARC: как настроить почту чтобы не попасть в спам

В статье рассказывается что такое DKIM, SPF и PTR и как с их помощью уменьшить вероятность попадания ваших писем в спам. Это может пригодится администраторам, которые настраивают свои почтовые сервера\сервисы или рассылки с сайта.

При получении какого-либо письма почтовый сервер-получатель проводит ряд проверок. Чем больше проверок будет пройдено с положительным результатом, тем меньше вероятность того, что письмо попадет в папку "Спам".

PTR запись

PTR запись - это обратная запись, которая связывает IP адрес с именем домена. Например если в консоли ввести команду "ping google-public-dns-a.google.com", то можно увидеть, что запросы посылаются к IP 8.8.8.8, это прописано в A-записи. Если же ввести команду "ping -a 8.8.8.8" то увидим что 8.8.8.8 преобразуется в "google-public-dns-a.google.com". Именно за это и отвечает PTR запись - обратно преобразовывает IP адрес в доменное имя.

В целях борьбы со спамом многие серверы-получатели почты проверяют наличие PTR записи для хоста, с которого происходит отправка и если видят не соответствие, то с высокой вероятностью помечают это письмо как спам. То есть IP адрес имени хоста (хост этим именем представляется), который постучался к серверу-получателю на "почтовый" порт для передачи письма, должен преобразоваться в это имя.

in-addr.arpa — специальная доменная зона, для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.

Итак подытожим, для прохождения проверки на PTR запись у нас должны быть две записи:

• A-запись которая говорит что, например, mailserver.elims.org.ua это ip 1.2.3.4
• PTR запись которая говорит что, например, 1.2.3.4 это mailserver.elims.org.ua

Если письма из Вашей организации посылаются через чужие почтовые сервера, то Вам ничего настраивать не нужно, нужно лишь проверить что PTR корректно настроена и попросить администраторов этих чужих серверов почтовых серверов (а значит и доменных зон) настроить PTR запись, если она не корректна.

Если же у Вас в локальной сети есть свой почтовый сервер, то для своей доменной зоны прописываем A-запись на IP-адрес, под которым будет виден Ваш почтовый сервер в интернете и просим чтобы Ваш провайдер прописал у себя соответствующую PTR-запись.

Посмотреть PTR через команду:

• nslookup: nslookup -type=PTR 46.4.26.19
• dig: dig -x 46.4.26.19

Ссылка по теме: PTR записи

SPF запись

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

В SPF записях можно использовать следующие опции:

• "v=spf1" - версия SPF.
• "+" - принимать письма (Pass). Этот параметр установлен по умолчанию. Тоесть, если никаких параметров не установлено, то это "Pass";
• "-" - Отклонить (Fail);
• "~" - "мягкое" отклонение (SoftFail). Письмо будет принято, но будет помечено как СПАМ;
• "?" - нейтральное отношение;
• "mx" - включает в себя все адреса серверов, указанные в MX-записях домена;
• "ip4" - опция позволяет указать конкретный IP-адрес или сеть адресов;
• "a" - IP-адрес в A-записи
• "include" - включает в себя хосты, разрешенные SPF-записью указанного домена;
• "all" - все остальные сервера, не перечисленные в SPF-записи.
• "ptr" - проверяет PTR-запись IP-адреса отправителя. Если она сходится с указанным доменом, то механизм проверки выдает положительный результат. Тоесть, разрешено отправлять всем IP-адресам, PTR-запись которых направлены на указанный домен.
• "exists" - выполняется проверка, резолвится ли домен на какой-либо IP-адрес. Тоесть, по существу, выполняется проверка работоспособности доменного имени. Не имеет значения, на какой IP-адрес, даже если это "серые" сети (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) или loopback (127.0.0.1).
• "redirect" - указывает получателю, что нужно проверять SPF-запись указаного домена, вместо текущего домена.

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

elims.org.ua. IN TXT "v=spf1 +a +mx -all"

Расшифровываем:

• "+a" - разрешает прием писем от хоста, IP-адрес которого указан в A-записи для elims.org.ua;
• "+mx" -  разрешает прием писем, если отправляющий хост указан в одной из MX-записей для elims.org.ua;
• "-all" - все остальные письма не принимать.

Еще один пример:

elims.org.ua. IN TXT "v=spf1 ip4:124.31.25.75 mx/24 a:test.com.ua/24 +a:smtp.mail.ru include:gmail.com ~all"

Расшифровываем:

• "ip4:124.31.25.75" - принимать письма, отправленные с IP-адреса 124.31.25.75;
• mx/24" - в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и MX-ы домена
• "a:test.com.ua/24" - в список разрешенных отправителей входят все IP-адреса, находящихся в тех же сетях класса С, что и А-записи домена test.com.ua;
• "+a:smtp.mail.ru" - то же, что и a:smtp.mail.ru. Принимать от smtp.mail.ru;
• "include:gmail.com" - принимать письма с серверов, разрешенных SPF-записями gmail.com;
• "~all" - принимать письма со всех остальных серверов, но помечать их как СПАМ

elims.com. IN TXT "v=spf1 redirect:elims.org.ua ~all"

Расшифровываем: для домена elims.com. следовать тем же инструкциям которые описаны в spf для домена elims.org.ua

DKIM

DomainKeys Identified Mail (DKIM)  — для определения отправителя письма в него добавляется цифровая подпись, которую можно проверить открытым ключем шифрования указанным в текстовой записи домена.

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

• Поддержка DKIM почтовым сервером для подписывания отправляемой почты - например бесплатный почтовый сервер под windows hMailServer;
• Создание приватного и публичного ключа шифрования
• Занесение в DNS домена записей связанных с DKIM

Создание приватного и публичного ключа шифрования

Генерация приватного ключа при помощи утилиты openssl:

openssl.exe genrsa -out tstpriv.pem 1024

Генерация публичного ключа из приватного ключа при помощи утилиты openssl:

openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem

Занесение в DNS домена записей связанных с DKIM

Прописываем эту запись:

_domainkey.example.com. TXT "t=s; o=~;"

Прописываем публичный ключ:

ТутПишитеЧтоХотите._domainkey.example.com. TXT "k=rsa\; t=s\; p=MIGfMA0GCSqGSIb3DQEBAQUAИЕЩЕМНОГОБУКВ"

Где:

• ТутПишитеЧтоХотите - так называемый domain selector, которых может быть несколько, например для каждого почтового сервера, если их у Вас несколько
• p= - публичный ключ

Не обязательная запись, которая говорит что делать с не подписанными письмами:

_adsp._domainkey.example.com. TXT "dkim=all"

"dkim=" может принимать следующие значения:

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

Возможные ошибки DKIM:

• pass = ‘The message was signed, the signature or signatures were acceptable, and the signature(s) passed verification tests.’ This is the result you want to see. Everything worked perfectly.
• fail = ‘The message was signed and the signature or signatures were acceptable, but they failed the verification test(s).’ This means that the message had a signature, and the signature was formed correctly, but didn’t match the signature of the sending domain. This probably means the message was modified somewhere along the way.
• none = ‘The message was not signed’ This means that the message had no DKIM signature. This is not the same as failing.
• policy = ‘The message was signed but the signature or signatures were not acceptable.’ DKIM can be configured to be more or less stringent in what is an acceptable match. A “policy” error means that the message was signed and correctly formed, but didn’t meet the policy requirements of the recipient.
• neutral = ‘The message was signed but the signature or signatures contained syntax errors or were not otherwise able to be processed.’ The message was signed, but it was not formed correctly. This is possibly a configuration error on the sending domain side.
• temperror = ‘The message could not be verified due to some error that is likely transient in nature, such as a temporary inability to retrieve a public key. A later attempt may produce a final result.’ This error indicates that there was a short-term problem verifying the signature. Feel free to try again. Repeated problems with this may indicate a DNS or lookup failure on the sending domain.
• permerror = ‘The message could not be verified due to some error that is unrecoverable, such as a required header field being absent. A later attempt is unlikely to produce a final result.’ The signature (or some part of it) was missing from the recieved message, which caused a failure. This indicates that either the header was formed incorrectly or it was modified after being sent.

Заголовки DKIM:

• b = the actual digital signature of the contents (headers and body) of the mail message
• bh = the body hash
• d = the signing domain
• s = the selector
• v = the version
• a = the signing algorithm
• c = the canonicalization algorithm(s) for header and body
• q = the default query method
• l = the length of the canonicalized part of the body that has been signed
• t = the signature timestamp
• x = the expire time
• h = the list of signed header fields, repeated for fields that occur multiple times

DMARC

Если очень кратко - то это еще одна запись в dns, которая указывает что делать с поддельными письмами. Письма считаются поддельными если они не проходят проверку spf и dkim, поэтому dmarc нужно прописывать только после их настройки. Также можно получать репорты от почтовых систем, которые сообщают сколько через них пыталось пройти или прошло поддельных писем на ваш домен.

Эта запись говорит ничего не делать с поддельными письмами на домен elims.org.ua и посылать ежедневные отчеты на почту postmaster@elims.org.ua :

_dmarc.elims.org.ua. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:postmaster@elims.org.ua"

Если хочется посылать на почтовый ящик который находится в другом домене, например на ящик postmaster@otherdomain.com, тогда dns домена otherdomain.com нужно прописать запись:

elims.org.ua._report._dmarc.otherdomain.com. 3600 IN TXT "v=DMARC1"

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

P.S.: отчеты удобно просматривать при помощи этого сервиса-конвертера - dmarcian.com/xml-to-human-converter

Используемые источники и полезные ссылки:

• SPF Policy Tester - проверка spf: указываете почтовый адрес с которого хотите отправлять и ip-адрес почтового сервера. Если все хорошо, то внизу теста должна быть зеленная надпись PASS
• muff.kiev.ua - статья "SPF-запись - проверяем валидность отправителя"
• habrahabr.ru - DKIM — это просто
• wikipedia.org - DomainKeys Identified Mail
• dkimvalidator.com - вам дают адрес почты на который нужно выслать письмо, после этого можно просмотреть отчет об валидности dkim
• mail-tester.com - тоже дается адрес почты на который нужно выслать письмо, после этого можно посмотреть на отчет
• mxtoolbox.com - еще один сервис проверки почтового сервера
• Exim + DKIM на примере FreeBSD 8.2 - если нужно подсмотреть как сконфигурировать Dkim в почтовом сервере Exim
• port25.com/authentication-checker - посылаете письмо на один из указаных ящиков и через пару минут получаете в ответ репорт
• Cправка - Gmail: Устранение неполадок с массовыми рассылками - набор вопросов на которые нужно выбрать ответ, получите рекомендации что нужно исправить
• Cправка - Gmail: Рекомендации по осуществлению массовых рассылок
• Cправка - Gmail: Инструменты Postmaster Tools - Если вы отправляете большое количество писем пользователям Gmail, вы можете воспользоваться средствами Postmaster Tools, чтобы узнать: помечают ли пользователи ваши письма как спам; соответствуют ли ваши рассылки рекомендациям; почему ваши письма могут не доставляться; обеспечивается ли безопасность при отправке писем.
• postmaster.google.com/managedomains - собственно сам сервис упомянутый в пункте выше
• Cправка - Gmail: Сообщить о проблемах доставки между доменом и Gmail - тут можно попробовать достучаться до техподдержки gmail
• DMARC: защитите вашу рассылку от подделок
• Как попасть в INBOX: всё о DMARC
• dmarcian.com/xml-to-human-converter - конвертирует xml в более читабельный вид