Microsoft
Microsoft 365 and Defender delivery
Separate sender-side failures from recipient tenant filtering and mail-flow policy.
Identify the receiving system
A corporate domain can use Microsoft 365 with additional gateways and tenant-specific policies. Outlook.com SNDS data does not explain every Microsoft 365 decision. Collect the complete non-delivery report or the headers of an accepted message and identify which hop made the decision.
Read the available evidence
| Evidence | Use |
|---|---|
| Complete NDR | Read the diagnostic text, generating server and remote response. 550 5.7.1 alone is not a unique diagnosis. |
| Authentication-Results | Check the authentication outcomes and evaluated identities at the trusted receiver. |
| X-Forefront-Antispam-Report | Consult Microsoft’s documented fields, including CAT and DIR, to understand filtering context. |
| Recipient-side trace or quarantine | Ask the authorized tenant administrator to identify the actual action and matching policy. |
Interpret the documented fields together with the recipient-side trace. Internal values and individual header numbers do not provide a complete explanation of cloud filtering.
Resolve the actual cause
- Repair sender authentication or message-generation faults identified by the evidence.
- For a recipient restriction or mail-flow rule, ask the recipient administrator to review the intended policy.
- For suspected false detection, preserve the original message and ask the authorized administrator to use Microsoft’s submission workflow.
- Retest with a newly generated message through the same route, then compare the recipient-side result.