Короткий ответ
Outlook «Отправлено» — не доказательство доставки. Сначала снимите факт в Microsoft 365: Message Trace (GUI или Get-MessageTrace) по ivan.petrov@contoso.example, времени и Message-ID. Статус Delivered к чужому домену значит, что Exchange Online отдал письмо принимающему MX; дальше это уже их Junk/карантин. Failed / NDR читайте по коду (5.1.10, 5.2.2, 5.4.1, 4.4.7), а не по эмоции пользователя. Pending — ещё в контуре Microsoft или на retry к чужому MX. Пока нет трейса, не трогайте профиль Outlook и не «чините» SPF.
Параллельно сверьте ваш исходящий контур: MX contoso.example должен смотреть на contoso-example.mail.protection.outlook.com, если почта живёт в Exchange Online. Чужой MX объясняет входящие дыры; исходящие «пропажи» чаще дают NDR, карантин, транспортное правило или переадресация.
Симптомы и как отличить
Типичная заявка: «письмо не дошло», вложение «срочное», скриншот папки «Отправленные». Разведите сценарии.
| Что видно | Это не «Outlook сломался» | Куда |
|---|---|---|
| Есть NDR отправителю | отказ принимающей стороны или вашего антиспама | код NDR, трейс |
Трейс Delivered, у людей нет | Junk, карантин, правило на стороне получателя | спам |
| Трейс пустой, в Outlook «отправлено» | кэш, не тот ящик, правило переадресации | трейс + inbox rules |
| Внутри тенанта ок, наружу нет | коннектор, remote domain, блок исходящего | трейс Failed |
| Один адресат, остальные живы | их MX/ящик/фильтр | MX получателя |
Отличие от переполненного ящика: отправитель получает 5.2.2, исходящие встают. Отличие от скрытой переадресации: трейс показывает Expanded / fork на внешний адрес, которого пользователь «не настраивал».
Возможные причины
От частых к редким:
- Письмо ушло, получатель смотрит не тот ящик / Junk / карантин своего контура.
- NDR: адрес не существует (
5.1.10), ящик получателя полный (5.2.2), принимающий MX отверг (5.4.1,5.7.1). - У
contoso.exampleили домена получателя MX указывает на мёртвый/чужой контур — см. MX. - Транспортное правило, Defender for Office 365, исходящий антиспам, политика автоматической пересылки.
- Ящик отправителя в
ProhibitSend, лимит получателей, вложение больше лимита организации. - Гибрид: коннектор на on-prem, который больше не принимает; или смарт-хост провайдера.
- Кэш Outlook: письмо только в OST, на сервер не сабмитилось (офлайн, зависший профиль).
Не путайте «не доходит» с «доходит как спам»: тогда аутентификация и репутация, не очередь.
Диагностика
Плейсхолдеры: домен contoso.example, UPN ivan.petrov@contoso.example, тенант contoso.onmicrosoft.com.
1. Факт в Message Trace
Exchange admin center → Mail flow → Message trace. Либо:
Connect-ExchangeOnline -UserPrincipalName admin@contoso.example
Get-MessageTrace -SenderAddress ivan.petrov@contoso.example `
-StartDate (Get-Date).AddHours(-24) -EndDate (Get-Date) |
Select-Object Received, SenderAddress, RecipientAddress, Subject, Status, MessageIdИнтерпретация Status: Delivered — принято следующим хопом (для внешнего это их MX); Failed — смотрите NDR/Detail; Pending — подождите и повторите, не пересоздавайте профиль; FilteredAsSpam / карантин — это уже политика Microsoft 365, не «пропажа в интернете»; Expanded — группа или форвард.
Для конкретного Message-ID:
Get-MessageTrace -MessageId '<GUID@contoso.example>' -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date)2. MX — свой и получателя
Resolve-DnsName contoso.example -Type MX
Resolve-DnsName fabrikam.example -Type MXnslookup -type=MX contoso.example
nslookup -type=MX fabrikam.exampleДля Exchange Online ожидайте MX на *.mail.protection.outlook.com. Если у получателя MX смотрит на паркованный регистратор или старый ISP — ваш трейс будет Failed/4.4.7, чинить их DNS вы не обязаны, но в тикете это должно быть сказано явно.
3. NDR без фантазий
Разберите код из отчёта. Документированные ориентиры: 5.1.10 — получатель не найден в их каталоге; 5.2.2 — квота; 5.4.1 Access denied — часто «MX на Exchange Online, но ящика в этом тенанте нет»; 4.4.7 — истек retry, принимающая сторона не ответила. Не выдумывайте CVE и не меняйте SPF из-за 5.1.10.
4. Не кэш ли Outlook
OWA / outlook.office.com: есть ли письмо в «Отправленные» на сервере. Если в десктопе есть, в OWA нет — сабмита не было. Тогда сеть, Modern Auth, квота, а не MX.
5. Правила и форвард
Get-Mailbox ivan.petrov@contoso.example |
Format-List ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward
Get-InboxRule -Mailbox ivan.petrov@contoso.example
Get-TransportRule | Where-Object { $_.State -eq 'Enabled' } |
Select-Object Name, PriorityРешение
Сценарий A. Трейс Delivered, «у них нет»
Отдайте получателю Message-ID, время UTC и их MX. Попросите проверить Junk и карантин. Со своей стороны можете только поправить аутентификацию, если параллельно падает SPF/DKIM — это другая статья. Не гоняйте одно и то же письмо десять раз: вы кормите их антиспам.
Сценарий B. NDR 5.1.10 / опечатка
Исправьте адрес. Для внутренних: проверьте алиас и Accepted Domains. Для внешних — это не ваш каталог.
Сценарий C. 5.4.1 при отправке на contoso.example
Входящий контур: MX должен быть на protection.outlook.com и ящик/контакт должен существовать в тенанте. Часто после миграции MX уже облачный, а объект не создан, либо наоборот — MX ещё на старом сервере.
Сценарий D. Pending / 4.4.7 на один домен
Проверьте MX и TCP 25 до их MX с любой внешней проверки; с рабочей станции за NAT SMTP 25 часто закрыт — это нормально, Exchange Online шлёт сам. Если падает весь исходящий — смотрите connector и outbound spam (тенант мог попасть под throttling после компрометации).
Сценарий E. В Outlook «отправлено», трейса нет
Снимите офлайн-режим, дождитесь синхронизации, отправьте тест из OWA. Если OWA шлёт, а Outlook нет — профиль/Autodiscover, не DNS почты домена.
Как проверить, что проблема устранена
- Тестовое письмо на внешний ящик, который вы контролируете, с уникальным Message-ID.
Get-MessageTrace→Deliveredза минуты, не часы.- Получатель видит письмо во Inbox, не только в трейсе.
- Повтор на проблемный домен из заявки — один раз, не пачкой.
Get-MessageTrace -SenderAddress ivan.petrov@contoso.example `
-RecipientAddress you@fabrikam.example `
-StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date)Если не помогло
- Трейс
FilteredAsSpam/ Quarantine: политика Defender, не MX. Смотрите карантин и спам. - Доходит только на Gmail / только на другой Microsoft 365 — сравните заголовки
Authentication-Results(проверка SPF/DKIM/DMARC). - Группа рассылки: нужен трейс на развёрнутых получателей, не на SMTP группы.
- Гибрид:
Get-HybridMailflow/ коннекторы Centralized Mail Transport — письмо может уезжать на on-prem и умирать там. Это очередь on-prem, её нет в облачном Message Trace как «локальный SMTP».
Профилактика
- Мониторинг очереди по сути: алерты на всплеск Failed в Message Trace и на outbound spam verdict.
- Документированный MX и TTL; изменения DNS — только с rollback-снимком зоны.
- Запрет произвольной внешней переадресации, чтобы «не дошло» не маскировало утечку.
- Пользователей учите прикладывать NDR целиком и время UTC, не скрин «Отправленные».
FAQ
Outlook показывает галочку — этого мало?
Да. Галочка — сабмит в транспорт или даже просто запись в OST. Факт для администратора — Message Trace.
Нужно ли сразу пересоздавать профиль?
Нет, пока нет доказательства, что сервер письмо не принимал. Профиль чинят после расхождения OWA vs десктоп.
Почему внутренние письма живы, внешние нет?
Другой путь: исходящий коннектор, антиспам, репутация, MX получателя. Внутренний хоп Exchange Online почти никогда не ходит в публичный MX.
Можно ли смотреть очередь как на Exchange 2019?
Классической очереди на сервере у вас нет. Роль «очереди» выполняет Message Trace (Pending) и сервис Microsoft. On-prem очередь имеет смысл только в гибриде на вашем сервере.
Заголовок «Received» у получателя пустой — это мы не отправили?
Если трейс Delivered, вы отправили. Их фильтр мог снять тело в карантин без копии в ящике. Нужен их администратор.
Сколько ждать Pending?
Минуты — норма. Часы на один домен — смотрите их MX и NDR. Не оставляйте «само рассосётся» на сутки без повторного трейса.