Read the complete Microsoft response in context
A Microsoft-related rejection does not automatically mean SPF, DKIM or DMARC is broken. The response may concern recipient restrictions, a tenant policy, sending reputation, forwarding, routing or authentication. Start with the full SMTP transaction or delivery-status notification, identify the service that generated it and locate the point of failure. A familiar 5.7 prefix is a classification clue, not a complete diagnosis.
This article uses Microsoft primary NDR guidance retained on 8 November 2026, together with DSN and authentication specifications. Its detailed code mappings are scoped to the cited Exchange Online documentation. They must not be assumed to describe every Outlook.com consumer response, on-premises Exchange system or third-party gateway. No tenant, recipient or live transaction was inspected here.
Identify the route and recipient class
Record whether the destination is a Microsoft 365 organizational tenant, a consumer mailbox or a route through another filtering service. Identify whether the affected recipient is an ordinary mailbox, group or mail-enabled public folder. The sending route matters too: direct internet delivery, authenticated submission and a configured connector are different contexts. Without these facts, the phrase “Microsoft blocked us” may assign responsibility to the wrong system.
Preserve both the reporting server and the remote diagnostic. An NDR can be generated by one server while quoting a refusal from another. RFC 3464 provides separate machine-readable fields for reporting and per-recipient delivery information. Keep that structure intact in the evidence package rather than treating every server name in a bounce as the rejecting endpoint. RFC 3464
Do not decode 5.7.1 as one universal cause
Microsoft's 550 5.7.1 article describes several possible contexts, including restrictions on external senders, mail-flow rules, public-folder authentication requirements and blocklist-related diagnostics. The full text distinguishes these cases. A response containing RESOLVER.RST.AuthRequired in the documented public-folder scenario concerns recipient delivery restrictions; it is not automatically an instruction to repair the sender's DMARC record. Microsoft 5.7.1 guidance
Do not immediately relax a recipient policy because the sender wants delivery. The recipient owner must decide whether the message should be accepted under the intended business rules. Likewise, an external sender cannot correct a recipient-side restriction simply by adding more SPF mechanisms. The investigation should identify the responsible boundary and seek the appropriate owner's review before proposing changes.
Use specific authentication diagnostics narrowly
Microsoft's Exchange Online NDR reference maps 5.7.23 to an SPF violation and 5.7.509 to a sending domain that fails DMARC with a reject policy. These are useful distinctions when the actual response matches. Preserve the named domain and route context through an approved evidence process, then inspect the corresponding authentication identity and policy rather than applying a generic “deliverability fix.” Microsoft NDR reference
The same reference maps 5.7.513 to a recipient-domain custom block list and 5.7.520 to blocked automatic external forwarding. Those conditions need different owners and evidence from an SPF failure. The examples are documentation mappings, not codes observed in a real message here. Do not transplant them to unrelated services or assume that every diagnostic sharing the first digits has identical semantics.
Keep authentication verdicts separate from disposition
If a message was accepted far enough to yield trusted headers, inspect the actual SPF, DKIM, DMARC and Microsoft composite-authentication fields individually. Microsoft explains that composite authentication uses multiple signals and that failure does not directly imply blocking; other assessments can influence handling. Conversely, passing authentication does not promise inbox delivery. Microsoft authentication explanation
For a message refused before delivery, there may be no recipient-side received-message header available to the sender. Do not fabricate a header result to explain an SMTP refusal. Use the transaction and DSN evidence for the failed stage, and obtain authorized recipient-side diagnostics only when needed and available. A later successful message is a separate observation, not a substitute for the missing original evidence.
Original failure-classification worksheet
This proposed worksheet keeps response interpretation tied to the actual route. It is not a completed diagnosis or a permission to change a policy.
- Recipient class: consumer service, organizational tenant, group, public folder or other gateway.
- Sending route: service, connector or submission method and relevant owner.
- Time and stage: explicit time zone, transaction point and reporting or remote server.
- Full response: basic reply, enhanced code and complete diagnostic text.
- DSN structure: affected recipient, Action, Status and Diagnostic-Code.
- Category: authentication, recipient restriction, tenant policy, routing or unresolved cause.
- Responsible party: sender administrator, recipient administrator, provider or business owner.
- Closure plan: approved correction, controlled observation and outcome limitations.
Retain an untouched original internally and prepare a redacted support copy with a field map. If the supplier needs a specific identifier to correlate a trace, confirm the recipient and disclosure before adding it. Do not remove all route information and then expect the support engineer to distinguish a consumer service from an enterprise connector failure.
Fictional example: an external supplier reaches a restricted folder
Fictional Copper Vale can send to a customer's ordinary mailbox but receives a refusal when addressing a mail-enabled public folder. The proposed review notices that the diagnostic refers to an authentication-required recipient condition, consistent with the documented public-folder scenario. It does not conclude that the supplier's entire domain has failed DMARC merely because the response contains 5.7.1.
The next step would be to confirm the actual recipient class and intended acceptance policy with the customer's administrator. Any change to external-sender restrictions would require that owner's authorization. A separate authentication check could still be useful, but it would not replace the recipient-policy decision. Copper Vale is fictional; no folder, tenant, response or policy was inspected or changed.
Report the narrow outcome and remaining work
A useful support summary says which response was observed, which documented category it matches and which evidence remains missing. Avoid promises that an allow-list entry, DNS edit or retry will solve every delivery problem. If a correction is approved, retain a fresh controlled observation showing whether the previously failing stage changed. Keep inbox placement and business receipt outside the conclusion unless separately observed.
The catalogue requires a redacted SMTP transaction or DSN with route, recipient class, timestamps and full response. None has been supplied for an actual incident. Original evidence, human SME, source applicability, production routes, visual accessibility and owner release remain open. This draft explains classification and ownership, not a verified Microsoft remediation.