Since November 5, 2026, Microsoft's consumer mail platform has been rejecting messages from domains that have no DMARC record, including low-volume domains with valid SPF and DKIM. There was no announcement, there is no documentation, and four days in, Microsoft has not said a word. We saw it in the bounce telemetry we monitor. This is what the operator community has pieced together so far.
On Friday November 7, 2026, at 18:00:29 UTC, a routine notification from a Belgian sender to an outlook.be address was refused by Microsoft. The rejection landed in the SMTP telemetry Engagor monitors:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) [DB1PEPF000509E3.eurprd03.prod.outlook.com 2026-11-07T18:00:29.972Z 08DF3BF680DF8A1F]
Two seconds later a second message from the same domain was refused by a different Microsoft edge server with the same text. The sending domain had a correct SPF record that covered the sending server, and the message carried a valid DKIM signature from the domain's own selector. By every published Microsoft rule, that mail should have been accepted. It was bounced with a permanent 550, which means the sending MTA did not retry, and the recipient never got the message.
We were not alone, because between November 5 and November 8 the same rejection showed up on the mailop operators' list, on Mastodon, on Hacker News, in at least six Microsoft Q&A threads, and in the logs of MXroute, MailRoute, Fastmail, Mythic Beasts and one.com. Every one of those operators reached the same conclusion we did: Microsoft's consumer platform has quietly started requiring a DMARC record from everyone.
What the Bounce Says, and What It Does Not
The rejection is worth reading closely, because it is unlike anything Microsoft has documented.
It is a 550 5.7.1. That is a permanent failure. A compliant MTA bounces the message and does not retry. One vendor write-up this week described these as "soft bounces", which is their product's suppression policy and not what the SMTP code says. If a message got this response, it was not delivered and will not be delivered unless somebody sends it again.
The text is new. "Message lacks SPF/DKIM/DMARC Auth Records" does not appear on Microsoft's postmaster troubleshooting page, in the Exchange Online NDR reference, in the Outlook.com support articles, or in Microsoft's email-authentication troubleshooting guide. We checked all of them on November 8. Microsoft's own AI-generated answer on one of the Q&A threads concedes that "AS9031519 is not defined in the available Microsoft documentation."
The AS code arrived a day late. MailRoute reports that on November 5 the same rejection came back without the "(AS9031519)" suffix, and that the code was added on the second day. Nobody outside Microsoft knows what the code means, and we are not going to guess.
It fires from consumer MXes only. Every rejecting host reported so far sits behind an *.olc.protection.outlook.com MX, which is the consumer Outlook.com platform that serves outlook.com, hotmail.com, live.com, msn.com and the national variants such as outlook.be. The bracketed server names span Europe (eurprd02, eurprd03), Asia-Pacific (apcprd03) and North America (namprd03, namprd04), so this is a global change rather than a regional one.
Microsoft 365 recipients are not affected. Al Iverson tested delivery to a Microsoft 365 hosted domain and it was accepted. Other reports describe the same split: Gmail and Exchange Online recipients get the mail, consumer Outlook recipients bounce it.
Four Days of Reports
The earliest dated observation comes from Mythic Beasts, a UK hosting provider, who wrote on Mastodon on November 6 that they had seen the message "over 500 times yesterday, but not once before then." Another admin in that thread put the start at "yesterday early morning" UK time, which places the change in the early hours of Thursday November 5. MailRoute independently dates its first bounces to November 5.
By the morning of November 6, Microsoft's Q&A forum had several threads open. The largest of them, titled "SPF Validation Error", collected more than sixty "same question" votes within two days. An IT contractor posted that four separate businesses they managed were affected, with the rejections hitting random users rather than a whole business at once.
Late on November 6, Jarland Donnell of MXroute opened a thread on mailop titled "Microsoft requiring DMARC now or just us?":
"In each case, the sender domain has correct SPF and DKIM. From what we're seeing, this just seems to trigger when the sender domain doesn't have a DMARC record. So I guess DMARC is now a requirement to send mail to Microsoft, they're pulling a Google and applying it at random, or they've targeted us and our customers for it."
The answers came quickly. Thomas Johnson of MailRoute: "Us too! We're currently seeing this for just a portion of emails sent to hotmail.com or outlook.com. Happening for users with perfectly valid SPF and DKIM, but who are missing DMARC of any type." Neil Jenkins of Fastmail: "We're seeing exactly the same for a bunch of customers with custom domains here at Fastmail. Very annoying. I can't see any announcement from Microsoft that they were going to start requiring this for low-volume domains." Julian Bradfield, an individual who sends around twenty emails a week to Microsoft addresses: "Me too. It only hit one of my MS-based members, not the others, so seems to be partly random. Notice would have been nice..."
On November 7, Al Iverson ran the experiment that settles the question of cause. He deleted the DMARC records from a handful of his own low-volume personal domains, sent test mail to Outlook.com, and reproduced the rejection in his Postfix log at 13:52 Central time. His conclusion on Spam Resource: "If you use that domain to send email, you need to have a DMARC record in place, not just SPF and DKIM." On whether Microsoft meant to do this, he was careful: "I'm not sure if this is an intended policy update in the world of Microsoft; time will tell."
The same day the mailop thread was posted to Hacker News, and Neowin and Windows Report ran stories, followed by Windows Latest on November 8. All three noted that Microsoft had not commented. As of November 8, that has not changed. There is no Tech Community post, no postmaster notice, no entry on the Outlook.com known-issues page (last updated May 2026), no Service Health incident that anyone has cited, and no Microsoft employee has replied on mailop, on Hacker News, on Mastodon or on Microsoft's own Q&A forum. The only Microsoft-badged voice in the whole episode is a contracted forum moderator who wrote that "contributors cannot confirm whether these reports have already been escalated to Microsoft's Outlook.com mail protection team."
What the Affected Domains Have in Common
Across every operator who looked at their own logs, the pattern is identical. The domains being rejected had SPF records that passed. Most had DKIM signatures that passed and aligned with the From domain. What they did not have was a _dmarc TXT record of any kind.
That is a strange thing to reject on. DMARC is a policy layer on top of SPF and DKIM. A domain without a DMARC record is telling receivers nothing about what to do with failures, but its mail can still be fully authenticated, and in these cases it was. Neil Jenkins made the point on mailop: "I can see requiring all mail to be authenticated with from-aligned SPF or DKIM, but at that point why require publishing a DMARC policy at all, if they're essentially ignoring it and treating it as p=reject anyway?"
Whatever the reasoning, the fix is consistent across every confirmed case. Publishing a minimal DMARC record stops the rejections. Mythic Beasts had "confirmation from one customer that adding a p=none policy appears to fix it." On Microsoft Q&A, a Microsoft 365 administrator reported that "Hotmail accepted my mail once the record showed up on MXToolbox", another that "the same emails that were rejected before are able to send okay now", and a third that after adding SPF and DMARC records they had "had no issues since." MailRoute contacted every customer without a DMARC record and told them to add one.
There is a second group of reports that does not fit as neatly. Several Q&A posters insist that their SPF, DKIM and DMARC were all in place and they were rejected anyway. We have not been able to verify any of those cases, and the two that were investigated in detail turned out not to have a DMARC record after all. In both, the sender had looked at message headers that said dmarc=pass and concluded the record existed. Microsoft's documentation explains one way this happens: when no DMARC record exists for a sender's domain, Microsoft 365 can record dmarc=bestguesspass, a heuristic pass that looks reassuring in a header and means nothing to another receiving server. If you believe you have DMARC because a header told you so, query DNS before you trust it.
Why It Looks Random
Almost every report uses the word "sporadic" or "random". The same domain gets one message accepted and the next rejected. A Zoho user's message was refused at 15:50 and accepted on resend at 16:09. The two rejects quoted at the top of this post hit two different edge servers two seconds apart, so it is not a question of one bad server either.
One observation from the mailop thread may explain part of it. Dan Malm, a systems engineer at one.com, wrote on November 8:
"After some digging it seems it only happens when a TXT for dmarc returns a NXDOMAIN result. I have two groups of domains, one group serves an NOERROR response without any result if they don't have the DMARC record. The other serves an NXDOMAIN. Only the NXDOMAIN group seems affected by this."
This is a single operator's finding and nobody has corroborated it yet, so treat it as a lead rather than a conclusion. But it is a plausible one. A nameserver that answers a _dmarc query with NXDOMAIN is saying the name does not exist; one that answers NOERROR with no data is saying the name exists but has no TXT record. If Microsoft's new check treats those two answers differently, that would explain why some DMARC-less domains sail through and others are blocked, and why the behaviour looks arbitrary from the outside.
The Microsoft 365 Twist
A large share of the confused reports this week come from Microsoft 365 business tenants, and there is a specific reason for that.
When a Microsoft 365 tenant sends to a consumer Outlook address and gets this rejection, Exchange Online wraps it in its own non-delivery report, which reads:
550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
The 5.7.23 headline says "SPF violation", so administrators spend their afternoon checking SPF, which was fine all along. The actual reason is in the second half of the line. One administrator described exactly this detour on Q&A: "That headline is misleading: my SPF and DKIM were both fine. The real problem was the detail line saying the message lacked SPF/DKIM/DMARC auth records. Even though Microsoft's own outbound headers said dmarc=pass, MXToolbox showed I had no DMARC record. M365 never creates one."
That last sentence is the important one. Microsoft 365 walks you through SPF during domain setup and lets you enable DKIM from the admin center, but it never publishes a DMARC record for a custom domain. A great many small businesses have run on Microsoft 365 for years with SPF and DKIM in place and no DMARC, which until November 5 cost them nothing. Now their mail to Hotmail bounces, and the error points them at the wrong record.
What Microsoft Has Actually Published
Microsoft's only published authentication requirement for the consumer platform dates from April 2025, when it announced new rules for high-volume senders. The scope was explicit: "For domains sending over 5,000 emails per day, Outlook will soon require compliance with SPF, DKIM, DMARC." The DMARC requirement was "at least p=none and align with either SPF or DKIM." The rejection code for non-compliance was to be 550 5.7.515 Access denied, sending domain does not meet the required authentication level, and the same text still appears on the postmaster policy page and in a dedicated support article today.
That April 2025 post also contains a promise. After describing that non-compliant mail would first go to the Junk folder, it says: "NOTE: that in the future (date to be announced), non-compliant messages will be rejected to further protect users." And under next steps: "We'll provide updates on official rollout schedules, and dates for when rejection actions will begin through a blog post." We checked the Defender for Office 365 blog and the Outlook blog through November 8. That blog post was never published. The last edit to the April post is dated April 30, 2025.
A Microsoft employee answering questions under that post in April 2025 also wrote: "We don't plan to expand this to Enterprise yet. Enterprise environments have complex mail flows that can break DMARC." Nothing was said about expanding it below the 5,000-a-day threshold either.
So the published rule is 5,000 messages a day, 5.7.515, and a Junk-folder first step. What operators are seeing is a different code, different text, no Junk-folder step, and a domain sending twenty messages a week getting the same treatment as a bulk sender. Either Microsoft's enforcement has silently moved well beyond its documentation, or a filter is misbehaving. Microsoft is the only party who can say which, and it has not.
What to Do Now
Check whether you actually have a DMARC record. Do not trust a header. Query DNS directly:
nslookup -type=TXT _dmarc.yourdomain.com
If the answer is a TXT record starting with v=DMARC1, you have one. If the answer is "Non-existent domain" (NXDOMAIN) or an empty response, you do not. Do this for every domain you send from, including subdomains used in the From address and domains you had forgotten were still sending transactional mail.
Publish a minimal record if you have none. A TXT record at _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com is enough to clear this rejection in every confirmed case. Publish exactly one, because two DMARC records at the same name is itself an error that makes DMARC evaluation fail. The rua address is optional for clearing the bounce but worth adding, because the aggregate reports it attracts will show you every source sending as your domain, which you will want before you tighten the policy later.
Do not weaken an existing policy. If you already have p=quarantine or p=reject and you are still seeing this bounce, the record is not your problem. Changing it to p=none will not help and will remove protection you already have. Look instead at whether the specific From domain or subdomain on the rejected message has its own record, and whether your DNS returns NXDOMAIN for it.
Resend what bounced. This is a 550. Nothing that was rejected is sitting in a queue waiting to go out. Once your record resolves, identify the messages that bounced with this text since November 5 and send them again.
Microsoft 365 administrators, check your custom domains today. If your tenant has SPF and DKIM but you never added a DMARC record yourself, you do not have one. Microsoft 365 does not create it for you. Your users are very likely bouncing to Hotmail and Outlook.com right now, and the NDR they are seeing blames SPF.
Alert on the string, not just the code. 550 5.7.1 is one of the most generic codes Microsoft emits. If your bounce processing groups by status code alone, this rejection is being counted alongside dozens of unrelated ones. Match on "lacks SPF/DKIM/DMARC Auth Records" or on "AS9031519", broken down per sending domain, and you will see exactly which domains need a record and when the problem started.
Check your DNS provider's negative answers. If you can, query _dmarc for one of your DMARC-less domains against its authoritative nameserver and note whether you get NXDOMAIN or an empty NOERROR. It costs nothing, and if Dan Malm's observation holds, it tells you which of your domains are exposed.
What We Do Not Know
We do not know whether this is policy or a mistake. The operators who have been watching Microsoft longest are split, and Al Iverson's "time will tell" is the honest position. We do not know whether the 5,000-a-day threshold has been abandoned or whether it was never what the enforcement actually keyed on. We do not know what AS9031519 stands for. We do not know whether Microsoft will roll this back, document it, or leave it exactly as it is, which is what happened with S3150 and S775.
What we do know is that the fix is a single DNS record that senders should have had anyway, and that a change affecting the delivery of ordinary mail from a very large number of small domains to one of the largest consumer mailbox providers in the world happened without a sentence of notice. The operator community diagnosed it, tested it, and published the remediation within 48 hours. Microsoft has yet to acknowledge it exists.
We will update this post when that changes.
Are your domains bouncing at Outlook.com right now? Engagor ingests the raw SMTP responses from your ESPs and MTAs and flags a new rejection string like AS9031519 the moment it appears, per sending domain, with the DNS context to tell you which record is missing before your customers do.
Frequently Asked Questions
What does "550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)" mean?
It is a permanent rejection from Microsoft's consumer mail platform (outlook.com, hotmail.com, live.com, msn.com and national variants such as outlook.be). Since November 5, 2026, operators have seen it on mail from domains that have no DMARC record in DNS, even when SPF and DKIM pass. Microsoft has not documented the message or the AS9031519 code anywhere. In every confirmed case, publishing a DMARC record stopped the rejections.
I have SPF and DKIM. Why is Outlook rejecting my email?
Because, as far as anyone can tell from the reports, Microsoft's consumer platform now also expects a DMARC record to exist for the From domain. SPF and DKIM authenticate the message; DMARC is a separate TXT record at _dmarc.yourdomain.com that tells receivers what to do when they fail. Microsoft 365 does not create this record for custom domains, so many tenants with otherwise complete authentication have never had one.
Is a p=none DMARC record enough to stop the bounces?
In every case confirmed so far, yes. A record of v=DMARC1; p=none; at _dmarc.yourdomain.com was sufficient for Mythic Beasts' customers and for several Microsoft 365 administrators on Microsoft's Q&A forum. The rejections stop once the record is resolvable, which took between a few minutes and about 90 minutes in the reported cases, depending on DNS caching. Messages already rejected have to be sent again.
Why does my Microsoft 365 NDR say "550 5.7.23 SPF violation" when my SPF is correct?
Because Exchange Online wraps the consumer platform's rejection in its own generic NDR, and the 5.7.23 headline refers to the outer wrapper rather than the actual reason. The real reason is in the detail line that follows the arrow: "Message lacks SPF/DKIM/DMARC Auth Records". If your SPF checks out, look for a missing DMARC record instead.
Is this the same as Microsoft's 550 5.7.515 high-volume sender rule?
No, it is a different rule. The 5.7.515 requirement, announced in April 2025, applies to domains sending more than 5,000 messages a day to Microsoft consumer addresses, and its bounce text lists the SPF, DKIM and DMARC results. The AS9031519 rejection uses a different code (5.7.1), different text, and hits low-volume domains that are nowhere near the threshold. Microsoft has not published anything linking the two.
Did Microsoft announce this change?
No, it did not. As of November 8, 2026 there is no Tech Community post, postmaster notice, known-issues entry or Service Health incident, and no Microsoft employee has responded in the mailop thread, on Hacker News, on Mastodon or in Microsoft's Q&A forum. The only Microsoft document on consumer authentication requirements still describes the 5,000-a-day rule and promises a future blog post announcing when rejections would begin. That post was never published.
This post is based on the public mailop thread "Microsoft requiring DMARC now or just us?" (November 6-8, 2026), Mythic Beasts' public Mastodon thread, the Hacker News discussion, public Microsoft Q&A threads, Microsoft's Tech Community, postmaster and Learn documentation as read on November 8, 2026, Al Iverson's reporting on Spam Resource, and SMTP bounce telemetry monitored by Engagor. The sending domain in our example is withheld. Quotes are reproduced from public archives; no private communications were used.
