Senders report Outlook.com email authentication bounces
News
Published 6 Nov 2026
Updated 6 Nov 2026
5 min read
Summarize with
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) appears in firsthand reports of intermittent SMTP rejections for messages sent to Outlook.com and Hotmail consumer recipients on November 5-6, 2026. The reports describe failed delivery attempts alongside successful deliveries, including a message that arrives after being resent.
The reporting cutoff is November 6, 2026 UTC, November 7 in Sydney. These reports matter for transactional email and ordinary correspondence reaching consumer Microsoft inboxes. They do not establish an issue affecting all Exchange Online recipients, or confirm a new authentication policy.
What the firsthand reports describe
A November 6 question on Microsoft Q&A concerns incoming messages being blocked at a personal Outlook.com account. A separate commenter describes intermittent rejections on November 5-6 across two personal Outlook.com accounts and different sending providers. The examples include a Zoho message that is rejected and then successfully resent.
A second November 6 report comes from a Microsoft 365 business sender describing rejections when sending to Outlook.com and Hotmail recipients. That report includes 550 5.7.23, an SPF violation diagnostic, alongside AS9031519. The sender reports successful delivery to other providers in that example.
The SPF, DKIM and compauth passes discussed in the first thread belong to the delivered resend. They do not establish the authentication results for the rejected attempt. A Microsoft staff moderator provides generic troubleshooting, without confirming an incident or policy change.
What remains unconfirmed
As of the reporting cutoff, no public provider confirmation of a rollout, root cause, remediation, new threshold, deadline or universal low-volume policy is identified. The reports do not establish a wider rejection rate or confirmed provider fault.
AS9031519 is distinct from the high-volume policy code
Microsoft's 550 5.7.515 documentation describes the separate authentication requirements for high-volume senders introduced in 2025. That documented error concerns the authentication level required for a sender's visible From domain when sending to Microsoft consumer email services.
The November reports use different diagnostics. The presence of an authentication-related rejection does not establish that the 2025 policy has changed or expanded to every low-volume sender. Keep the entire receiving-server response, because the generic 550 5.7.1 code alone does not identify AS9031519.
|
|
|
|---|---|---|
550 5.7.1 | AS9031519 reports | Full diagnostic |
550 5.7.23 | SPF violation report | Envelope sender/IP |
550 5.7.515 | High-volume policy | Policy requirements |
Different diagnostics require separate investigation.
Checks for affected sending streams
A password reset, receipt or account notification rejected at SMTP does not reach the recipient's inbox. Ordinary person-to-person messages also warrant investigation. A successful delivery to another provider helps narrow the observed destination, but does not establish how Outlook.com evaluated the failed message.
I would start with the rejected sending stream and its exact diagnostic. Separate consumer Outlook.com and Hotmail destinations from business domains hosted in Exchange Online. An Outlook application on a recipient's computer does not identify the receiving email service.
- Bounce grouping. Group failures by exact SMTP/NDR code, timestamp with timezone, sending stream, receiving hostname and recipient domain. Keep the original NDR and distinguish its generating server from the server that rejected delivery.
- SPF. Check the actual envelope sender domain and the outbound IP used for the failed attempt. Confirm that its SPF record authorizes that IP. Checking only the visible From domain misses a different return-path domain.
- DKIM. Check whether the actual sending stream signs messages. Identify the signature's signing domain and selector, verify the corresponding public key, and validate the signature. A published DKIM record alone does not prove a particular message passes.
- DMARC. Verify a valid DMARC policy for the visible From domain. Check DMARC alignment with a passing SPF envelope sender identifier or a passing DKIM signing domain, using the policy's configured alignment mode.
Suped's domain health checker helps inspect currently published authentication DNS records. Use those results to find demonstrable configuration gaps, while retaining the original evidence: a current DNS lookup does not reconstruct the receiving server's lookup or evaluation at the time of rejection.
Compare controlled tests with the failed attempt
Send a controlled test through the same sending stream to a consumer Microsoft account you control. Record the time and outbound IP, preserve any NDR, and inspect the full headers if delivery succeeds. Compare the envelope sender, DKIM signing domain and selector against the failed attempt where logs expose them.
Suped's email tester analyzes authentication on a separate test message. That is useful for checking the stream's configuration, but it does not reproduce Outlook.com's decision. Headers from a controlled message delivered to Outlook.com provide evidence about that specific Microsoft delivery.
Rejected attempt
The NDR records the failed delivery and the receiving server's diagnostic. Unless it includes individual authentication results, it does not establish which specific check failed. Correlate it with sending logs.
Delivered test
The headers describe the accepted sample. Passing authentication on a resend does not prove the earlier attempt passed, explain the earlier rejection, or establish that recurring failures are resolved.
Fix verified gaps and escalate recurring failures
Correct demonstrable SPF authorization problems or DKIM signing failures, then retest the affected stream. Repair invalid DMARC configuration without replacing an existing policy unnecessarily. Changing a working enforcement policy to p=none does not guarantee delivery and does not fix missing signatures or an unauthorized outbound IP.
For recurring cases, escalate through Outlook.com Sender Support with redacted NDRs and relevant sending logs. Preserve exact codes, UTC timestamps, receiving hostnames and sending IPs, plus enough domain information to investigate authentication. Include a delivered comparison sample and label it separately. Remove personal message content and private recipient details.
A personal Outlook.com or Hotmail recipient cannot edit Outlook.com's authentication DNS. Ask the sending administrator or sending provider to investigate the affected stream and collect the receiving-server evidence. Keep existing security controls while the failure remains unexplained.
Frequency asked questions
No. The November 5-6 reports describe individual authentication-related rejections. As of November 6, 2026 UTC, they do not establish a new rollout or universal low-volume requirement. Microsoft documents 550 5.7.515 separately for its high-volume policy.
It provides evidence about the delivered resend. Its SPF, DKIM or compauth results do not establish the rejected attempt's results. Keep both samples and compare the actual sending paths.
Do not weaken a working policy merely to test this diagnostic. Fix verified configuration gaps and check alignment with a passing SPF or DKIM identifier. A p=none policy does not guarantee acceptance by Outlook.com.
