Настройки DNS для почты: чеклист критических параметров
Ошибки в одной DNS-записи способны нарушить прием почты, сорвать проверку отправителя или привести к отклонению сообщений принимающим сервером.
Проверяйте настройки DNS до запуска корпоративной почты, после переноса почтового сервера и при смене сервиса рассылок. Минимальный набор для диагностики: MX, SPF, DKIM, DMARC и PTR.
DNS не гарантирует попадание каждого письма во «Входящие». На решение принимающего сервера также влияют репутация IP и содержание сообщения. Но некорректные записи создают отдельные, устранимые причины отказа. Ниже приведен порядок проверки: от маршрутизации входящих сообщений к авторизации исходящих.
1. Проверьте MX: куда доставлять входящую почту
MX-запись указывает почтовые серверы, которые принимают сообщения для домена. В записи задается имя сервера и приоритет. Если для домена опубликовано несколько MX, отправляющая сторона ориентируется на значения приоритета: приоритетный сервер выбирается по правилам DNS и протокола доставки.
Проверьте, что MX ведут на актуальные имена серверов вашего почтового провайдера или собственной инфраструктуры. После миграции старые значения часто остаются в зоне. В результате часть отправителей продолжает обращаться к прежнему узлу, пока действует DNS-кэш, либо доставка ломается после отключения старого сервера.
Для первичной диагностики выполните:
dig MX example.comdig +short MX example.com
Замените example.com на свой домен. Сверьте полученные имена и приоритеты с параметрами, выданными почтовым сервисом. Если сервер находится на отдельном хосте, проверьте также разрешение его имени в A или AAAA. MX обычно указывает на имя узла, а не на IP-адрес.
Проверка корректности MX-записей
Проверьте каждый опубликованный MX, а не только запись с наименьшим значением приоритета. Убедитесь, что:
- имя сервера написано без опечаток и разрешается в адрес;
- сервер действительно принимает почту для нужного домена;
- приоритеты соответствуют схеме, заданной администратором или провайдером;
- устаревшие MX удалены после завершения миграции;
- записи не направляют почту на узел, который доступен только из внутренней сети.
Наличие MX в ответе dig подтверждает публикацию DNS-данных, но не доступность SMTP-службы. Если DNS выглядит корректно, а сообщения не приходят, отдельно проверяйте доступность принимающего MTA, его журналы и настройки домена на самом сервере.
MX отвечает на вопрос, куда отправитель должен доставить письмо. Он не подтверждает, что целевой сервер доступен и готов принять сообщение.
2. Проверьте SPF: кто вправе отправлять от имени домена
SPF публикуется в TXT-записи. Значение начинается с v=spf1 и перечисляет адреса или домены, которым разрешена отправка сообщений от имени домена. Принимающий сервер сопоставляет отправляющий IP с опубликованной политикой.
Найдите все TXT-записи корневого домена:
dig TXT example.comdig +short TXT example.com
В ответе найдите SPF-строку. Для одного домена должна быть одна SPF-политика. Если в DNS опубликовано несколько отдельных TXT-записей, начинающихся с v=spf1, настройка становится некорректной для обработки SPF. Не добавляйте вторую политику при подключении нового сервиса. Объедините разрешенные механизмы в существующую запись, следуя документации отправляющей системы.
Составьте перечень всех легитимных источников исходящей почты. В него могут входить корпоративный сервер, сервис рассылок, система заявок и другие приложения, которые отправляют сообщения с адресами вашего домена. Для каждого источника выясните, какой механизм авторизации рекомендует его оператор. После этого внесите нужные данные в единственную SPF-политику.
Типовые ошибки при диагностике SPF:
- в запись внесен IP старого сервера, а новый адрес пропущен;
- сервис рассылок включен в SPF не тем способом, который требует его документация;
- для разных систем созданы отдельные SPF-записи;
- политика изменена, но фактическая отправка идет с другого IP;
- разрешение выдано слишком широко и охватывает ненужные источники.
Не копируйте SPF-запись из чужой зоны и не добавляйте механизмы наугад. Сначала установите фактический маршрут исходящего сообщения. Проверяйте IP, который видит принимающая сторона, а не только адрес, указанный в панели хостинга. Если почта отправляется через внешний сервис, исходящий IP может принадлежать этому сервису.
3. Проверьте DKIM: подпись и селектор
DKIM позволяет принимающему серверу проверить цифровую подпись сообщения. Открытый ключ публикуется в TXT-записи по имени вида selector._domainkey.example.com. В значении записи используется тег v=DKIM1.
Селектор выбирается почтовой системой, которая подписывает сообщения. Это не произвольная часть адреса: сервер-получатель использует селектор из заголовка DKIM-подписи, чтобы найти соответствующий ключ в DNS. Поэтому запрос корневого домена не покажет, работает ли DKIM. Проверяйте точное имя селектора, настроенное в отправляющей системе.
Для просмотра записи используйте:
dig TXT selector._domainkey.example.comdig +short TXT selector._domainkey.example.com
Подставьте реальный селектор из конфигурации почтового сервера или сервиса рассылок. В DNS должна находиться запись с открытым ключом, а система отправки должна подписывать исходящие сообщения соответствующим закрытым ключом. Публикация ключа сама по себе не включает подпись.
При смене DKIM-ключа согласуйте обновление DNS и конфигурации подписывающего MTA. Если система использует новый селектор, а запись создана для старого, проверка подписи завершится ошибкой. Если ключ ротируется с сохранением прежнего селектора, проверьте последовательность обновления особенно внимательно: рассинхронизация между DNS и сервером отправки приводит к сбоям проверки.
Валидация DKIM требует проверки фактического сообщения. Получите письмо из целевого потока и изучите результат проверки подписи в его заголовках или в отчете принимающей системы. Одного успешного ответа dig недостаточно: DNS может отдавать ключ, который не соответствует ключу, используемому MTA.
4. Проверьте DMARC: политика и отчеты
DMARC публикуется в TXT-записи по имени _dmarc.example.com. Значение начинается с v=DMARC1. Политика задается тегом p: none, quarantine или reject. Адрес для получения агрегированных отчетов указывается тегом rua.
Сначала запросите запись:
dig TXT _dmarc.example.comdig +short TXT _dmarc.example.com
Затем проверьте, что запись опубликована именно под _dmarc и относится к нужному домену. Ошибка в имени узла делает политику невидимой для проверки DMARC. Несколько отдельных DMARC-политик для одного домена также требуют исправления: оставьте корректную запись и согласуйте ее содержимое с владельцами почтовых потоков.
Параметр p=none задает режим наблюдения. Он позволяет собирать отчеты без применения политики карантина или отклонения на основании DMARC. p=quarantine просит принимающую сторону помещать сообщения, не прошедшие проверку, в нежелательную почту или обрабатывать их как подозрительные. p=reject задает наиболее строгую политику отклонения таких сообщений.
Не переключайте политику сразу на reject, пока не инвентаризированы все системы, отправляющие почту от имени домена. Проверьте корпоративный MTA, CRM, сервисы рассылок, тикет-систему и приложения, которые формируют уведомления. Сопоставьте отчеты DMARC с известными источниками. Неизвестный отправитель может быть ошибочной интеграцией, забытым сервисом или попыткой подделки домена. Различайте эти случаи до ужесточения политики.
DMARC оценивает соответствие SPF и DKIM домену отправителя по правилам выравнивания. Поэтому успешная проверка SPF или DKIM отдельно не всегда означает успешный DMARC. Если сообщения легитимного сервиса не проходят DMARC, проверьте домены в видимых заголовках, результаты SPF и DKIM и соответствие доменов. Исправление зависит от конфигурации конкретного потока.
Ужесточайте DMARC после инвентаризации исходящих потоков. Политика, установленная без учета легитимных отправителей, способна блокировать собственную почту организации.
5. Проверьте PTR: обратное разрешение IP отправителя
PTR связывает IP-адрес отправляющего сервера с доменным именем. Это обратная DNS-запись. Для исходящей почты проверяйте публичный IP, с которого сообщение действительно выходит в интернет, и имя, которое сервер сообщает в HELO/EHLO.
Запрос PTR выполняется для IP-адреса:
dig -x 192.0.2.10dig +short -x 192.0.2.10
Адрес 192.0.2.10 здесь приведен как пример формата команды. Подставьте фактический публичный IP исходящего узла. Сверьте PTR с именем сервера, используемым в SMTP-сессии. Отсутствие соответствия между PTR и HELO/EHLO повышает риск блокировки почты принимающими системами.
PTR обычно управляется владельцем адресного диапазона или хостинг-провайдером. Если IP выделен облачной платформой, проверьте, доступно ли изменение обратной записи в панели управления. Если запись назначает провайдер, передайте ему требуемое имя узла и дождитесь подтверждения. Изменение локальной DNS-зоны домена не заменяет настройку PTR для IP.
После обновления проверьте прямое разрешение имени из PTR. Оно должно вести к адресу, согласованному с инфраструктурой. Если SMTP-сервер отправляет с нескольких IP, проверяйте каждый адрес отдельно. Проверка только основного узла не выявит расхождение у резервного MTA или отдельного сервера рассылок.
6. Дождитесь обновления DNS и локализуйте источник ошибки
После изменения зоны результат может отличаться у разных резолверов. Обновление и распространение DNS-записей может занимать до 72 часов. Это не означает, что каждый запрос будет задержан на весь этот срок: срок зависит от кэширования и параметров записей. Не меняйте конфигурацию повторно только потому, что один проверочный сервис пока показывает прежнее значение.
Сравните ответы авторитетного DNS-сервера и публичного резолвера:
dig NS example.comdig @ns1.example.net MX example.comdig @8.8.8.8 MX example.comdig @1.1.1.1 TXT example.com
Замените имена серверов и домен на фактические. В запросах для SPF, DKIM и DMARC указывайте точные имена записей. Если авторитетный сервер уже отдает новое значение, а рекурсивный резолвер показывает старое, вероятна задержка обновления кэша. Если оба источника отдают неправильный ответ, исправляйте зону у DNS-хостера или регистратора, который обслуживает авторитетные NS.
Порядок диагностики должен отделять DNS от SMTP:
1. Получите ответ авторитетного сервера для нужной записи.
2. Сравните его с ответом нескольких рекурсивных резолверов.
3. Проверьте, что запрос сделан для правильного домена и селектора.
4. Сопоставьте опубликованные IP и имена с реальным маршрутом письма.
5. Проверьте журнал MTA и результат проверки у сервера-получателя.
Если DNS-записи корректны, переходите к SMTP-логам, TLS, доступности порта, очереди сообщений и репутации IP. Не пытайтесь исправить ошибку маршрутизации изменением DMARC. И не меняйте SPF, если проблема находится в MX или недоступности принимающего сервера. Диагностика должна идти по компонентам, которые участвуют в конкретном потоке.
Итоговый чеклист
Перед вводом почты в эксплуатацию и после изменений в инфраструктуре выполните проверку по порядку:
- MX указывают на действующие серверы приема, приоритеты соответствуют схеме провайдера.
- Имена MX разрешаются в актуальные адреса; устаревшие узлы удалены после миграции.
- SPF опубликован одной TXT-политикой и включает все легитимные источники отправки.
- DKIM-запись доступна по точному имени селектора, а отправляющая система использует соответствующий закрытый ключ.
- DMARC опубликован под
_dmarc, политика и адресruaсоответствуют этапу внедрения. - PTR настроен для каждого публичного IP исходящей почты и согласован с HELO/EHLO.
- Ответ авторитетного DNS сравнен с рекурсивным; изменениям дано время пройти через кэши.
- Фактические результаты SPF, DKIM и DMARC проверены на сообщениях из каждого почтового потока.
Сохраняйте исходные значения зоны и фиксируйте время каждого изменения. При сбое это позволит отличить новую ошибку конфигурации от задержки DNS-кэша и быстро вернуть рабочее состояние.