Все, что стоит знать о настройках почты

- Спасение электронного письма – дело рук отправителя!

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

- Лилу Далас!

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

Итак, что же нужно для максимально беспроблемного путешествия нашего сообщения к адресатам? На сегодняшний день это:

• правильно настроенные НС-записи почтовых серверов;
• соответственно настроенная обратная(PTR) – запись;
• правильно настроенный на ответ почтовый сервер («баннер»);
• SPF/DKIM/DMARC – записи.

Начнем по порядку

НС-записи или ДНС-записи

Все, что есть в интернете, может работать исключительно благодаря DNS-серверам, которые денно и ношно переводят понятные нам имена, например - google.com, в понятные серверам IP-адреса (172.217.16.14). Естественно для каждого «чиха» должна быть своя НС-запись.

НС-записи есть нескольких типов:

• NS – перечисляют непосредственно ДНС-сервера для домена;
• А – (от слова «Address») – преобразует имя в IP-адрес;
• MX – говорит о серверах отвечающих за обслуживание почты для домена;
• ТХТ – текстовая информация для других серверов. Например, в это поле вносят ключи SPF и т.п.

Интересующие нас записи – МХ и А типов выглядят примерно так:

При этом вполне себе допустимо, чтоб для сервера example.com почтовым сервером был назначен сервер – mail.other.net. Так же как и для одного сервера может быть несколько соответствующих А-записей с разными IP-адресами – таким образом осуществляется балансировка нагрузки между серверами/каналами данных.

ТХТ-запись выглядит следующим образом:

Как можем увидеть тут есть информация по верификацию домена (например, подтверждение для googl’а) и SPF-запись. О самом SPF’е поговорим чуть ниже.

PTR – или «обратная» запись

PTR–запись это обратное преобразование IP-адреса в доменное имя. Выглядит оно вот таким незамысловатым образом:

Да, это тоже НС-запись, но сделать её может реальный хозяин IP-адреса будь то провайдер интернета, хостинг-провайдер или облачный провайдер. Короче говоря – где брался домен/IP-адрес/сервер - туда и надо обращаться за PTRом. Обычно у хостинг- или облачных провайдеров есть инструкция как сделать эту запись в автоматическом режиме.

Несколько слов – почему же так важна PTR?

Все достаточно просто. При отправке сообщения с почтового сервера на другой почтовый сервер, сервера обмениваются между собой информацией – так называемое «рукопожатие». Обмен этот выглядит примерно так:

• Здрасте! У нас письмо, для Вашего мальчика!
• Здравствуйте! А вы, собственно, кто?
• Я – MX.EXAMPLE.COM!
• Сейчас проверим! (идет запрос к НС-серверам отвечающим за домен EXAMPLE.COM с вопросом кто-же там таки почтовый? Выясняется IP-адрес и идет обратная проверка – разрешение IP-адреса в имя) Так… Минуточку! А вот Ваш НС говорит, что у вас там за почту отвечает – MAIL.EXAMPLE.COM, так что либо давайте письмо от него, либо не давайте вообще!

или

• Так у вас по этому IP-адресу отвечает сервер EXAMPLE.COM, а не MX.EXAMPLE.COM. Извините, мы ваше письмо не прнимем.

Еще сервер получателя сравнивает «баннер» - ответ почтовой программы почтового сервера отправителя с именем сервера. Естественно, что «баннер» тоже должен соответствовать имени.

«Банер»

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

SPF/DKIM/DMARC – записи

Эти записи не являются обязательными. Для локального почтового сервера они вообще не нужны по большому счету. Но если у Вас много корреспонденции, то отсутствие этих записей не просто моветон, из-за которого просто поморщат нос. Многие сервера на сегодняшний день уже второе-третье письмо без, как минимум, SPF-записи отправляют в «мягкий» спам, а все последующие – в спам без уведомления получателя. Все крупные почтовые сервера проводят обязательную проверку этих записей.

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

### Примеры настройки SPF записей

# C этого домена не принимать почту

v=spf1 -all

# С этого домена принимать почту только с адресов, указанных в MX записях

v=spf1 mx -all

# С этого домена принимать почту с адреса mail.example.org, с остальных

# маркировать сообщения как подозрительные

v=spf1 a:mail.example.org ~all

Как можно увидеть – при настройке SPF указывается:

• версия – она пока одна, первая;
• адреса серверов отправляющих. Можно указать просто «mx» - тобиш почтовые сервера из НС-записей и/или с помощью опции «а» – А-записи, ipv4 и ipv6 адреса. Так же возможно указать запись через «include:»

google.com. 3496 IN TXT "v=spf1 include:_spf.google.com ~all"

• То, что идет после «include:» - тоже ТХТ-запись в которой просто перечислены сервера, адреса, другие «инклуды»;
• заканчивается строка SPFа обязательным «-all» или «~all» - как видно из приведенного выше примера – это директива либо вообще не принимать с отсутствующих в описании серверов, либо принимать, но помечать как подозрительные.

DKIM-запись используется для подтверждения отправителя с помощью хеш-подписей, добавляемых в каждое сообщение проходящее от Вас через Ваш почтовый сервер. Подписи уникальны и не могут быть подделаны. Хеш-подпись в письме сравнивается с «ключом», записанным в специальное поле в НС-записях. Для этой записи требуется кроме добавления определенного поля в НС-записи ещё и настройка почтовой программы – чтобы она не забыла добавить ключ в проходящее сообщение. Для точных настроек DKIM в связке с почтовым ПО лучше обратится к документации, коей полно на просторах интернета.

DMARC – выставляет политики для серверов получателей в отношении полученных от Вас писем по результату проверки SPF и DKIM записей.

### Примеры настройки DMARC записей

# Отклонять все несоответствующие сообщения и посылать отчёт на адрес

# администратору v=DMARC1; p=reject; pct=100; rua=mailto:admin@example.org

# Посылать в спам 50% сообщений, которые не соответствуют политикам, остальное

# доставлять, и также посылать отчёт
v=DMARC1; p=quarantine; pct=50; rua=mailto:admin@example.org

# Пропускать все сообщения и отправлять отчёт администратору
v=DMARC1; p=none; rua=mailto:admin@example.org

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

Чтоб кратко подытожить, скажу, что из практики на сегодня к правильной настройке сервера, чтоб Ваша почта не попадала в СПАМ, хватает добавить SPF-запись. Но в идеале желательно настроить все перечисленное.