Исходим из того, что все умные, но многие не знают, как ходит почта и вопросы эти на 99% исходят из базы.
База:
Для работы почты почтовый сервер должен быть доступен из Internet
Почта приходит, потому что указаны MX-записи
Почта уходит, потому что настроена в соответствии с безопасностью SPF, DKIM, DMARC
Разберёмся по порядку, что должно быть настроено, чтобы работала почта.
Определяемся со схемами функционирования почтовой системы
Базовая схема предполагает, что почта проходит через фаервол/роутер, на нём соответственно входящий NAT на TCP 25й порт почтового сервера и разрешающие правила
В случае, если интернета нет, почтовый сервер недоступен.
Более продвинутый вариант предполагает использование нескольких ISP провайдеров, промежуточные Email Security Gateway и набор почтовых серверов за ними
В данном реализации почта будет приходить по нескольким провайдерам одновременно и в случае сбоя у одного, переключаться на второго.
Ну и современная база: почтовый сервис где-то в облаке и "Я всё делаю, как рекомендует Яндекс, Гугл, Мру!" Сюда же можно добавить Email Security GW, как сервис.
Схемы просты и понятны, но сами по себе схемы не объясняют, почему приходит почта.
Настройка DNS
Переходим к следующему шагу: DNS записи
Для того чтобы письмо пришло требуется каким-то образом сообщить, что ваш домен обслуживает данный конкретный сервер. Для этого нужен DNS, а именно: MX записи. Только MX записи отвечают за указание адреса почтового сервера.
example.com. IN MX 10 mail.example.com. mail.example.com. IN A 9.9.9.9
Указанная выше MX запись по факту сообщает, что для домена example.com почтовым сервером является сервер mail.example.com, а живёт он на IP адресе 9.9.9.9 (об этом нам говорит уже A-запись). Таким образом вся входящая почта для домена example.com будет отправляться на tcp://9.9.9.9:25
Самая объёмная часть. Исходящая почта.
Для того чтобы ваше письмо дошло необходимо пройти довольно большое количество проверок, в базе: PTR, SPF, DKIM, DMARC
По порядку: PTR запись - имя, которое возвращает IP адрес. Сейчас используется всё реже, но в РФ идут своим путём и зачастую требуется.
Проверяем так: nslookup -type=PTR 9.9.9.9 8.8.8.8, соответственно должно быть mail.example.com. Задаётся у вашего провайдера, у облачников часто нет самостоятельной возможности указать PTR, пишем в саппорт.
Следующая по порядку, но одна из основных по значимости: SPF запись. По факту это текстовая запись в DNS зоне вашего домена, которая сообщает о том, кому можно слать почту от имени вашего домена. И вот здесь случается миллион ошибок.
Вероятно от незнания, но база:
В рамках одного домена SPF запись может быть только одна. Если их две, то все проверки SPF пойдут на мороз.
SPF запись не должна быть слишком большой (не более 10 серверов)
Можно всех обмануть и разрешить отправлять со всех MX и A записей в вашем домене
Часто встречаются такие вот ошибки:
Первое - записи две, второе - они себе противоречат. Вероятнее всего, компания купила домен на timeweb.ru, где в дефолте уже указаны SPF самого timeweb, а затем администратор (вероятно от непонимания) добавил вторую запись с редиректом на mail.ru.
Нет смысла выяснять, что и где работает, но правильная запись, вероятно, должна выглядеть так: v=spf1 include:_spf.timeweb.ru include:_spf.mail.ru ~all
Давайте по-простому опишем, что и как должно выглядеть в SPF записи: v=spf1 a mx include:_spf.mail.ru ip4:9.9.9.9 ~all
a - все А-записи в вашем домене
mx - все MX-записи в вашем домене
include:_spf.mail.ru - все SPF записи mail.ru
ip4:9.9.9.9 - непосредственно IP адрес
~all - не парьтесь, поскольку у вас есть сторонние сервисы, хватит и ~
Одной из самых верных проверок, является проверка DKIM. По своей сути, это подписание писем электронной подписью на уровне сервера. Открытый ключ указываем в своём DNS - по нему проходит проверка, закрытый - на почтовом сервере, им подписываются письма.
Данный механизм прост до безобразия, но нужно помнить, что длина ключа должна быть 2048 бит, а закрытый ключ хранить как зеницу ока.
Есть как онлайн генераторы (не доверяем), встроенные в почтовый сервис, а можно сделать и ручками.
Ну и напоследок: DMARC - политика, определяющая, что делать с письмами от вашего домена в случае, если они не прошли проверки. Такая же текстовая запись в DNS зоне вашего домена. По факты мы сообщаем почтовому серверу получателя.
Вот пример: v=DMARC1; p=none; rua=mailto:reports@example.com; ruf=mailto:forensic@example.com; fo=1
p=none (может быть reject, quarantine) - ничего не делать с письмами, но администратор будет получать отчёты. Рекомендуется использовать только при тестировании/настройке
rua - адрес для агрегированных отчётов
ruf - для детальных
fo=1 (отчёт создаётся если не пройдет проверка или DKIM или SPF). 0 - обе проверки, s - не пройдена проверка SPF, d - DKIM
С базой закончили. В дальнейшем планирую рассказать, как работают всякие вкусные: Dynamic Reputation Lists, Sandbox, White/Black/Gray Lists, Email throttling, URL Defense и т.д. А если меня хватит, то рассмотрим настройку различных почтовых шлюзов/серверов.