Read the anatomy first
An NDR carries: the enhanced status code (class.subject.detail — 5.x.x permanent, 4.x.x transient), the remote server's verbatim response (the single most valuable line — it names WHOSE policy and often includes the reason or a lookup URL), and the failing hop. Rule one, always: the code tells you the family; the text tells you the culprit.
The family map
| Family | Domain | Typical suspects |
|---|---|---|
| 5.1.x | Addressing | 5.1.1 bad recipient (typo, deleted mailbox, stale MX-record targets); 5.1.10 recipient not found at Microsoft — the address genuinely doesn't exist in that tenant |
| 5.2.x | Mailbox state | 5.2.2 full mailbox; 5.2.3 message too large for the recipient's limit |
| 5.4.x | Routing | 5.4.14 hop-count loop — the hybrid/forwarding loop signature; 5.4.4/5.4.310 DNS/no-MX (check the recipient DOMAIN's records, not yours) |
| 5.6.x | Content | Conversion/format failures — rare, usually gateway middleboxes |
| 5.7.x | Policy & reputation | The big family — below |
5.7.x: the policy family in practice
- 550 5.7.1 — the generic "not allowed": far-side spam block, your own ETR rejection, or relay denial. The TEXT disambiguates; a URL in it (many receivers include a delisting/reason link) is your fastest path.
- 5.7.708 / 5.7.750 family — Microsoft throttling/blocking the SENDING tenant or connection: your outbound reputation is the story (high-risk-pool concept) — go hunting for the compromised mailbox or the runaway app, not the recipient's config.
- 5.7.51 / restricted-recipient class — the RECIPIENT is restricted (delivery management on the DL/mailbox); membership and sender-restriction settings, not transport.
- 5.7.13x — DL sender-restriction variants: the sender isn't in the allowed list of an internal group.
- Auth-flavoured 5.7.x (57x with SPF/DKIM/DMARC words in the text) — the trio module's territory; the receiving side is enforcing sender authentication your source path fails.
The triage discipline (four steps, no folklore)
- Read the far-side text in full (trace FAIL event or the NDR body).
- Classify by family — addressing/state/routing/policy.
- Locate the OWNER: your config, Microsoft's reputation systems, or the recipient's stack (the text names it more often than not).
- Prove the fix with a re-send + trace, and file the pattern (the NDR ledger below).
What to watch (proofs)
- Per-incident:
Get-MessageTrace/DetailFAIL events — the code+text pair captured verbatim into the ticket. - Fleet-level: NDR/failure-reason trends in mail-flow reports — a new code spiking is an outbound-reputation or config event announcing itself (5.7.708 trending = drop everything).
- The NDR ledger: your estate's recurring codes with the proven local cause — institutional memory that turns repeat bounces into one-minute closures (and, on this site, the searchable page you're reading).
- Loop insurance: alert on 5.4.14 occurrences at all — loops are always config, always yours, always worth immediate attention.