IP и DNS настройки: чеклист подготовки почтового сервера

Типовой дефект: IP-адрес отправителя разрешается в одно имя, PTR возвращает другое, а сервер представляется по SMTP третьим значением в HELO/EHLO. Получатель видит несоответствие и снижает доверие к потоку или отклоняет письмо.

Подготовьте связку IP и DNS до запуска исходящей почты. Проверьте маршрутизацию MX и A, обратное разрешение PTR, авторизацию SPF, подпись DKIM и политику DMARC. Эти записи решают разные задачи; наличие одной не заменяет остальные.

Маршрутизация и идентификация: роль MX и A-записей

Начните с разделения входящего и исходящего направления. MX указывает отправителям, на какие хосты доставлять входящую почту для домена. A связывает имя почтового узла с IPv4-адресом. Для IPv6 используется AAAA. Если MX указывает на mail.example.com, у этого имени должна быть корректная адресная запись.

Пример логики конфигурации:

Не направляйте MX на IP-адрес: в качестве цели указывается доменное имя почтового узла. Не используйте в MX имя, у которого нет адресной записи. Иначе принимающий сервер не сможет разрешить маршрут до конечного узла.

Установите TTL с учётом режима эксплуатации. Значение 3600 секунд подходит как ориентир для обычной рабочей конфигурации, но перед миграцией его часто снижают заранее, чтобы ускорить обновление DNS-кэшей. Понимайте ограничение: снижение TTL не очищает кэши мгновенно и не отменяет время, оставшееся у уже полученных ответов.

Проверьте записи снаружи авторитетной DNS-панели. Запрос из панели показывает, что внесено в зону; запрос к публичному резолверу показывает, что уже доступно получателям. После изменения дождитесь обновления с учётом TTL. При диагностике фиксируйте имя, тип записи, полученный ответ и время запроса. Без этого легко перепутать ошибку зоны с устаревшим кэшем.

PTR и обратная зона: настройка на стороне владельца IP

PTR связывает IP-адрес с доменным именем. Для почтового сервера это часть идентификации исходящего узла. Настройка обратной зоны DNS обычно находится не у регистратора домена, а у организации, контролирующей адресный диапазон: хостинг-провайдера, облачной платформы или владельца блока IP.

Задайте PTR для выделенного исходящего IP. Затем настройте прямое разрешение этого FQDN через A-запись на тот же адрес. Например, если PTR адреса возвращает mail.example.com, запрос A для mail.example.com должен вести на IP отправителя. Это проверка согласованности прямой и обратной зон.

Отдельно настройте имя, которое MTA передаёт в HELO/EHLO. Оно должно соответствовать сетевой идентичности сервера и не быть случайным внутренним именем вроде localhost или временного hostname виртуальной машины. Сверьте три значения:

1. PTR для исходящего IP возвращает публичное FQDN почтового узла.

2. A-запись этого FQDN возвращает тот же IP.

3. HELO/EHLO использует согласованное имя.

PTR, A и HELO/EHLO должны описывать один и тот же почтовый узел. Расхождение в этой связке становится причиной отказов на стороне получателя.

Не пытайтесь исправлять PTR в обычной панели DNS домена, если адресный блок вам не делегирован. Создайте запрос провайдеру, указав IP и требуемое FQDN. После внесения проверьте результат внешним DNS-запросом. Если сервер использует несколько исходящих IP, настройте и проверьте каждый адрес отдельно.

Для динамического или общего адреса исходящая почта требует отдельной оценки. PTR может быть недоступен для изменения, а репутация адреса зависит от других пользователей. Для производственной отправки предпочтителен выделенный IP с управляемой обратной зоной. Сам факт выделения адреса не гарантирует доставку: фильтры учитывают и другие сигналы, а точные лимиты отправки зависят от принимающего провайдера.

SPF: список разрешённых отправителей

SPF публикуется как TXT-запись домена. Она задаёт, какие IP-адреса и серверы вправе отправлять почту от его имени. Получатель сопоставляет адрес соединения с опубликованной политикой. Ошибка в SPF может привести к провалу проверки, даже если сам MTA работает без сбоев.

Соберите полный перечень источников отправки до публикации записи: основной MTA, почтовый сервис, CRM, система уведомлений, платформа рассылок. Если сторонний сервис отправляет с вашего домена, он должен быть учтён предусмотренным поставщиком способом. Удаление действующего источника из SPF ломает авторизацию его писем.

Базовая форма начинается с v=spf1. Дальше указываются механизмы и завершающая политика. Не создавайте несколько независимых SPF-записей для одного домена: получатель ожидает одну действующую SPF-политику. Если источников несколько, объедините их в единую запись согласно требованиям каждого отправителя.

Перед включением жёсткой политики проверьте, что перечислены все легитимные потоки. Типовые ошибки:

• забыли сервер транзакционных уведомлений или CRM;
• опубликовали несколько TXT-записей с v=spf1;
• указали устаревший IP после миграции;
• включили слишком широкое разрешение и фактически авторизовали лишние узлы;
• изменили запись, но проверяют результат до обновления DNS-кэша.

Не считайте SPF полной защитой от подделки домена. Он проверяет авторизацию источника в рамках SPF-механизма, но сам по себе не заменяет DKIM и DMARC. Кроме того, пересылка сообщений может изменить сетевой источник и повлиять на результат SPF-проверки у конечного получателя. Именно поэтому аутентификацию настраивают комплектом.

DKIM: подпись исходящих сообщений

DKIM добавляет к письму криптографическую подпись. MTA формирует её закрытым ключом, а получатель проверяет открытым ключом из DNS. Публичный ключ размещается в TXT-записи по имени вида selector._domainkey.example.com. Селектор связывает DNS-запись с конфигурацией подписывающего сервера.

Настройте DKIM на каждом сервисе, который отправляет сообщения от домена. У разных платформ могут быть разные селекторы и ключи. Запись одного сервиса не подтверждает подпись другого. Проверьте, что MTA действительно подписывает исходящие письма нужным доменом, а DNS содержит соответствующий ключ.

Порядок внедрения:

1. Сгенерируйте или получите пару ключей средствами используемого MTA или почтовой платформы.

2. Сохраните закрытый ключ только на стороне отправителя. Ограничьте доступ к нему правами системной учётной записи.

3. Опубликуйте открытый ключ в TXT-записи с точным селектором, выданным отправляющей системой.

4. Дождитесь обновления DNS и выполните тестовую отправку на внешний адрес.

5. Проверьте заголовки результата: наличие DKIM-подписи и успешную проверку у получателя.

В DNS-значении используется версия, начинающаяся с v=DKIM1. Не копируйте ключ в произвольную запись домена: имя селектора должно совпасть с тем, который использует MTA. При ротации ключей сначала опубликуйте новый открытый ключ, переключите подпись на новый селектор и только после этого удаляйте старую запись. Иначе часть сообщений может проверяться ключом, которого уже нет в DNS.

DKIM подтверждает целостность подписанной части сообщения и связь подписи с доменом. Он не шифрует письмо и не подтверждает, что содержимое безопасно. Для доставки важен результат проверки, но также важна согласованность домена подписи с доменом отправителя, которую учитывает DMARC.

DMARC: политика после SPF и DKIM

DMARC задаёт получателю политику обработки сообщений, которые не проходят требуемые проверки SPF и DKIM, и позволяет получать отчёты. Запись размещается в TXT для имени _dmarc домена. В ней задаются версия, политика и адреса отчётности.

Политика может быть одной из трёх:

• p=none — наблюдение и сбор отчётов без указания карантина или отклонения;
• p=quarantine — просить получателя отправлять не прошедшие проверку сообщения в спам или карантин;
• p=reject — просить отклонять такие сообщения.

Начинайте с p=none, если источники отправки ещё не инвентаризированы. Собирайте отчёты и сопоставляйте обнаруженные потоки с системами организации. Не переключайте политику на quarantine или reject, пока не выяснено, откуда отправляются легитимные письма и проходят ли они аутентификацию.

DMARC опирается на SPF и DKIM с проверкой выравнивания доменов. Успешной проверки недостаточно, если идентификатор не согласован с доменом в адресе отправителя по правилам DMARC. Проверьте домен SPF, домен DKIM-подписи и домен в поле отправителя. Для каждого легитимного сервиса подтвердите, что хотя бы один из допустимых механизмов проходит проверку и выравнивание.

Указывайте адрес отчётности, который действительно принимает сообщения и регулярно разбирается. Отчёты могут быть объёмными и технически неудобными для ручного чтения; заранее определите, кто отвечает за их обработку и как обнаруженные источники будут сверяться с реестром сервисов. Политика без наблюдения не даёт оператору достаточной картины для безопасного ужесточения.

Финальная проверка перед запуском

Проведите проверку по каждому домену отправителя и каждому исходящему IP. Не ограничивайтесь основным корпоративным доменом: поддомены рассылок, систем уведомлений и отдельных бизнес-приложений могут иметь собственные DNS-зоны и политики.

Последовательность контроля:

1. Проверьте MX и убедитесь, что целевые почтовые хосты разрешаются через A или AAAA.

2. Проверьте привязку IP к домену: прямое разрешение почтового FQDN должно соответствовать фактическому адресу сервера.

3. Запросите PTR у владельца IP и сверьте его с A и HELO/EHLO.

4. Проверьте SPF на единую запись и полный список отправляющих систем.

5. Проверьте DKIM для каждого используемого селектора тестовым сообщением.

6. Начните DMARC с мониторинга, разберите легитимные источники и только затем ужесточайте политику.

7. Повторите внешние DNS-запросы после обновления записей и проверьте результат на письме, доставленном независимому почтовому провайдеру.

Фиксируйте исходное и ожидаемое значение каждой записи. При миграции меняйте конфигурацию в контролируемом порядке: подготовьте новые адресные и аутентификационные записи, проверьте их распространение, переключите MTA, затем удаляйте устаревшие значения. Такой порядок снижает риск разрыва доставки и упрощает откат.

Настроенная DNS-зона не гарантирует попадание в папку «Входящие». Она устраняет ошибки маршрутизации и аутентификации, но не отменяет репутационные и содержательные фильтры получателя. Для стабильной работы обеспечьте согласованность MX, IP, PTR, HELO/EHLO, SPF, DKIM и DMARC; затем контролируйте результаты отправки и отчётность.