Are you waiting for an invoice or a reply on Hotmail.com (or outlook.com), but nothing appears in your inbox, not even in junk mail? In some cases reported since early November, the problem occurs upstream: the destination server rejected the email and a non-delivery notice was sent to the sender. The person waiting for the message may therefore find out only if they are contacted another way.
Windows Latest dates the first reports to at least 5 November 2026 and says it reproduced the problem on 8 November. The following day, on Microsoft Q&A, a moderator identified as Microsoft External Staff described degraded delivery to Outlook.com, Hotmail, and Live.com, with investigations into the cause still underway.
What is happening to the mail
The most similar cases have one detail in common: someone writing to a personal Microsoft address receives a non-delivery report, also called an NDR or a bounce. In some cases, the report shows 550 5.7.23, which the Microsoft documentation for Exchange Online associates with SPF validation issues. The remote server’s response details may also include 550 5.7.1, along with the reference AS9031519 and a message about SPF, DKIM, and DMARC checks.
A case posted on Microsoft Q&A concerns a Microsoft business account 365 that could deliver to Gmail and AOL, but received these errors when sending to Outlook.com and Hotmail. This distinction is useful: a business account can be involved as the sender, without demonstrating a widespread issue with incoming mail to Exchange Online business mailboxes.
If the server rejected the message, searching junk mail will not make it appear. Checking folders still makes sense when an email is missing and you do not yet know whether it was accepted or rejected.
SPF, DKIM, and DMARC: why the code alone is not enough
| Check | What it verifies |
|---|---|
| SPF | Whether the sending server is authorized to use the SMTP sender’s domain. |
| DKIM | Whether the message’s digital signature is valid for the domain that applied it. |
| DMARC | Whether at least one of SPF and DKIM passes and is aligned with the domain shown in the Fromfield, according to the specified alignment rules. |
A record published in DNS and a check that passes on an individual message are two different things. For example, a newsletter service may sign correctly with its own domain, but that signature may not be aligned with the domain the recipient sees in the From. Microsoft explains how to read these results in its guide to diagnosing email authentication.
The relay provider Teneo documented a rejection observed in its logs on 7 November: the sender’s domain had working SPF and DKIM in the case described, but no DMARC record. At the same time, some users on Q&A report intermittent rejections despite saying that all three checks are configured. Windows Latest also reports a case where a new attempt was delivered after the first rejection.
The two findings help show where to start. If DMARC is missing, there is a specific configuration to check. If a second attempt is delivered, the headers of the delivered message show how that attempt was evaluated: on their own, they do not prove that the first one followed the same route or passed the same checks.
The update on 9 November and reference EX1540236
In the discussion SPF Validation Error on Microsoft Q&A, the moderator said that the service was degraded and that analyses of service data and customer-provided examples were underway. The response did not specify a definitive cause or a restoration date.
The reference EX1540236 is circulating in reports collected by BornCity. The notice and its scope have not been verified directly in the admin portal. If you manage a Microsoft 365, you can check whether the reference appears in Health > Service health, in the Microsoft 365 admin center.
There is also an existing Microsoft rule: domains sending at least 5.000 messages per day to Microsoft consumer addresses are subject to requirements for SPF, DKIM, and DMARC. Microsoft documents code 550 5.7.515. This is a reference distinct from the codes reported in these cases and does not prove that the same rule was extended to all senders on 5 November.
What to do if you’re waiting for an email on Outlook.com or Hotmail
Open your Outlook.com mailbox in a browser and search for the message by sender or subject. If you do not know the delivery status, also check junk mail, filters, and other folders.
If you cannot find the message, ask the sender whether they received a non-delivery notice. If so, ask them to confirm the code and, for an urgent communication, agree on an alternative address or another channel. A new attempt succeeded in some reported cases, but this should be verified with the recipient. Changing your mail app or adding the sender to your contacts cannot retrieve a message the server has already rejected.
What to check if you’re the sender or administrator
- Keep the full NDR. In addition to the summary, you need the remote server’s response, the date and time with time zone, and the destination domain. If you use Exchange Online, look for the attempt in Message trace and also keep the Network Message ID when available.
- Check the domain configuration for the actual sending flow. A message sent from webmail, an invoice sent by an accounting system, and a newsletter may be sent through different services. Check which servers are authorized by SPF, which domain signs with DKIM, and whether DMARC alignment is in place.
- Change DNS only if you find a problem. If DMARC is missing, whoever manages the domain can consider an initial monitoring configuration, with
p=noneand an address for aggregate reports. Do not lower an existing policy fromquarantineorrejectbased on these reports:p=noneis an observation phase, not a general fix for rejection. - If the rejection continues, open a support case with recent examples. Send the NDR and tracking details to your provider or Microsoft support. If you compare a successful attempt with a rejected one, clearly indicate which diagnostics belong to each. Avoid posting complete headers containing addresses or other confidential data in a forum.
Investigation status: 9 November 2026.