MX не виноват один: где обрывается доставка почты

Если MX-запись выглядит правильной, проверьте весь путь: имя узла в DNS, входящий TCP-порт 25, SMTP-ответ и очередь отправителя. Для исходящей почты отдельно проверяют PTR, SPF и DKIM: они влияют на доверие получателя, но не заменяют маршрут. Ниже — порядок диагностики и данные, которые стоит передать администратору.

Что на самом деле подтверждает MX-запись

Я сначала уточняю направление сбоя. Если вам не доставляют письма, в рамках корпоративной почты проверяем домен-получатель и его входящий сервер. Если ваши письма не доходят до адресатов, смотрим уже исходящий сервер и правила принимающей стороны. Фраза «почта не работает» смешивает эти два маршрута так же ловко, как провода за столом: всё подключено, но какой провод куда — загадка.

MX-запись сообщает отправителю, какой узел принимает почту для домена. В ответе важны имя сервера и preference — приоритет. Когда MX-записей несколько, меньшему числу соответствует более высокий приоритет; отправляющий сервер выбирает узел по этим значениям и правилам SMTP. Поэтому правильное число само по себе ничего не говорит о том, отвечает ли выбранный узел. dig показывает DNS, а не факт успешной доставки.

Затем я проверяю, разрешается ли имя из MX в адрес A или AAAA. Ошибка в имени узла, пустой или устаревший адрес и неверный ответ у разных DNS-резолверов ведут к разным симптомам. Сравниваю ответ авторитетного DNS и ответ, который видит отправитель. Если они различаются, сначала разбираюсь с делегацией зоны, TTL и кэшем; менять настройки почтовой программы в этот момент бессмысленно.

Если MX-записей несколько, я сверяю каждый указанный узел, а не только тот, у которого самое привлекательное число. Запасной MX помогает лишь тогда, когда его действительно настроили принимать почту для этих адресов и доставлять её дальше; сама дополнительная строка в DNS этого не гарантирует. При сбое основного узла отправляющий сервер может перейти к следующему по preference, но некорректный резерв только переносит отказ на следующий шаг. Поэтому фиксирую весь список ответов и проверяю доступность каждого сервера отдельно. Низший приоритет на бумаге не лечит службу, которая не запущена.

На условной схеме «Жасмин-Трейд» я бы зафиксировал домен, полученные MX-ответы, адрес выбранного узла и время проверки. Это пример порядка работы, а не описание реального инцидента или обещание заранее известного результата. Я не ставлю диагноз по одному скриншоту панели: записываю точные ответы DNS и только после этого перехожу к соединению. Иначе легко исправлять аккуратно оформленную, но вообще не связанную с проблемой запись.

• Сверьте MX-ответы для домена получателя.
• Проверьте A/AAAA для имени из MX.
• Сравните ответ авторитетного DNS и внешнего резолвера.

Как проверить входящее соединение на порт 25

Для обычной доставки между почтовыми серверами нужен доступ по SMTP к входящему узлу домена; на публичном MX обычно проверяют TCP-порт 25. Если соединение не устанавливается, письмо не дойдёт до этапа проверки получателя или фильтрации. Я проверяю не только правило локального firewall, но и внешний сетевой экран, ACL у провайдера, маршрут и то, слушает ли MTA нужный адрес.

Пробу делаю с узла вне сети, где стоит почтовый сервер: nc -vz mx.example.com 25. Подставьте имя из своей MX-записи. Успешное TCP-соединение подтверждает только, что удалённый узел ответил на соединение; оно не доказывает, что сервер принял конкретного получателя или сохранил сообщение. Для этого нужен SMTP-диалог и запись в логах. Не запускайте проверку только с самого сервера: локальный маршрут может обходить внешний экран.

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

Отдельная ловушка — путать входящий TCP 25 с исходящим SMTP. Некоторые облачные площадки ограничивают исходящие соединения на порт 25, чтобы с их адресов не рассылали спам; это мешает отправлять почту с сервера, но само по себе не означает, что извне нельзя подключиться к вашему MX. Например, документация AWS EC2 описывает именно ограничение исходящего трафика к публичным адресам. Я проверяю направление потока до обращения в поддержку — иначе можно попросить открыть совсем не тот порт.

Даже открытый TCP-порт не означает, что SMTP-обмен завершился. Клиент может подключиться, но не получить ожидаемый ответ службы, увидеть отказ после команды RCPT TO либо дождаться временного ответа уже после передачи сообщения. Я отмечаю, на каком шаге закончился диалог, и сохраняю полный ответ вместе с временем. Это помогает не смешивать «нет маршрута до сервера», «сервер отказал этому адресу» и «сервер принял письмо, но фильтр поместил его дальше в карантин». У этих состояний разные владельцы и разные исправления; скриншот теста порта показывает только самый первый этап.

Когда сбой плавающий, я повторяю проверку из двух независимых внешних сетей и записываю точное время с часовым поясом, имя MX и результат TCP-соединения. Затем прошу сетевого администратора сопоставить эту попытку с журналом внешнего экрана или облачной сетевой политики. Если одна точка подключается, а другая нет, это сужает поиск до маршрута и правил между конкретной сетью и сервером; если обе не доходят, проверяю также службу и адреса узла. Один удачный тест не объясняет жалобу, которая возникает раз в несколько часов, а снимок без времени почти невозможно сопоставить с логами. Я сохраняю вывод проверки целиком и отмечаю, с какого внешнего узла её запускали.

• Проверяйте MX с внешнего узла: `nc -vz mx.example.com 25`.
• Отдельно проверьте сетевой экран, маршрут и службу MTA.
• Уточните у хостера ограничения на входящий и исходящий трафик.

Что говорят SMTP-ответы и greylisting

Когда соединение состоялось, я ищу конкретный SMTP-ответ в логах принимающего сервера и в очереди отправителя. Коды класса 4xx обозначают временный отказ, а 5xx — постоянный. Это важнее общего сообщения «письмо зависло»: при временном ответе отправляющий MTA обычно оставляет сообщение в очереди и пробует доставить позже; постоянный ответ нужно читать вместе с причиной и адресом получателя.

Greylisting — один из возможных временных отказов, а не синоним любой задержки. Сервер отклоняет попытку временным ответом, а отправитель должен повторить её согласно своей политике очереди. Точного универсального интервала нет: он зависит от отправляющей системы. Поэтому обещание «письмо придёт через полчаса» — гадание; подробнее разбираю задержку кода входа. В логах ищу время отказа, текст ответа, отправляющий узел и повторные попытки; в очереди отправителя — следующее действие.

В Mailcow greylisting связан с фильтрацией Rspamd: в официальном руководстве мягкий отказ применяется к письмам с подходящим уровнем spam score, а не автоматически к каждому незнакомому адресу. Это полезная конкретика для диагностики: нужно посмотреть решение фильтра и его журнал, а не наугад отключать защиту целиком. Если сервер возвращает 4xx из-за greylisting, исправлять MX или открывать порт повторно обычно нечего — сетевой этап уже пройден.

Если получатель ждёт письмо, а у отправителя его очередь пуста, запросите полный bounce или SMTP-лог: код, текст ответа, время и домен назначения. Если очередь растёт, выясняйте, что именно повторяется и не превращается ли временный отказ в постоянную проблему. Именно по этой границе я решаю, к кому идти дальше: к администратору принимающего сервера, владельцу DNS или тому, кто управляет исходящей почтой. Строка «не доставлено» без ответа сервера для расследования почти бесполезна; примеры собрал в разборе ответов 421 и 554.

Сопоставляю две стороны одной попытки: журнал принимающего MTA и статус очереди у отправителя. Если получатель не видит даже соединения, начинать с правил ящика рано. Если лог показывает, что сервер принял сообщение, поиск переходит к фильтру, карантину и папке пользователя. Если отправитель получил 4xx, письмо остаётся его ответственностью до следующей попытки или истечения срока очереди; принимающая сторона не может заставить чужой сервер повторить доставку. Текст SMTP-ответа и идентификатор сообщения обычно экономят больше времени, чем серия случайных изменений DNS.

Для разбора я прошу не пересылать содержимое делового письма, если оно не нужно, а передать технические данные: домен отправителя и получателя, время с часовым поясом, полный SMTP-ответ и идентификатор сообщения или очереди, если он доступен. С этими данными администраторы обеих сторон могут найти одну и ту же попытку в журналах. Скриншот папки «Входящие» такой связки не даёт: письмо могло не попасть на сервер, быть временно отложено или уже лежать в карантине. Я не чищу очередь до фиксации причины и не отключаю greylisting целиком ради одного обращения. Сначала выясняю, какой ответ получил отправитель и повторял ли он доставку; после этого меняю только тот фильтр или маршрут, который виден в журнале.

• 4xx — временный отказ; проверьте очередь и повторы.
• 5xx — постоянный отказ; изучите полный текст ответа.
• При greylisting сопоставьте логи фильтра и отправителя.

Когда проверять PTR и кто может его изменить

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

Для исходящего узла важно не просто увидеть какое-нибудь имя. Некоторые принимающие системы проверяют, что отправляющий домен или IP имеет действительные прямую и обратную DNS-записи; Google прямо указывает такое требование в своих правилах для отправителей. Это не правило «PTR обязан дословно совпадать с MX». Сначала узнаю имя, на которое указывает PTR, затем проверяю его A/AAAA и сверяю полученный адрес с исходящим IP.

Команда для обратного запроса выглядит так: dig -x 203.0.113.10 +short; замените зарезервированный примерный адрес на публичный IP своего исходящего сервера. Саму PTR-запись обычно меняет организация, управляющая адресным блоком или сервером: хостер, оператор облака либо владелец IP. Если панель домена не даёт такой настройки, это нормально — обратная зона может быть не в управлении регистратора. Попросите у провайдера установить подходящее имя и затем перепроверьте прямой и обратный ответы.

Отправка через внешний почтовый сервис добавляет ещё одно различие: получатель видит публичный IP того узла, который реально установил SMTP-соединение, а не обязательно адрес вашего MX-сервера. При проверке PTR я выясняю, через какой relay отправлялось конкретное письмо и кому принадлежит исходящий IP. Если письмо ушло через сервис-посредник, менять обратную запись вашего входящего сервера не поможет — нужно смотреть настройки и требования к отправляющему сервису. В заголовках принятого тестового письма ищу цепочку Received и Authentication-Results, чтобы связать диагностику с фактическим маршрутом.

• Проверьте обратное имя: `dig -x 203.0.113.10 +short`.
• Проверьте A/AAAA полученного имени.
• Закажите изменение PTR у владельца IP-адреса.

Как SPF, DKIM и DMARC влияют на доставку

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

Из этого не следует, что отсутствие одной записи автоматически отправит каждое письмо в спам или что наличие всех трёх гарантирует Inbox. Итог зависит от проверки получателя, его правил, репутации и содержимого сообщения; отдельно описал проверку репутации почты. Требования могут отличаться у разных сервисов и типов рассылки. Для диагностики я сначала смотрю, какое именно сообщение отклонено и кем, а затем проверяю выравнивание доменов, результат SPF/DKIM/DMARC и заголовки конкретного письма.

Пересылка может изменить результаты проверки: пересылающий сервер отправляет письмо от своего IP, поэтому исходный SPF не всегда проходит на следующем узле. Если DKIM-подпись сохранена и её домен выровнен с видимым From, DMARC всё ещё может пройти по DKIM. Но некоторые пересыльщики меняют тело или заголовки, и тогда подпись может стать недействительной. Поэтому письмо, прошедшее напрямую, может получить другой результат после списка рассылки или переадресации. Это не обязательно поломка SPF исходного домена: сравните Authentication-Results до и после пересылки и проверьте, изменил ли посредник сообщение.

Не лечите этой тройкой проблему приёма входящих писем, пока не проверили MX, TCP-соединение, ответ сервера и локальную очередь. Обратная ситуация тоже встречается: компания уверена, что «почта не приходит», а письмо фактически принял сервер и положил в спам, карантин или папку пользователя. Тогда нужны журналы фильтра и почтового ящика, а не новый DNS-шаблон. Я разделяю отказ до SMTP-приёма и сортировку уже принятого сообщения.

Мой короткий маршрут такой: подтвердить, кто не получает письмо; сохранить MX и адрес узла; проверить доступность TCP 25 снаружи; найти SMTP-ответ и состояние очереди; только для исходящего потока проверить PTR и аутентификацию. Если письмо есть на сервере, но его не видит человек, дальше проверяю карантин, правила и папки. Пять отдельных проверок дают причину, которую можно исправить, а не ещё один набор DNS-записей «на всякий случай». Если подтверждено, что сервер принял письмо, отдельно проверьте карантин, пользовательские правила и папки, куда сообщение мог перенести почтовый клиент.

• Для исходящей почты проверьте SPF и DKIM.
• Проверьте DMARC и выравнивание доменов.
• Не считайте успешную аутентификацию гарантией Inbox.

Частые вопросы