Короткий ответ

Входящая почта на contoso.example идёт туда, куда смотрит публичный MX, не туда, где пользователи открывают Outlook. Для облачного контура MX должен указывать на contoso-example.mail.protection.outlook.com (дефисы вместо точек домена) с приоритетом, который вы задали в мастере Microsoft 365 (часто 0). Если MX держит A-запись веб-хостинга, старый Postfix провайдера или выключенный Exchange 2016 — письма не попадут в ящик ivan.petrov@contoso.example, хотя OWA открывается.

Исходящие при этом могут жить: EO не обязан получать сам себя через ваш MX. Симптом «нам не пишут, мы пишем» — почти всегда MX или Accepted Domain, не профиль Outlook.

Симптомы и как отличить

  • Внешние сообщают NDR, внутренние в тенанте доходят.
  • На старом сервере в /var/log/mail или очереди on-prem копится почта на @contoso.example.
  • Resolve-DnsName -Type MX показывает mx1.hosting.example или mail.contoso.example → 10.0.10.10.
  • NDR 5.4.1 Recipient address rejected: Access denied — MX уже облачный, но получателя нет в тенанте (или наоборот, облако отвергает домен).
MX указываетВходящие
*.mail.protection.outlook.comконтур Microsoft 365
старый IP офисаon-prem, если он жив
регистратор «parking»чёрная дыра
два MX разные контуры равный priлотерея сплита, обычно плохо

Autodiscover и MX — разные записи. Сломанный Autodiscover ломает профиль, не входящий SMTP с интернета.

Возможные причины

  1. После миграции забыли сменить MX, TTL ещё сутки.
  2. Хостер «помог» и вернул MX на себя при продлении домена.
  3. Гибрид: MX должны соответствовать выбранной схеме (обычно MX на EO, on-prem через коннекторы). Оставили MX на on-prem, сервер выключили.
  4. Несколько MX: старый с приоритетом 10 всё ещё живее нового с 20 — почта идёт на старый.
  5. MX на CNAME (нельзя по RFC; часть отправителей ломается). Нужно MX → A/AAAA имени Microsoft, не MX → CNAME вашей выдумки.
  6. Опечатка: contoso.example.mail.protection.outlook.com вместо contoso-example.mail.protection.outlook.com.
  7. Домен не добавлен как Accepted Domain в тенанте contoso.onmicrosoft.com.

Диагностика

1. Что видит интернет

Resolve-DnsName contoso.example -Type MX
Resolve-DnsName contoso-example.mail.protection.outlook.com -Type A
nslookup -type=MX contoso.example
nslookup -type=A contoso-example.mail.protection.outlook.com

Сверьте имя с мастером доменов в Microsoft 365 admin center (Settings → Domains → DNS records). Не угадывайте дефисы.

2. Кто реально принимает 25/tcp

С внешней сети (не с офисного NAT, где 25 закрыт) MX должен слушаться на SMTP. С рабочей станции за провайдером, который фильтрует 25, Test-NetConnection -Port 25 врёт. Для проверки контура Microsoft достаточно корректного имени MX; не сканируйте чужие диапазоны «для интереса».

3. Сообщение снаружи и трейс

Попросите внешнего отправителя Message-ID. У себя:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.example
Get-MessageTrace -RecipientAddress ivan.petrov@contoso.example `
  -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date)

Пустой трейс при живом отправителе = письмо не попало в EO (чужой MX или отказ до EO). Есть Failed — читайте недоставку.

4. Accepted Domains

Get-AcceptedDomain | Format-Table Name, DomainName, DomainType, Default

contoso.example должен быть Accepted (Authoritative, если ящики здесь).

Решение

Сценарий A. Облако, MX на хостинг

В DNS замените MX на значение из портала Microsoft 365. Удалите старые MX, не оставляйте «запасной» на ISP. Подождите TTL. Снимите копию зоны до правки.

Сценарий B. Приоритеты

Оставьте один целевой контур. Второй MX того же mail.protection.outlook.com не нужен: Microsoft балансирует за именем. Два разных контура с pri=10 — почти всегда ошибка.

Сценарий C. Гибрид

Если Centralized Mail Transport / MX на on-prem — on-prem обязан быть жив, с коннекторами в EO. Если on-prem выводят — MX переводят на protection.outlook.com, коннекторы и Autodiscover пересматривают отдельно.

Сценарий D. 5.4.1 при правильном MX

Ящик/алиас не существует, домен не Accepted, или получатель в другом тенанте. Это каталог, не DNS. Создайте пользователя/контакт, не плодите второй MX.

Сценарий E. Парковка и «email forwarding» регистратора

Выключите почтовый форвардинг регистратора, он перехватывает MX. Корпоративная почта и «пересылка на личный gmail в панели nic» несовместимы как два MX-контура.

Сценарий F. Несколько имён, один тенант

У contoso.example и mail.contoso.example разные MX, если заведены отдельно. Часто мастер Microsoft 365 показывает запись только для apex. Поддомен, с которого «нам пишут на info@mail.contoso.example», может смотреть на старый A. Снимите MX для каждого SMTP-домена в Accepted Domains, не только для логотипа на сайте. В тенанте contoso.onmicrosoft.com сравните список доменов в admin center с фактическими адресами в GAL.

Исходящие при «кривом MX» живут, потому что EO отдаёт почту напрямую на MX получателя. Не используйте успешную отправку Ивана как доказательство, что входящий контур верный. Для входящих единственный лабораторный тест — внешний ящик, которым вы владеете, плюс Get-MessageTrace -RecipientAddress ivan.petrov@contoso.example.

Если cutover только что прошёл и часть писем ещё капает на старый Postfix, не убивайте on-prem в ту же минуту: доберите TTL и очередь. Потом выключите приём на 25/tcp у старого имени, чтобы не плодить два контура.

Как проверить, что проблема устранена

  1. Публичный MX = имя из портала, единственный нужный контур.
  2. Письмо с внешнего ящика, которым владеете, за 5–15 минут в Inbox и в Get-MessageTrace как Delivered.
  3. Старый сервер больше не получает новую почту на @contoso.example (лог тихий).
  4. SPF/DKIM не забудьте: MX вход, SPF выход — комплект.

Если не помогло

  • TTL не истёк у отправителя: они кешируют старый MX. Подождите, не прыгайте MX туда-сюда каждые 5 минут.
  • Только один домен-отправитель не доходит: их исходящий антиспам, не ваш MX. Сверьте трейс.
  • Поддомен info.contoso.example без своего MX наследует apex — это норма RFC. Если для поддомена нужен другой контур — отдельные MX.
  • IPv6-only странности редки; AAAA на MX-имени Microsoft штатные.

Профилактика

  • Документ: «входящий контур = EO», дата cutover, TTL на момент смены (понизить заранее, поднять после).
  • Мониторинг MX (внешняя проверка записи, не только ping).
  • Запрет хостеру «оптимизировать DNS» без заявки.
  • Чеклист подготовки домена включает MX вместе с Autodiscover.

FAQ

Нужен ли A-запись mail.contoso.example?

Не обязательна для EO. MX может указывать сразу на *.mail.protection.outlook.com. Старый mail. A на офисный IP вреден, если кто-то шлёт туда в обход MX.

Можно ли MX на CNAME?

Не делайте. Стандарт требует MX на имя с A/AAAA.

Исходящие идут, входящих нет — это точно MX?

Очень вероятно. Ещё: транспортное правило, карантин Defender, неверный адрес. Но начинайте с MX и трейса.

Сколько держать низкий TTL?

На период миграции часы–сутки. Потом 3600+ чтобы не кормить чужие резолверы вечным 60s.

Два тенанта и один домен?

Домен Accepted только в одном тенанте. MX не разрежет почту «по 50%». Сначала перенос домена, потом MX.