Microsoft 365 delivery failures are more diagnosable than they first appear, because Exchange Online's Non-Delivery Reports (NDRs) typically state a specific error code that maps to a known cause — the fix is reading the NDR carefully rather than treating it as generic noise.
Reading the NDR Code
An NDR bounce message includes a status code (like 5.7.1 or 4.4.7) that identifies the failure category precisely. A 5.x code means permanent failure (the message won't be retried — invalid recipient, policy rejection); a 4.x code means temporary failure (Exchange Online will keep retrying for a period before giving up — often a receiving server's temporary block or greylisting). Reading the specific code before assuming a generic "email is broken" saves significant diagnostic time.
Common Cause: Transport Rule Conflicts
Exchange Online's mail flow (transport) rules can inadvertently block or redirect messages matching criteria nobody remembers configuring — a compliance rule set up months ago for one purpose can silently catch unrelated mail matching similar conditions. Reviewing active transport rules in the Exchange admin center for anything that could match the affected message type is worth doing before assuming an external cause.
Common Cause: Connector Misconfiguration
If your organization uses a custom connector (routing mail through a third-party filtering service, or a hybrid setup with an on-premises server), a misconfigured connector can silently drop or misroute mail that would otherwise deliver fine through Exchange Online's default path. This is more likely in organizations with more complex mail routing than a straightforward Microsoft 365-only setup.
Common Cause: Recipient-Side Rejection
Some NDR codes clearly indicate the problem is on the receiving end — the recipient's mailbox is full, their domain doesn't exist, or their server explicitly rejected your message for a policy reason on their side. In these cases, no configuration change on your Microsoft 365 tenant will fix it; the resolution requires the recipient to address it on their own system.
Common Cause: Message Trace Reveals the Real Path
The Exchange admin center's Message Trace tool shows the exact path a specific message took — accepted, delivered, or where it stopped and why — for messages sent within the last several days. This is the single most useful diagnostic tool for a specific missing message, far more precise than guessing from a general symptom description.
When to Escalate to Microsoft or Your Reseller
If Message Trace shows the message stuck or rejected at Microsoft's own infrastructure with no clear recipient-side or transport-rule explanation, that's the point to open a support case with Microsoft (directly or through your Microsoft 365 reseller) — bring the specific NDR code and Message Trace details, which dramatically speeds up getting a useful answer rather than a generic first-line response.
A Reference Table of Common NDR Codes
| Code | Meaning |
|---|---|
| 5.7.1 | Permanent rejection, often a policy or content filter block |
| 5.1.1 | Recipient address doesn't exist |
| 4.4.7 | Message expired in the queue after repeated temporary failures |
| 4.7.26 | Authentication (SPF/DKIM) issue causing a temporary throttle |
A Note on Third-Party Filtering Layers
Organizations that route mail through an additional third-party security or archiving service before it reaches Exchange Online add another layer where delivery can fail — if Message Trace shows a message leaving that third-party layer but never registering in Exchange Online, the fault sits with that connector's configuration specifically, not with Microsoft 365 itself.
