Когда «почта не ходит», чаще всего виноват DNS: неверные MX, не сходятся A/AAAA для хоста MX, сломан TXT со SPF или домен не проходит DMARC/DKIM. Ниже — практический разбор, как MX работает в реальности, как его правильно настраивать и как быстро находить типовые ошибки, которые бьют по доставке.
Как работает доставка почты через DNS (короткая модель)
Отправляющий сервер (MTA) делает DNS-запрос к домену получателя и ищет MX-записи. Каждая MX указывает:
- приоритет (число): меньше — важнее;
- имя почтового хоста (FQDN), например
mx1.example.com.
Дальше MTA резолвит имя MX-хоста в IP-адреса через A/AAAA и пытается доставить письмо по SMTP на найденные адреса. Если основной сервер недоступен — пробует следующий MX по приоритету (или другой IP того же хоста, если их несколько).
MX не содержит IP-адреса напрямую. MX всегда ссылается на имя, а IP берётся из
A/AAAAэтого имени.
Что происходит, если MX отсутствует
Если MX-записей нет, RFC допускают fallback: многие отправители попробуют доставку на A/AAAA самого домена (то есть на example.com). На практике это часто означает «почта уедет на веб-сервер», где SMTP не слушают, и вы получите отказы с формулировками вроде «connection refused» или «no route to host».
MX на практике: приоритеты, несколько записей и отказоустойчивость
Самая частая рабочая схема — два MX:
10 mx1.example.com.— основной;20 mx2.example.com.— резервный.
Отправитель сначала попробует mx1. Если он недоступен сетево или по SMTP — попробует mx2. Если оба недоступны, письмо встанет в очередь на стороне отправителя и будет ретраиться (обычно от часов до нескольких дней — зависит от политики отправителя).
Если вы держите почтовую инфраструктуру на отдельном сервере, удобнее и безопаснее делать это на VDS: вы контролируете сетевые правила, PTR/IPv6 и обновления, а DNS-правки для MX/A/AAAA получаются предсказуемыми.
Равные приоритеты и «балансировка»
Если задать одинаковый приоритет двум MX, часть отправителей будет выбирать случайно и распределять трафик. Но это не гарантированный балансировщик: поведение сильно зависит от реализации MTA, кеширования и даже локальных политик. Для предсказуемости чаще делают явный основной/резервный, а «баланс» решают на стороне MTA или через специализированную инфраструктуру.
Почему «меньше число = выше приоритет» постоянно путает
MX-приоритет — это «стоимость» маршрута. Меньше число — «дешевле», значит выбирается раньше. Классика тикетов: админ ставит 50 «чтобы было главным», а в итоге главным становится 10.
Связка MX с A/AAAA: без неё почта не поедет
MX указывает на имя. Это имя обязано резолвиться в IP. Проверяем:
- есть ли
A(IPv4) и/илиAAAA(IPv6) уmx1.example.com; - правильные ли это адреса (не «старый» IP после миграции);
- доступен ли SMTP на 25 (а для сабмита — 587/465, если это ваш сценарий) на этих адресах.
Типичная поломка: MX смотрит на mail.example.com, а A у mail указывает на старый IP после переезда. Веб уже работает (сайт перевели иначе), а SMTP остался на «забытом» адресе.
Можно ли делать CNAME для MX-хоста
Формально MX должен указывать на имя, которое при резолвинге даёт A/AAAA. Многие резолверы «терпят» CNAME в цепочке, но совместимость не идеальна, а некоторые проверки/антиспам относятся к этому подозрительно.
Практическое правило: избегайте CNAME в цепочке для MX. Делайте прямые
A/AAAAна конечный хост MX.
TXT для почты: SPF, DKIM, DMARC и почему это рядом с MX
MX отвечает на вопрос «куда доставлять». Но доставляемость в реальной почте завязана на аутентификацию домена как отправителя. Даже если входящий MX настроен идеально, без нормальных TXT-записей письма от вашего домена будут чаще уходить в спам или отклоняться.
SPF (TXT): кто имеет право отправлять от домена
SPF — это TXT-запись для домена (или поддомена), которая перечисляет разрешённые источники отправки. Условно: «разрешаем отправлять отсюда, остальным — fail/softfail».
Частые ошибки SPF:
- несколько SPF TXT у одного домена (должна быть одна запись с
v=spf1); - слишком длинная цепочка
includeи превышение лимита DNS-запросов (часто проявляется какpermerror); - настроили SPF не там: сделали SPF на
mail.example.com, а отправляют сexample.com; - слишком жёсткий
-allпри наличии легитимных рассылок через сторонние сервисы.
DKIM (TXT): подпись письма ключом домена
DKIM — это TXT-запись по селектору: selector._domainkey.example.com. Публичный ключ лежит в DNS, приватный — на MTA/в сервисе рассылки. Если селектор сменили, а DNS не обновили (или наоборот) — подпись не проходит, и это напрямую бьёт по доставляемости.
Если планируете ротацию ключей и хотите сделать её без сюрпризов из-за TTL и кешей, пригодится материал про ротацию DKIM-селекторов и TTL.
DMARC (TXT): политика домена и отчёты
DMARC живёт в TXT на _dmarc.example.com и определяет, что делать с письмами, которые не прошли SPF/DKIM, а также куда слать агрегированные отчёты. Ошибка в DMARC редко «ломает SMTP» на входе, но легко приводит к массовым отклонениям или спаму — особенно когда политика p=quarantine или p=reject включена без подготовки.
DMARC — это режим работы домена как отправителя. Включайте строгую политику только после выравнивания (alignment) SPF/DKIM и инвентаризации всех источников отправки.
Split DNS: почему внутри всё работает, а снаружи — нет
split DNS (split-horizon) — это когда для одной и той же зоны разные клиенты получают разные ответы. Обычно внутренние резолверы видят «внутренний» IP, внешние — «публичный».
Для почты split DNS опасен тем, что:
- внутри сети тесты проходят (MX резолвится на внутренний адрес, SMTP доступен);
- снаружи MX может указывать на другой хост/IP, где SMTP не настроен, закрыт фаерволом или не существует;
- SPF/DKIM/DMARC могут отличаться внутри/снаружи, что делает диагностику неочевидной.
Если у вас split DNS, правило простое: публичная зона должна быть самодостаточной для всего внешнего мира. Почта — это внешний мир.
Типовые DNS-ошибки, которые ломают доставку
Ниже — список проблем, которые встречаются чаще всего, и что проверить в первую очередь.
1) MX указывает на несуществующий хост или хост без A/AAAA
Симптом: ошибки резолвинга (NXDOMAIN/No answer) или «Host not found». Лечение простое: MX-хост должен иметь A/AAAA.
2) MX указывает на CNAME (или цепочку CNAME)
Симптомы «плавающие»: у части отправителей работает, у части — нет; где-то падает валидация. Надёжнее заменить на прямые A/AAAA для конечного MX-хоста.
3) Перепутаны приоритеты MX
Симптом: почта идёт через резервный сервер, очереди растут, появляются задержки. Проверка: меньший приоритет должен указывать на основной сервер.
4) Слишком большой TTL во время миграции
Симптом: часть мира ходит на старый MX/IP ещё сутки-двое. Практика: за 24–48 часов до переключения уменьшить TTL на MX и A/AAAA для MX-хостов, а после стабилизации вернуть к разумным значениям.
5) SPF: несколько TXT или превышение лимитов
Симптом: письма от домена хуже доставляются, появляется «SPF permerror». Проверка: ровно одна SPF-запись и она укладывается в лимит DNS-механизмов.
6) DKIM: неверный селектор или битый ключ в TXT
Симптом: «DKIM fail», иногда массовый спам. Частая причина — копипаст ключа с переносами/кавычками или публикация не туда (не тот селектор/домен).
7) DMARC: включили reject без инвентаризации отправителей
Симптом: внезапно отваливаются транзакционные письма/рассылки/CRM, потому что они шли без DKIM или с невыравненным SPF. Правильный путь: p=none → сбор отчётов → исправления → quarantine → reject.
Как быстро диагностировать DNS для почты (команды и что смотреть)
Для диагностики достаточно dig или kdig. Ниже — минимальный набор проверок.
Проверяем MX и его IP
dig +short MX example.com
dig +short A mx1.example.com
dig +short AAAA mx1.example.comЕсли MX есть, но A/AAAA пустые — это почти гарантированная причина проблем.
Проверяем, «какую правду» видит конкретный резолвер
dig @1.1.1.1 MX example.com
dig @8.8.8.8 MX example.com
dig @9.9.9.9 MX example.comЕсли ответы разные — возможны проблемы с делегированием, split DNS «по ошибке» или рассинхрон на авторитативных серверах.
Проверяем SPF, DKIM, DMARC
dig +short TXT example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.comПрактический совет: SPF ищите по строке, начинающейся с v=spf1. DMARC — с v=DMARC1. DKIM — с v=DKIM1.
Чек-лист: как настроить MX «правильно» и не пожалеть
Определите архитектуру: один почтовый сервер, два MX (основной/резервный), внешняя почтовая платформа.
Создайте имена MX-хостов (например
mx1,mx2) и назначьте имA/AAAA, соответствующие реальным SMTP-узлам.Создайте MX у домена с корректными приоритетами (меньше число — выше).
Не используйте CNAME для MX и избегайте цепочек алиасов.
Согласуйте TTL: перед миграциями уменьшайте, после — возвращайте.
Настройте TXT для отправки: SPF (одна запись), DKIM (ключи и селекторы), DMARC (постепенное ужесточение).
Проверьте split DNS: внешняя зона должна возвращать рабочие MX/
A/AAAAи актуальные TXT.Протестируйте с нескольких резолверов и из внешней сети: MX,
A/AAAA, доступность SMTP.
Частый кейс: сайт переехал, а почта «падает»
Сценарий: вы перенесли сайт на новый сервер, поменяли A домена на новый IP. Почта обслуживается отдельно, а MX указывает на mail.example.com, который остался на старом IP. На старом сервере при этом закрыли 25 порт или отключили почтовый сервис.
Почему это не видно сразу: сайт работает, веб-проверки зелёные, но входящая почта начинает ретраиться у отправителей и приходит с задержкой или не приходит вовсе.
Правильная последовательность: сначала привести в порядок MX-хосты и их A/AAAA, проверить SMTP, и только затем «гасить» старую инфраструктуру.
Итоги
MX — это верхушка почтового DNS, но именно он задаёт маршрут доставки. Рабочая настройка — это связка MX + корректные A/AAAA для MX-хостов + аккуратные TXT-записи для SPF, DKIM и DMARC. Если добавить контроль TTL при миграциях и внимательность к split DNS, вы закрываете большинство причин, из-за которых ломается доставка.
Для углубления темы пригодится разбор про делегирование поддоменов и NS-записи: часть «магических» проблем с почтой на практике упирается в кривую делегацию или рассинхрон авторитативных DNS.
