Настройка DNS адрес: как работает маршрутизация почты

Это запасной сценарий протокола SMTP, а не надёжная схема почтовой инфраструктуры: веб-сервер и сервер приёма почты могут быть разными узлами.

Настройка DNS-адреса для почты сводится не к одной записи. Нужны корректные MX и адреса серверов, на которые они указывают. Для защиты исходящей почты добавляются SPF, DKIM и DMARC. Смешение этих задач приводит к типичной ошибке: домен принимает письма, но исходящие сообщения не проходят проверку подлинности — или наоборот.

Как MX направляет письмо

Отправитель обычно не знает, где размещён почтовый ящик адресата. Его MTA запрашивает DNS домена получателя и получает список почтовых серверов из MX-записей. Затем выбирает сервер по приоритету и устанавливает SMTP-соединение.

Упрощённо маршрут выглядит так:

1. MTA извлекает домен из адреса получателя. Для user@example.com это example.com.

2. Запрашивает у DNS список MX-записей домена.

3. Сортирует полученные серверы по числовому значению приоритета.

4. Находит IP-адрес выбранного сервера через A или AAAA-запись его имени.

5. Подключается к серверу по SMTP и передаёт письмо для дальнейшей доставки.

MX не содержит IP-адрес. Он содержит имя почтового сервера, например mx1.example.net. Это имя должно разрешаться в IP через A- или AAAA-запись. Если MX указывает на имя, для которого нет адресной записи, маршрут неполон: отправляющий сервер не сможет установить соединение.

Проверяйте не только наличие MX, но и всю цепочку разрешения:

Для подключения домена к внешней бизнес-почте провайдер обычно выдаёт готовые значения MX и дополнительные TXT-записи. Переносите их без переименования хостов и без подстановки IP вместо имени MX. Если почта размещена на собственном сервере, настройте DNS так, чтобы имя почтового узла указывало на его адрес, а MX домена — на это имя.

Приоритеты MX: меньшее число — первый выбор

Приоритет MX задаётся числом. Чем число меньше, тем раньше MTA попробует подключиться к серверу. Поэтому MX с приоритетом 10 предпочтительнее MX с приоритетом 20.

Например, домен может публиковать два сервера:

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

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

Есть и обратный случай. Если домен не должен принимать почту, публикуют Null MX: запись с приоритетом 0 и значением .. Она явно сообщает, что для домена нет почтового сервера. Это не то же самое, что случайно забыть MX: отсутствие записи может привести к попытке доставки на A- или AAAA-адрес самого домена.

Приоритет MX — не оценка важности сервера. Это порядок попыток: сначала меньшее число, затем большее.

TTL и распространение изменений

TTL задаёт срок, в течение которого DNS-резолвер может использовать сохранённый ответ. Значение измеряется в секундах. Если TTL MX равен 3600, резолвер может кэшировать запись примерно час, прежде чем запросить её заново. Изменение в панели DNS не очищает кэши, которые уже получили прежний ответ.

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

Порядок миграции:

1. Проверьте текущие MX, адресные записи серверов и TTL.

2. Уменьшите TTL заранее. Сделайте это до переключения, а не одновременно с ним.

3. Подготовьте новый сервер и проверьте его приём почты для нужного домена.

4. Измените MX и связанные A/AAAA-записи, если меняется адрес почтового узла.

5. Оставьте старый сервер доступным на период обновления кэшей. Иначе часть отправителей продолжит доставлять письма по старому маршруту.

6. Проверьте входящую и исходящую почту, затем верните TTL к значению, подходящему для штатной работы.

Распространение DNS-записей может занимать от нескольких минут до 24–48 часов. Точная задержка зависит от ранее закэшированных ответов и резолверов отправляющих систем. Поэтому обещание мгновенного переключения некорректно даже при коротком новом TTL.

Для MX-записей одного домена задавайте одинаковый TTL. Разные TTL у записей одного набора одного типа и имени считаются устаревшей практикой и затрудняют предсказание того, какой состав MX увидит резолвер.

MX, SPF, DKIM и DMARC решают разные задачи

MX отвечает за входящий маршрут. SPF, DKIM и DMARC участвуют в проверке исходящей почты и защите домена от подделки. Они не заменяют MX и не перенаправляют письма на почтовый ящик.

SPF публикуют в TXT-записи корневого домена. Она описывает, каким серверам разрешено отправлять почту от имени домена. В запись должны попасть реальные источники отправки: корпоративный сервер, сервис рассылок и другие системы, которые действительно используют домен в отправителе. Не копируйте чужой SPF и не создавайте несколько независимых SPF-записей для одного домена: итоговая политика должна соответствовать всей схеме отправки.

DKIM добавляет к исходящему письму криптографическую подпись. Открытый ключ публикуется в DNS как TXT-запись по имени, связанному с селектором. Закрытый ключ хранится на отправляющем сервере. Если селектор в DNS не совпадает с селектором подписи, проверка не пройдёт.

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

MX принимает почту. SPF, DKIM и DMARC подтверждают, кто отправляет её от имени домена. Настройте обе стороны отдельно.

Почему почта не работает после настройки DNS

Сначала определите направление сбоя. Если письма не приходят, проверяйте MX и доступность принимающего сервера. Если письма не отправляются или попадают в спам, проверяйте исходящий MTA и аутентификацию. Если проблема возникает только у части адресатов, учитывайте DNS-кэширование и различия в проверках у принимающих систем.

Типовые ошибки конфигурации:

• MX указывает не на то имя. Проверьте, что в записи стоит hostname сервера, а не адрес IP и не веб-адрес панели управления.
• У имени из MX нет A или AAAA. Разрешите адресное имя почтового узла. Для опубликованной AAAA-записи убедитесь, что IPv6 действительно настроен и доступен.
• Перепутан приоритет. Запись с числом 20 будет запасной по отношению к записи с числом 10, а не наоборот.
• Оставлен старый MX. После смены провайдера прежняя запись может продолжить направлять часть писем на старый сервер. Удаляйте её только после проверки миграции и с учётом TTL.
• Изменён только MX. Новый маршрут может быть правильным, но исходящая почта всё ещё будет не проходить SPF или DKIM.
• Создано несколько SPF-записей. Сведите политику к одной записи TXT для домена и включите в неё необходимые источники отправки.
• Неверно выставлен TTL. Значение TTL не исправляет ошибку в записи и не очищает кэши, уже получившие старый ответ.
• Ожидается, что DNS создаст почтовый ящик. MX задаёт маршрут, но не создаёт учётные записи и не включает обработку домена на сервере. Настройте домен и адреса у почтового провайдера или на собственном MTA.

При отсутствии MX по RFC 5321 отправляющий сервер может попробовать доставить письмо на A- или AAAA-адрес самого домена. Не используйте это поведение как замену явной конфигурации. Если веб-сервер не принимает SMTP для домена, доставка завершится ошибкой; если принимает, маршрут окажется неочевидным для сопровождения.

Порядок проверки DNS-почты

Проверяйте конфигурацию от маршрута к аутентификации. Не начинайте с DMARC, если домен ещё не направляет входящую почту на нужный сервер.

1. Запросите MX домена и сравните имена и приоритеты с настройками почтового провайдера.

2. Разрешите каждое имя MX в A и AAAA. Убедитесь, что адреса соответствуют реальным почтовым узлам.

3. Проверьте, что принимающий сервер настроен обслуживать домен и почтовые ящики.

4. Сверьте TTL и учтите, когда резолверы могли получить прежние значения.

5. Проверьте SPF для всех легитимных источников исходящей почты.

6. Сверьте DKIM-селектор в DNS с селектором, который использует MTA или сервис рассылок.

7. Проверьте DMARC и не ужесточайте политику до инвентаризации отправителей.

8. Отправьте тестовые сообщения в обоих направлениях и изучите результат SMTP-диалога и заголовки полученного письма.

Настройка DNS-записей для почтового сервера считается завершённой не тогда, когда панель регистратора показывает сохранённые значения, а когда маршрут проверен снаружи и сервер принимает почту для нужного домена. Для бизнес-почты зафиксируйте текущие значения MX, SPF, DKIM, DMARC и TTL. Это упростит откат при миграции и позволит отличить сбой DNS от ошибки конфигурации MTA.

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