Key takeaways
- From around 4–5 November 2026, users reported Outlook.com, Hotmail and Live.com bounces reading
Message lacks SPF/DKIM/DMARC Auth Records (AS9031519), often intermittently. [1] [2] - On 9 November a moderator labelled Microsoft External Staff described an ongoing Exchange service issue under investigation. When we checked on 10 November, Microsoft had published no root cause and no new rule for low-volume senders. [2] [3]
- Check that your From domain has exactly one DMARC record, an SPF record that covers every sending service, and DKIM signed with your own domain. [6] [7] [8]
- If you have no DMARC record, start at
p=nonewith reports you will actually read. Do not jump top=rejectto answer one provider’s bounces. [5] [7] - Keep complete bounce messages and report repeated rejections to Microsoft instead of mass-resending. [1] [2] [4]
What senders and recipients reported
Since around 4–5 November 2026, people on Microsoft’s public Q&A forum have described mail to personal Outlook.com, Hotmail and Live.com addresses bouncing with 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519). The reports involved senders on several different mail providers, and some users said the same message was accepted when it was sent again a short time later. [1]
A second thread shows a longer form of the same bounce: 550 5.7.23 The message was rejected because of Sender Policy Framework violation, followed by the 5.7.1 text. A volunteer contributor there summarised the pattern so far: some mail from domains with valid SPF but no published DMARC record was rejected, yet rejections were also reported for domains with all three records in place, so a missing record did not appear to explain every case. [2]
What Microsoft has and has not said
On 9 November, a moderator labelled Microsoft External Staff posted in the second thread that, based on the information available to them, there was an ongoing Exchange service issue affecting messages to Outlook.com, Hotmail.com and Live.com addresses. The reply said affected users may see 550 5.7.1 or 550 5.7.23 bounces related to SPF validation, that the advisory was classified as a service degradation, and that Microsoft was investigating the cause. [2]
That is a forum reply, not a published policy change. When we checked on 10 November, Microsoft’s public service status page listed all products, including its consumer services, as operational, and a volunteer in the thread had found no public Microsoft acknowledgement of a change in enforcement for low-volume senders. At least one user also wrote later on 9 November that the rejections had stopped for their company. Treat both the cause and any fix date as unconfirmed for now. [2] [3]
The rules that were already in place
Separately from this incident, Microsoft announced in April 2025 that domains sending more than 5,000 messages a day to Outlook.com consumer addresses must pass SPF and DKIM and publish DMARC at least at p=none, aligned with SPF or DKIM. Mail from those senders that fails is rejected with 550 5.7.515, a different code from the one in the November reports. Microsoft also said that all senders benefit from the same practices, even though enforcement started with large senders. [4]
Google’s sender guidelines set a similar baseline for Gmail. Every sender needs SPF or DKIM, and bulk senders need SPF, DKIM and DMARC. To pass DMARC, SPF or DKIM must pass for a domain that matches the address in the visible From header. If your records already meet these baselines, the sensible response to an intermittent Outlook.com bounce is to save the evidence and report it, not to rebuild a working setup in a hurry. [8]
Check your own records first
Look up the TXT record at _dmarc in front of your From domain. There should be exactly one record that begins with v=DMARC1. RFC 9989, the current DMARC standard published in May 2026, says that when a receiver finds more than one DMARC policy record for the same name it discards all of them, which leaves the domain with no usable policy at all. Duplicates can appear when two teams or two tools each add a record of their own. [7]
Next, confirm that SPF lists every service that sends as your domain, and that DKIM signs with your own domain rather than only a provider’s default domain. Microsoft’s documentation, for example, says Microsoft 365 does not DKIM-sign outbound mail from a custom domain until DKIM is set up for that domain, and that a DKIM signature only counts towards DMARC when the signing domain aligns with the From domain. Google describes DMARC alignment in the same way. [6] [8]
If your domain has no DMARC record yet
Several forum contributors reported that publishing a minimal monitoring record, v=DMARC1; p=none;, stopped the rejections for their senders. For a domain with no DMARC record at all, that is a low-risk step, because under the standard p=none asks receivers not to change how they treat mail because of the policy. It is still not proof of the cause, and other users reported rejections even with complete records in place. [1] [2] [7]
Add a rua reporting address that someone actually reads, or a reporting service, so you can see which systems send as your domain. Both RFC 9989 and Microsoft describe the same order: start at p=none, fix any legitimate mail that fails, and only then move to quarantine or reject. The standard notes that getting to enforcement can take many months of aggregate reports. Changing straight to p=reject in response to one provider’s bounces risks blocking your own legitimate mail elsewhere. [5] [7]
Save the evidence and report it
When a message bounces, keep the whole bounce message rather than a screenshot. The useful details are the timestamp, the rejecting server, the sending IP address, the full status line including the AS reference, and the authentication results. Contributors in both threads asked for exactly this, and the Microsoft moderator asked affected users to give Microsoft Support fresh Network Message IDs, message logs and sample messages in .eml format. [1] [2]
Senders can open a case through Microsoft’s sender support form for Outlook.com, which is linked from the Outlook.com postmaster site. Recipients with personal accounts can report the problem from the help menu inside Outlook.com. If you send through an email service provider, ask whether it has seen the same code across other customers, and avoid resending large batches while the cause is unclear. [1] [2] [4]
Example: a quick record check
Synthetic output for illustration only. The domain, selector, address and key are placeholders.
$ dig +short TXT _dmarc.example.com"v=DMARC1; p=none; rua=mailto:(your report mailbox)"$ dig +short TXT example.com | grep spf1"v=spf1 ip4:192.0.2.10 include:spf.example.net -all"$ dig +short TXT s1._domainkey.example.com"v=DKIM1; k=rsa; p=MIIBIjAN…"This shows one DMARC record at p=none with a reporting address, one SPF record that names the sending services, and a published DKIM key for the selector the provider signs with. Records like these are the starting point. Alignment still has to be confirmed in the headers of a real delivered message, and no record set can rule out a fault on the receiving side.
Outlook.com rejection checklist
- 01Save the full bounce message: timestamp, rejecting server, sending IP, the complete 5.7.x status line and any
ASreference. - 02Confirm there is exactly one
v=DMARC1TXT record at_dmarcfor your From domain. - 03Check that SPF covers every system that sends as your domain and that DKIM signs with your own, aligned domain.
- 04If you have no DMARC record, publish
p=nonewith a report address you will monitor; do not jump top=reject. - 05Retry a small number of affected messages and record the result instead of resending whole batches.
- 06Report repeated rejections through Microsoft’s sender support form and keep the case reference.
Check the source
Numbered citations link to the documents behind each claim. Rules and policies change, so check the current version before changing a live sending program.
- [1]Incoming emails being blocked due to lack of SPF/DKIM/DMARC records on my @outlook.com account — Microsoft Q&A User reports from around 4–5 November 2026 of intermittent 550 5.7.1 rejections including AS9031519, a resend later accepted, the minimal p=none workaround reported by contributors, and advice to keep complete bounce messages and report them from Outlook.com.
- [2]SPF validation error — Microsoft Q&A The 550 5.7.23 to 550 5.7.1 bounce text, the volunteer summary that missing DMARC did not explain every case, the 9 November reply from a moderator labelled Microsoft External Staff describing an ongoing Exchange service issue classified as service degradation, the request for Network Message IDs and .eml samples, and later reports that rejections had stopped.
- [3]Microsoft service health status Microsoft’s public status page listed all products, including consumer services, as operational when checked on 10 November 2026.
- [4]Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders — Microsoft Defender for Office 365 Blog The April 2025 Outlook.com requirements for domains sending over 5,000 messages a day (SPF, DKIM, DMARC at least p=none with alignment), the 550 5.7.515 rejection, the note that all senders benefit, and the link to Outlook.com sender support.
- [5]Set up DMARC to validate the From address domain for cloud senders — Microsoft Learn Microsoft’s recommended DMARC rollout: configure SPF and DKIM first, publish the TXT record at _dmarc, start at p=none and monitor, then move to quarantine and reject.
- [6]Set up DKIM to sign mail from your cloud domain — Microsoft Learn Microsoft 365 does not DKIM-sign outbound mail from custom domains until DKIM is configured, and DKIM passes DMARC only when the signing domain aligns with the From domain.
- [7]RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF The May 2026 DMARC standard: starting at p=none with rua reporting as monitoring mode, the meaning of p=none, many months of reports before enforcement, and discarding all records when more than one DMARC record is found.
- [8]Email sender guidelines — Google Workspace Admin Help Gmail’s baseline that all senders need SPF or DKIM, bulk senders need SPF, DKIM and DMARC, and DMARC passes only when SPF or DKIM authenticates a domain matching the From header.