Some Outlook.com and Hotmail users may be missing legitimate messages because incoming mail is being rejected before it reaches their inbox. Windows Latest reports authentication-related delivery failures dating back to November 5, including complaints from senders who believe their domain settings are already correct.
For anyone waiting on an invoice, customer reply, or appointment confirmation, the immediate problem is visibility: the sender may receive a bounce while the recipient sees nothing. An empty inbox is not proof that nobody tried to contact you.
The practical response is to confirm delivery through another channel, collect the rejection details, and investigate authentication without weakening existing protections. The reporting does not establish a universal fix or a confirmed Microsoft root cause.
What has been reported
Windows Latest’s Mayank Parmar describes personally encountering the problem and cites reports from Microsoft’s forums and Reddit. Examples include messages rejected by Hotmail while a separate recipient using Gmail received the same communication, and messages that arrived after the sender tried again.
Reported rejection notices include 550 5.7.23, associated with SPF failures, and 550 5.7.1 accompanied by wording about missing SPF, DKIM, or DMARC records and the identifier AS9031519.
These examples are useful diagnostic clues, not evidence that every failure has the same cause. A sender’s assertion that DNS is correct also needs to be checked against the actual system that sent the rejected message.
The source says Microsoft had not publicly confirmed the cause at the time of its reporting. It does not establish that all Outlook users are affected, nor that Exchange Online business mailboxes face an identical service-wide problem. Here, “Outlook” primarily concerns Microsoft’s consumer email service, not necessarily the Windows desktop application.
If you are waiting for an email
Start with the person or organization you expected to hear from. Use a known phone number, an existing messaging conversation, or another trusted channel to ask whether they received a delivery failure. Avoid assuming that silence means they never replied.
Check your junk folder, inbox rules, blocked senders, and mailbox storage as normal troubleshooting steps. However, a message rejected during delivery will not simply be waiting in the junk folder. Adding someone to a safe-senders list is not a dependable workaround for a server-side authentication rejection.
Ask the sender to preserve the complete bounce notification. If the message is urgent, agree on an alternative delivery method appropriate for its sensitivity. Do not move confidential documents to an unfamiliar account merely because someone claiming to be the sender suggests it.
A single resend after a short interval may help: the source describes successful retries. Treat that as a temporary measure, not confirmation that the underlying problem has disappeared. Confirm receipt explicitly for important messages.
If you administer the sending domain
Separate evidence collection from configuration changes. Capture the full non-delivery report, timestamp with time zone, recipient domain, sending service, and outbound IP address where available. Keep message IDs and mail-provider trace records so support can investigate the particular attempt.
Then check the authentication path used by that message:
- SPF: Confirm that the domain evaluated for the envelope sender authorizes the actual sending infrastructure. Check for duplicate SPF records and excessive DNS lookups rather than simply adding another record.
- DKIM: Confirm that the sending service signs messages and that its selector resolves to the correct public key. Having a DNS key published does not prove every outgoing message is signed correctly.
- DMARC: Check that the visible From domain aligns with a passing SPF or DKIM identity. Merely having three authentication records does not guarantee that a particular message satisfies DMARC.
- Routing: Look for forwarding, third-party applications, scanners, or marketing services that send through a different path from ordinary staff mail.
If a later attempt succeeds, inspect its authentication results and compare the route with the failed attempt. A passing result on a delivered copy cannot prove that the earlier rejected copy used identical infrastructure or received identical checks.
Do not weaken security to chase an intermittent failure
Windows Latest includes a user report that adding a missing DMARC record with p=none appeared to resolve delivery failures. That is an individual observation, not a broadly validated repair procedure.
A monitoring-only DMARC policy can be part of a planned deployment, but changing an existing enforcement policy to p=none reduces the protection requested for failing mail. Do not make that change solely because another sender reported success. Similarly, avoid broadening SPF permissions to infrastructure you do not control.
Where a genuine configuration error is found, correct it deliberately and retest. Where authentication appears sound but rejections continue, escalate with the complete evidence rather than repeatedly editing DNS. Share diagnostic information privately with your provider or Microsoft support, not in public screenshots containing customer addresses or message content.
Keep delivery monitoring practical
For a small business, the most useful short-term safeguard is to review bounce notifications and identify time-sensitive conversations with affected recipients. Test through the real sending application, not just a different mailbox that happens to use the same domain.
The takeaway is straightforward: verify receipt, preserve the failure evidence, and change authentication settings only when the investigation supports it. Successful retries are encouraging, but they are not a substitute for a confirmed diagnosis.