550 5.7.1 Message rejected: Message lacks SPF\/DKIM\/DMARC Auth Records (AS9031519)<\/strong><\/mark><\/code><\/pre>\n\n\n\nThere was no announcement, no blog post and no postmaster notice. And the rule it appears to enforce goes well beyond anything Microsoft has published. This is not about bulk senders anymore. A five-person accounting firm emailing a client at hotmail.com can get this bounce today.<\/p>\n\n\n\n
We confirmed it ourselves. Here is what we know, what Microsoft has and hasn’t said, how it compares to what Google and Yahoo did in 2024, and what you should actually do about it.<\/p>\n\n\n\n
What we’re seeing<\/strong><\/h2>\n\n\n\nThe first reports surfaced on the mailop list on November 6. Mailbox hosts and email service operators described a Microsoft rejection none of them had seen before, hitting customer domains with valid SPF and DKIM but no DMARC record. Within a day, others confirmed the same pattern across their own customers.<\/p>\n\n\n\nDate (2026)<\/strong><\/td>What happened<\/strong><\/td><\/tr>Nov 8<\/td> EasyDMARC reproduces the rejection with a domain that has aligned SPF and DKIM but no DMARC<\/td><\/tr> Nov 7<\/td> Tech press and Microsoft’s own Q&A forum fill up with reports; Microsoft stays silent<\/td><\/tr> Nov 6<\/td> The bounce gains the (AS9031519) suffix; mailop thread starts; ESPs and hosts begin advising customers to add DMARC<\/td><\/tr> Nov 5<\/td> First rejections appear, without the AS9031519 suffix<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nOur own test<\/strong><\/h3>\n\n\n\nWe didn’t want to report on hearsay, so we tested it. We sent from a domain hosted on Zoho Mail with SPF passing and aligned, DKIM passing and aligned, and no DMARC record. The message to a live.com address bounced:<\/p>\n\n\n\n
Reporting-MTA: dns; mx.zohomail.com\nStatus: 550\nAction: failed\nDiagnostic-Code: 5.7.1 Message rejected: Message lacks SPF\/DKIM\/DMARC Auth Records (AS9031519) [MWH0EPF000C6190.namprd02.prod.outlook.com 2026-11-08T14:01:49.694Z 08DF3AF9DED5A42C]\nRemote-MTA: dns; live-com.olc.protection.outlook.com<\/strong><\/mark><\/code><\/pre>\n\n\n\n![\"\"](\"https:\/\/easydmarc.com\/blog\/wp-content\/uploads\/2026\/11\/Screenshot-2026-11-08-at-6.15.02-PM-1024x564.png\")
<\/figure>\n\n\n\nNote the Remote-MTA. The olc in live-com.olc.protection.outlook.com stands for Outlook Consumer. That’s the infrastructure behind the free mailboxes.<\/p>\n\n\n\n
Who is affected<\/strong><\/h3>\n\n\n\n\n- Recipients:<\/strong> Microsoft’s consumer mailboxes only, meaning outlook.com, hotmail.com, live.com, msn.com and their country variants. Microsoft 365 business tenants with custom domains don’t appear to be affected as recipients.<\/li>\n\n\n\n
- Senders:<\/strong> any domain without a DMARC record, regardless of volume. That includes Microsoft 365 customers who never published DMARC, since Microsoft 365 doesn’t create one for you.<\/li>\n\n\n\n
- Pattern:<\/strong> it’s intermittent. Some messages from the same domain get through, others bounce. If your test message landed, that doesn’t mean you’re fine.<\/li>\n<\/ul>\n\n\n\n
There is also a smaller set of reports from senders who say their SPF, DKIM and DMARC are all in place and they still get rejected, sometimes paired with 550 5.7.23<\/strong> <\/mark>(SPF violation). Those may be misconfigurations, or a second issue on Microsoft’s side. We’d treat them separately until there’s more data.<\/p>\n\n\n\nIs this official?<\/strong><\/h2>\n\n\n\nNo. As of November 8, 2026, Microsoft has published nothing about it. We checked the Microsoft Defender for Office 365 blog, the Outlook.com sender support pages and the Outlook.com known-issues list. Nothing.<\/p>\n\n\n\n
The discussion so far lives in community forums and operator mailing lists, and none of it comes from Microsoft. Nobody at Microsoft has confirmed this rejection as a known incident or as a new rule.<\/p>\n\n\n\n
So there are three possible readings:<\/p>\n\n\n\n
\n- A deliberate, unannounced policy change.<\/strong> Microsoft decided every domain sending to consumer mailboxes needs DMARC, and is rolling it out gradually.<\/li>\n\n\n\n
- A staged rollout of something announced later.<\/strong> Microsoft has done quiet enforcement before and documented it afterwards.<\/li>\n\n\n\n
- A filtering bug or misfire (Highly Unlikely).<\/strong> This would fit the intermittent pattern and the reports from fully authenticated senders.<\/li>\n<\/ol>\n\n\n\n
Our read: the behavior is too consistent to be random. Domains without DMARC get hit, adding even p=none <\/mark>fixes it, and the bounce text names the missing records. That looks like a rule. Whether Microsoft keeps it, softens it or formalizes it is still open. Plan as if it stays.<\/p>\n\n\n\nWe’ll update this post if Microsoft says anything.<\/p>\n\n\n\n
What Microsoft did publish, and how this is different<\/strong><\/h2>\n\n\n\nMicrosoft does have written sender requirements. In April 2025 it announced new requirements for high-volume senders to Outlook.com, Hotmail and Live. Domains sending over 5,000 messages a day had to pass SPF and DKIM and publish DMARC at p=none<\/mark> <\/strong>or stronger, aligned with SPF or DKIM. The original plan was to route non-compliant mail to Junk first. A later update changed that to outright rejection, and enforcement started May 5, 2025 with 550 5.7.515 Access denied.<\/strong><\/mark><\/p>\n\n\n\nThe new rejection breaks from that in five ways:<\/p>\n\n\n\n<\/td> May 2025 bulk sender rule<\/strong><\/td>November 2026 rejection<\/strong><\/td><\/tr>Announced<\/td> Yes, Microsoft blog<\/td> No<\/td><\/tr> Who it applies to<\/td> Domains sending 5,000+ messages\/day<\/td> Any domain without DMARC, any volume<\/td><\/tr> Bounce code<\/td> 550 5.7.515 Access denied<\/td> 550 5.7.1 Message lacks SPF\/DKIM\/DMARC Auth Records (AS9031519)<\/td><\/tr> What the bounce tells you<\/td> SPF, DKIM and DMARC results<\/td> Only that records are missing<\/td><\/tr> Consistency<\/td> Deterministic<\/td> Intermittent<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThe volume threshold is the big one. For 18 months, small senders assumed Microsoft’s DMARC requirement didn’t apply to them. That assumption just stopped being safe.<\/p>\n\n\n\n
Microsoft just went further than Yahoogle<\/strong><\/h2>\n\n\n\nWhen Google and Yahoo announced their sender requirements in October 2023, the industry had about four months to prepare. Enforcement started in February 2024 and ramped up gradually, first with temporary errors, then with rejections for a share of non-compliant traffic. Everyone knew the rules and the thresholds.<\/p>\n\n\n\n
Those rules split senders into two tiers. Every sender needed SPF or DKIM. Only bulk senders, 5,000+ messages a day, needed DMARC. A small business with SPF and DKIM and no DMARC was compliant with Gmail and Yahoo then, and still is today.<\/p>\n\n\n\n
Microsoft has now quietly erased that line for its consumer mailboxes.<\/p>\n\n\n\n<\/td> Google and Yahoo (Feb 2024)<\/strong><\/td>Microsoft Outlook.com (May 2025)<\/strong><\/td>Microsoft Outlook.com (Nov 2026, observed)<\/strong><\/td><\/tr>Announced in advance<\/td> Yes, ~4 months<\/td> Yes, ~1 month<\/td> No<\/td><\/tr> Senders below 5,000\/day<\/td> SPF or DKIM<\/td> Not covered<\/td> DMARC record required<\/td><\/tr> Senders above 5,000\/day<\/td> SPF, DKIM, DMARC p=none+, alignment<\/td> SPF, DKIM, DMARC p=none+, alignment<\/td> Same, plus the new rejection<\/td><\/tr> Other bulk requirements<\/td> One-click unsubscribe, spam rate under 0.3%, PTR, TLS<\/td> Recommended hygiene, not mandated<\/td> No change known<\/td><\/tr> Rollout<\/td> Gradual, temp errors first<\/td> Rejection from day one<\/td> Intermittent rejection, no warning<\/td><\/tr> Bounce clarity<\/td> Specific codes with links to guidelines<\/td> 5.7.515 lists auth results<\/td> 5.7.1<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThe irony is hard to miss. Yahoogle was the loud one, and Microsoft was seen as the laggard that followed a year later. Now Microsoft is the first of the big three to effectively require DMARC from every sender, regardless of volume, and it did it without saying a word.<\/p>\n\n\n\n
p=none fixes the bounce. It doesn’t fix the problem.<\/strong><\/h2>\n\n\n\nESPs, CRMs and hosting providers are already flooded with tickets on this. The standard advice going out is the same everywhere: publish v=DMARC1; p=none<\/mark> <\/strong>and you’re done. Technically, that works. Senders who added the record report that delivery resumes once it’s live.<\/p>\n\n\n\nBut look at what that record actually does. It tells receivers your domain uses DMARC, then tells them to take no action when a message fails. With no rua<\/strong> <\/mark>tag, nobody receives any reports. You’ve satisfied Microsoft’s check and learned nothing about your own mail.<\/p>\n\n\n\nOne operator on mailop raised a fair question. If Microsoft already sees valid, aligned SPF and DKIM, why demand a published policy that says “do nothing”? Our answer: a DMARC record is a statement of intent. It tells receivers that someone owns this domain’s authentication and is paying attention. A bare p=none<\/mark> <\/strong>with no reporting is the empty version of that statement.<\/p>\n\n\n\nHere’s what a rushed p=none<\/strong><\/mark> leaves on the table:<\/p>\n\n\n\n\n- No visibility.<\/strong> Without aggregate reports you don’t know which services send as your domain, which ones fail alignment, or who is spoofing you.<\/li>\n\n\n\n
- No protection.<\/strong> p=none<\/strong><\/mark> doesn’t stop anyone from sending phishing as your domain. Only quarantine<\/strong> <\/mark>or reject <\/strong><\/mark>does.<\/li>\n\n\n\n
- No path forward.<\/strong> Microsoft’s bar today is a record. Gmail and Yahoo’s bar for bulk senders is alignment. The direction of travel for every mailbox provider is enforcement. A domain parked at p=none forever will hit the next wall too.<\/li>\n\n\n\n
- Hidden failures.<\/strong> Many domains that “have SPF and DKIM” are signing with the provider’s domain, not their own. Microsoft 365, for example, signs with your onmicrosoft.com<\/strong><\/mark> domain until you enable DKIM for your custom domain. That passes DKIM but doesn’t align, so it doesn’t count for DMARC.<\/li>\n<\/ul>\n\n\n\n
What to do now<\/strong><\/h2>\n\n\n\nIf you’re bouncing right now<\/strong>, the fix is a DMARC record. Here’s how to set it up with EasyDMARC so it does more than stop the bounce:<\/p>\n\n\n\n\n- Sign up for EasyDMARC and add your domain.<\/strong><\/li>\n\n\n\n
- Publish a DMARC record at p=none<\/mark>.<\/strong> This is the step that stops the Outlook.com rejections, as soon as the record is live in DNS.<\/li>\n\n\n\n
- Use your EasyDMARC reporting address in the rua<\/mark> tag.<\/strong> Every account gets its own unique address in the form [your-id]@rua.easydmarc.com<\/strong><\/mark> (or .us, depending on your account’s region). Copy the exact address from your dashboard. Your record will look like this:<\/li>\n<\/ol>\n\n\n\n
_dmarc.yourdomain.com TXT \"v=DMARC1; p=none; rua=mailto:[your-id]@rua.easydmarc.com\"<\/strong><\/mark>\n<\/code><\/pre>\n\n\n\n 4. Resend anything that bounced.<\/strong> A 5xx is permanent, so Outlook.com won’t retry it.<\/p>\n\n\n\n 5. Investigate your reports.<\/strong> Give it two to eight weeks, depending on the complexity of your email ecosystem. EasyDMARC shows every service sending as your domain and which ones fail SPF or DKIM alignment.<\/p>\n\n\n\n 6. Fix what the reports surface.<\/strong> The usual suspects:<\/p>\n\n\n\n