DNS MX record not found / Domain not found / 554 5.7.1 Recipient address rejected
#Как почтовый сервер находит получателя
Когда отправитель пишет на адрес user@example.ru, его сервер запрашивает у DNS MX-записи домена example.ru. Если MX нет, по стандарту сервер попробует доставить на A-запись домена, но большинство современных серверов отклоняют такие письма или помещают в очередь. Если MX указывает на несуществующее имя или адрес, письма уходят в очередь и возвращаются с ошибкой через несколько дней. Поэтому правильно заданные MX — обязательное условие работы почты домена.
#Типичные причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Нет MX-записиНе создана. | dig MX пустой. | Добавьте записи у провайдера. |
| Редактируют не у того DNS-провайдераNS на другой стороне. | Изменения не видны. | Меняйте там, куда указывает NS. |
| MX указывает на IPНельзя. | Часть серверов отклоняет. | Укажите имя. |
| У MX-имени нет A-записиОпечатка. | Письма в очереди. | Исправьте имя. |
| Конфликт CNAME и MXCNAME на корне. | Записи не принимаются. | Уберите CNAME на корне домена. |
| Не обновился кешСтарый TTL. | Одни получают, другие нет. | Подождите, проверьте на dnschecker.org. |
#Порядок
- Проверьте, на каких серверах делегирован доменУ владельца домена в кабинете регистратора откройте раздел делегированных DNS-серверов/NS и запишите реальные имена. Затем выполните в Windows «Пуск → Командная строка» →
nslookup -type=NS example.com(вместо примера подставьте домен); на Linux/macOS используйтеdig NS example.com +short. DNS-зону с MX нужно редактировать у того поставщика, чьи NS действительно опубликованы. Если список отличается от панели, где вы меняли запись, сперва выясните причину рассинхронизации у регистратора. - Проверьте текущие MX-записиВладелец домена может открыть терминал и выполнить
nslookup -type=MX example.com(вместо example.com — свой домен; в Linux/macOS также подходитdig example.com MX +short). Найдите в ответе имя почтового сервера и приоритет. Если MX отсутствует или имя не соответствует документации вашего почтового провайдера, откройте DNS-панель именно делегированной зоны и переходите к исправлению. Отсутствие ответа у одного кеширующего DNS ещё не доказывает ошибку записи у авторитетного сервера. - Получите значения MX у почтового провайдераВойдите в административную панель почтового сервиса, которому принадлежит домен: например, в раздел подключения домена или проверки DNS. Откройте официальную инструкцию этого сервиса по MX-записям и перепишите точное имя почтового сервера и приоритет; они различаются у Яндекс 360, Google Workspace и других провайдеров. Не копируйте адрес MX из чужой статьи. Затем откройте панель DNS-хостинга своего домена, проверьте текущие MX и запланируйте замену с учётом TTL. Если нет доступа к DNS, передайте значения администратору домена.
- Добавьте записи MX с нужным приоритетомВ панели DNS именно делегированного домена нажмите «Добавить запись» → тип
MX. Поле имени обычно@для домена целиком; целевой сервер и приоритет скопируйте дословно из настроек почтового провайдера (не из примера в интернете). Сохраните; через несколько минут проверьтеnslookup -type=MX example.comс вашим доменом. В целевом поле должно быть доменное имя сервера, не IP; не удаляйте прежние MX до проверки инструкции по миграции. - Удалите старые, конфликтующие MXУдаляйте MX только после сверки с официальной инструкцией вашего почтового провайдера и сохранения списка текущих записей. В DNS-панели авторитетной зоны сравните каждый MX по имени, цели и приоритету; удалите именно тот, который больше не должен принимать почту, а правильные записи оставьте. Проверьте, что целевой почтовый сервер разрешается в A/AAAA. Ошибка при удалении MX может остановить приём почты; если используете несколько почтовых систем, сначала уточните схему маршрутизации.
- Убедитесь, что MX указывает на имяВ панели DNS-хостинга откройте список записей домена и найдите все записи типа MX. В их поле «Значение/Сервер» должен быть доменный адрес, указанный вашим почтовым провайдером, а не цифровой IP; адрес должен корректно разрешаться в A и/или AAAA. В терминале можно проверить
nslookup -type=MX ваш-домен.exampleи отдельноnslookup имя-почтового-сервера.exampleс реальными именами. Если записи совпадают с документацией сервиса, но почта не поступает, проверьте приоритеты, TTL и журнал почтового сервиса. - Добавьте SPF и DKIMSPF и DKIM нужны для проверки подлинности исходящих писем, но сами по себе не восстанавливают доставку входящих писем по MX. После исправления MX откройте официальную инструкцию используемого почтового сервиса: он выдаст точную TXT-запись SPF и DKIM-ключ/селектор. Добавляйте их в DNS-панели строго в указанном формате, не сочиняйте значения и не создавайте второй SPF TXT для того же имени. Проверьте наличие TXT через
nslookup -type=TXT example.com; если не управляете исходящей почтой, пропустите этот отдельный этап. - Подождите распространения и проверьте доставку тестовым письмомПосле публикации MX подождите, пока рекурсивные DNS-серверы обновят кеши. Отправьте контрольное письмо на ваш адрес с другого почтового сервиса, проверьте «Входящие» и «Спам». Если письмо не приходит, изучите текст уведомления о недоставке отправителю: код ошибки и имя принимающего сервера показывают, связана ли проблема с DNS, существованием ящика или фильтрами. Сохраните уведомление для поддержки почтового сервиса.
- Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Проверка доставки
Отправьте письма с Gmail и с Яндекса на адрес домена и посмотрите, придут ли они. Проверьте заголовки и журнал провайдера. Онлайн-проверка записей и диагностика доступна на https://mxtoolbox.com/SuperTool.aspx : введите mx:example.ru, и сервис покажет найденные записи, их доступность и основные проблемы.