Start with the enhanced status family, then read the provider text
An Exchange Online NDR normally includes an enhanced status code such as 5.1.10, 5.4.14 or 5.7.509 plus descriptive text. The first digit separates temporary and permanent outcomes, while the later digits narrow the failure class. Do not stop at a broad family such as 5.7.1: Microsoft can use adjacent codes for recipient policy, authentication, transport security, abuse controls and connector attribution. Preserve the complete NDR so the provider-defined text stays attached to the code.
Route recipient and message-format failures to identity evidence
Codes in the 5.1 family often point to addressing or message-originator structure. A recipient-not-found result should lead to the exact SMTP address, alias history and recent directory changes. A multiple-From-addresses error should lead to the raw From and Sender fields in the generated message. These failures are usually better diagnosed from the message and directory intent than from public DNS.
Route 5.4 failures to the transport path
Routing loops and MTA-STS MX validation failures describe how the message is moving between systems. For a routing loop, reconstruct the Received chain and look for repeating hosts, smart hosts or domains. For an MTA-STS validation problem, compare active MX targets with the policy that is supposed to authorize them. The correct fix lives in the route or transport policy, not in content rewriting.
Split 5.7 authentication failures by the identity that failed
SPF violations, DMARC reject failures, reverse-DNS requirements and relay-authentication errors all live in the broad security and policy family but require different evidence. SPF needs the envelope domain, actual sending IP and recursive policy. DMARC needs the visible From domain plus aligned SPF or DKIM. IPv6 reverse-DNS failures need the exact connecting address and PTR identity. Submission or connector errors need the endpoint and relay design.
Treat forwarding-specific failures as a chain problem
A forwarded message can fail SPF because the final receiver sees the intermediary IP, and intermediaries can also modify content that was covered by DKIM. Microsoft documents a dedicated forwarded-or-relayed failure path for authentication problems. Inspect ARC, Authentication-Results and the Received chain together before changing the original sender. A valid fix may belong to the forwarding gateway rather than the source domain.
Separate configuration failures from abuse enforcement
Some Exchange Online responses indicate blocked accounts, IP reputation or tenant thresholds rather than a malformed record. Unexpected volume should be investigated as a possible security incident before anyone attempts reputation remediation. Confirm the actual sending account, source IP, connector and recent traffic change. Restoring a compromised sender without removing the source of abusive traffic simply recreates the condition.
Use the error page as a router, not a substitute for the bounce
A useful error-code library tells you which evidence to gather next. It should not claim that the numeric code alone identifies the exact root cause in every environment. Mailybox routes SPF failures to recursive SPF analysis, TLS failures to transport-security checks, forwarding failures to ARC analysis, route loops to header reconstruction and ambiguous provider responses to Mail Failure Doctor so the complete diagnostic remains part of the investigation.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.