Коротко — причин может быть много. Ниже — последовательность проверок и конкретных действий, чтобы локализовать проблему и подготовить данные для обращения в техподдержку Microsoft.
1) Быстрая проверка статуса Microsoft
- Откройте Microsoft 365 admin center → Health → Service health — есть ли инциденты по Exchange/Exchange Online или Mail flow (09–10.06.2026)?
- Поиск в Twitter/DownDetector/сообществах Microsoft — нештатные массовые сбои.
2) Проверить MX/DNS (частая причина)
- Убедитесь, что публичные MX-записи домена указывают на mail.protection.outlook.com или на ваш сторонний MX, если используется шлюз.
- Windows: nslookup -type=mx yourdomain.ru
- Linux/macOS: dig +short MX yourdomain.ru
- Если MX отсутствует или указывает на старый/сторонний сервер — письма могут идти туда и теряться.
3) Тест «снаружи» и сетевое подключение к MX
- С внешнего сервера/ISP запустите telnet <MX> 25 — проверьте, принимается ли SMTP-соединение и отвечает ли сервер.
- Если соединение не устанавливается — возможен блок портов/фильтрация на уровне провайдера или у MX.
4) Message trace (Exchange Online / EAC)
- В Exchange admin center → Mail flow → Message trace (или Security & Compliance → Mail flow → Message trace) выполните поиск входящих писем за период начиная 09.06.2026. Это покажет были ли попытки доставки и какой статус (Received, Pending, Filtered, Delivered, Rejected, etc.).
- В PowerShell (ExchangeOnline) можно использовать Get-MessageTrace / Get-MessageTraceDetail.
5) Quarantine / Spam filtering
- Проверьте Security & Compliance → Review → Quarantine — возможно письма попадают в карантин.
- Посмотрите политики Microsoft Defender for Office 365 / Exchange Online Protection — есть ли транспортные правила или политики, автоматически удаляющие/отклоняющие входящие.
6) Приёмные коннекторы и ограничения
- Проверьте inbound connectors в Exchange Admin Center — есть ли ограничения по IP, RequireTLS и т.п., которые начали блокировать внешних отправителей.
- Если у вас гибрид/передача через сторонний шлюз (Proofpoint/Barracuda/etc.) — проверьте его очередь и лог.
7) Статус почтовых ящиков и домена
- Убедитесь, что домен подтверждён в Microsoft 365, лицензии пользователей активны, почтовые ящики не заблокированы/не переполнены.
- Проверьте, не удалён ли «Accepted domain» для вашей почты.
8) Почему отправители не получают NDR
- Если отправители не видят отказа, возможно:
- Их сервер успешно доставил письмо на другой MX (старый/сторонний), который просто принимает и не ставит NDR (грейлистинг/удаление).
- Письма принимаются и сразу удаляются транспортным правилом/скриптом.
- Коннектор/шлюз принимает и не отвечает (маловероятно).
Поэтому message trace и MX-проверка критичны.
9) Что просить у отправителя
- Время и дата отправки, адрес отправителя, заголовки (если есть), IP отправляющего сервера, скриншот попытки отправки.
- Попросите отправить тест с Gmail, Yandex и другого провайдера — смотреть закономерности.
10) Диагностика, которую можно выполнить прямо сейчас
- nslookup/dig MX.
- telnet на MX:25 (проверка подключения).
- Отправить тестовое письмо с разных внешних сервисов и одновременно запустить message trace в EAC.
- Проверить quarantine и mail flow rules в EAC.
- Проверить Service health.
11) Если нужно обращаться в поддержку Microsoft
Подготовьте:
- Результаты nslookup/dig MX.
- Результаты message trace (или пример MessageTraceId).
- Время/даты тестовых отправок и адреса отправителей.
- Вывод telnet/SMTP-сессии к MX.
Откройте запрос в Microsoft 365 admin center → Support → New service request.
Если хотите, пришлите:
- Ваш домен (или результат nslookup), пример исходного письма (от кого, когда) и вывод попытки telnet — помогу проанализировать и составить корректный запрос в поддержку.