Pull to refresh

DNS записи для почтовых серверов

Reading time6 min
Views78K


Представьте, что вы в реальной жизни получили конверт, где в поле “Отправитель” написано имя вашего старого друга. Можете ли вы, не открыв и не прочитав письма, точно сказать – это конверт от вашего старого друга или какого-то злоумышленника?

Именно эта задача стоит перед почтовыми серверами — просто взглянув на конверт определить, не врёт ли поле отправитель. Для этого почтовый сервер обращается к тому механизму, который в интернете служит для подтверждения владения доменом – DNS серверу.

Видео


Previous < Про порты и шифрование в почтовых серверах



Сразу оговорюсь, что под полем «отправитель» я подразумеваю не поле «from» в самом сообщении, а адрес сервера отправителя.

Почтовый сервер очень зависим от DNS. Единственный случай, когда почтовому серверу не нужен DNS сервер – когда это локальный почтовый сервер, который не отправляет и не получает письма от других серверов.



Теперь, давайте определимся со всеми необходимыми DNS записями для почтовых серверов. Начнём с “А” записи, которая преобразует имя в IP адрес. Кстати, А – от слова адрес. Частые примеры имён для почтовых серверов – mx.example.org, mail.example.org, smtp.example.org. Несколько А записей с одним именем и разными IP адресами позволят балансировать трафик на разные почтовые сервера при условии настройки round robin DNS.



MX запись – от слова мейл эксчейнджер – нужна, чтобы другие почтовые сервера могли узнать, на какой адрес следует отправлять почту по указанному домену получателя. Если вы планируете использовать субдомены, допустим, user@support.example.org, то и для субдомена понадобится отдельная MX запись. Также, вы можете указывать несколько MX записей для одного домена, указывающие на разные адреса и выбирая приоритет. Скажем, вы хотите, чтобы по умолчанию вся почта отправлялась на сервер mx1.example.org, тогда даёте ему приоритет ближе к нулю. Чем менее приоритетнее сервер, тем большее число вы ему назначаете. Максимальное значение – 65535, но обычно приоритеты выставляют 10, 20, 30 и т.п. Приоритеты могут совпадать, тогда либо DNS балансирует эти записи, если так настроено на DNS сервере, либо отправитель будет использовать первый доступный сервер.



PTR запись – обратная DNS запись, которая преобразует IP адрес в имя. Основная задача данной записи для почтового сервера – отсеять большую часть спама. Эта запись позволяет определить имя хоста, с которого приходит почта. При получении почты, почтовый сервер делает два запроса – на получение имени по IP адресу и на получение IP адреса по имени отправителя. Если результаты совпадают – значит сервер отправитель тот, за кого себя выдаёт. В отличии от остальных записей, такую запись можно создать только в случае владения или аренды IP адреса.



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



SPF – запись, которая разрешает определённым адресам отправлять сообщение с указанного домена, и говорит, что делать если сообщение пришло с другого адреса. Допустим, вы, как отправитель, заявляете, что разрешаете отправлять почту из домена example.org только адресу mail.example.org. А если сообщение придёт не с этого адреса, но в поле отправитель указан домен example.org, то смело отклонять это сообщение как недоверенное. По идее, сервера получатели должны проверить вашу SPF запись и действовать согласно тому, что вы выставили, но получатель может игнорировать ваши “наставления” по своему желанию. SPF запись нужна для защиты от спуфинга – атак, когда злоумышленник притворяется одним из пользователей отправителя.

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

# C этого домена не принимать почту
v=spf1 -all

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

# С этого домена принимать почту с адреса mail.example.org, с остальных маркировать сообщения как подозрительные
v=spf1 a:mail.example.org ~all

При настройке SPF записи вы указываете версию SPF, а она пока одна – первая. Дальше указываете адреса, которым разрешаете отправлять сообщения с данного домена. В качестве адресов может быть просто запись “mx” – то есть те сервера, которые у вас указаны в MX записях. Также можно прописать дополнительные адреса с помощью опций a – по A записи, по ipv4 и ipv6 адресам и т.п. После разрешенных адресов указывается опция all для всего того, что не подошло под ваше правило. Вы можете советовать получателю разрешить все сообщения с любых адресов по вашему домену, запретить, пометить как несоответствующее, но пропустить, либо на усмотрение получателя. Полный синтаксис и все опции SPF я дам в виде ссылки в конце.
И хотя SPF указывает на адреса, кому разрешено отправлять сообщения, есть вероятность подмены сообщения кем-то посередине. Для предотвращения таких атак есть другая DNS запись.



DKIM – запись, которая используется для подтверждения отправителя с помощью подписей, которые добавляются в каждое сообщение. Вкратце, ваш сервер добавляет в исходящие сообщения уникальный хеш, который можно расшифровать с помощью публичного ключа из соответствующей DNS записи. Если даже кто-то подменит сообщение, он не сможет подделать вашу цифровую подпись. Тем самым, DKIM также нужен для защиты от спуфинга.
Но для DKIM недостаточно просто добавить DNS запись, нужно также сгенерировать ключи и настроить почтовый сервер для работы с 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

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



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



Забыл упомянуть. В сети есть пара важных инструментов для проверки ваших настроек.
Один из самых удобных инструментов — mail-tester. Всё просто:
1. Заходите на сайт, копируете почтовый адрес, который выдал вам сервис.
2. Отправляете на этот адрес со своего домена с любого ящика сообщение. Желательно, чтобы сообщение не было пустым, а содержало какой-никакой текст.
3. Возвращаетесь на сайт, нажимаете «Затем проверьте оценку».
4. Проверяете результат. Портал проверит все возможные настройки, как DNS — те же SPF, DKIM и DMARC записи, так и покажет, попал ли ваш сервер в черные списки и т.п. Также он выдаст рекомендацию, если у вас есть ошибки в настройках.
5. Если были ошибки — исправляете а затем опять отправляете сообщение и снова проверяете результат. Если проблемы были связаны с DNS записями, убедитесь, что ваши изменения в DNS применились(к примеру, той же командой dig), прежде чем пробовать заново.
НО! Сервис даёт вам всего 3 бесплатные попытки в день, поэтому, желательно, исправить все ошибки, а затем заново проверять.



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



Если вы настроили DKIM и хотите убедиться в правильности, можете отправить сообщение на тот же gmail аккаунт, а затем открыть сообщение в исходном виде и попытаться найти строку DKIM=pass. Либо воспользоваться готовым сервисом — dkimvalidator. Принцип работы такой же, как у mail-tester — отправляете сообщение на сгенерированный адрес и смотрите результат.

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

Полезные ссылки:
Что такое SPF
Загадки и мифы SPF
What Is DKIM?
HowTo: DMARC
Tags:
Hubs:
+4
Comments19

Articles