Published 8 November 2026 · By Bram Van Daele, Teneo
Since 5 November 2026 Microsoft's consumer mailboxes have started refusing messages from sending domains that publish no DMARC record, also when SPF and DKIM pass. Microsoft has not announced it. We see the refusals on our own relay, and so do operators elsewhere. This is what the bounce means, how it differs from the bulk-sender rule of 2025, and what to publish today.
On Saturday 7 November at 18:00 UTC our relay received this answer from Outlook for a message to an outlook.be address:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
The message was signed with DKIM for the sender's domain, the sending IP was in that domain's SPF record, and both checks passed. The one thing missing was a DMARC record at _dmarc of the domain. A second message from the same domain, two seconds later, got the same answer from another Outlook front end.
The short answer: Outlook.com, Hotmail, Live and MSN addresses now refuse part of the mail from domains that have no DMARC record, whatever the volume, and passing SPF and DKIM does not help. Publishing a record, even one with p=none, is the fix that operators report working.
What changed, exactly?
- The rule of 2025 was about volume. On 2 April 2025 Microsoft announced requirements for domains that send more than 5,000 messages a day to its consumer domains: SPF must pass, DKIM must pass, and DMARC must be published with at least
p=noneand align with SPF or DKIM. Enforcement started on 5 May 2025, first by routing such mail to Junk. Microsoft's support page for the error now describes the refusal with550 5.7.515. - The new refusal ignores volume. The domain in our example sends nowhere near 5,000 messages a day to Microsoft. The reason text and the code differ too:
5.7.1with the identifierAS9031519, not5.7.515. - It is about the record existing. The reports so far describe domains with no DMARC record at all. A domain with
p=nonepasses, which is the policy that changes nothing about delivery elsewhere. - It is consumer mail only, as far as anyone has seen. Microsoft 365 business mailboxes accepted the same mail in the tests reported so far. A company that sends from Microsoft 365 itself is affected when it writes to consumer addresses, and its bounce arrives wrapped in a
5.7.23SPF notice that points the administrator in the wrong direction, as we described on the Engagor blog. - It is partial. Not every message from an affected domain is refused, and some operators report a message going through on a later attempt.
The timeline as reported
Operators began describing the refusals on 5 and 6 November. On Spam Resource, Al Iverson wrote up the reports from the mailop list on Friday night 6 November, US time, and reproduced the refusal himself the next afternoon with a domain that passed SPF and DKIM. In his test a p=none record was enough, and mail to a Microsoft 365 hosted domain was accepted. Our first refusal came on the Saturday evening, European time.
As of 8 November we found no statement from Microsoft about it: no blog post, and no support article for AS9031519. It may be a deliberate step, an early rollout or a mistake that gets rolled back. Nobody outside Microsoft knows yet.
Why a refused message matters more than a junked one
A 5.7.1 answer is permanent. The sending server does not retry, the message bounces back to the sender, and the recipient never sees it. Junk placement at least leaves the message in the mailbox. Because only part of the mail is refused, a sender can miss it for days. The open rates do not move much, and the bounces look like any other bounce unless someone reads the reason.
It also catches a kind of sender the 2025 rule did not: the school that mails parents from its own domain, the accountant who sends invoices through an application, the small web shop. These are domains with SPF and DKIM in place, set up years ago by someone who did the right thing at the time, and never given a DMARC record because nothing asked for one.
The subdomain question
DMARC has a rule that many checkers get wrong. RFC 7489, section 6.6.3, says that when a subdomain such as hr.mail.example.com has no record of its own, the receiver looks up the record of the organizational domain, example.com, and applies its sp= policy, or p= when there is no sp=. So a subdomain is covered by its parent.
We have not seen whether Microsoft's new check follows that rule. The refusals reported so far concern domains without a record anywhere in the tree. If you send from a subdomain and want to be sure, a record on the subdomain itself costs nothing.
What you can actually do
Check every domain you send from, today. Look up the TXT record at _dmarc. followed by the domain, for each domain that appears in a From address: the main domain, the newsletter domain, the invoicing domain of the old application nobody touches.
Publish at least p=none where nothing exists. A record such as v=DMARC1; p=none; rua=mailto:dmarc@example.com asks receivers to change nothing about delivery and to send you aggregate reports. It is enough for what operators see today.
Read the reports before you tighten. The rua reports show which servers send mail in your name. Once every legitimate source passes SPF or DKIM in alignment, move to quarantine and then reject. Microsoft's 2025 rule already asks for alignment from bulk senders, and so do Gmail and Yahoo since 2024.
Make sure DKIM signs with your own domain. DMARC passes when SPF or DKIM aligns with the From domain. A relay or ESP that signs with its own domain gives you a DKIM pass that does not count for DMARC.
Search your bounces for the reason text. Look for Message lacks SPF/DKIM/DMARC Auth Records and AS9031519 in your logs or your provider's delivery log. Each one is a message that did not arrive and will not arrive by itself.
Keep the full bounce. If refusals continue after a record is published, Outlook's sender support asks for the complete answer, with the front-end name and timestamp in brackets.
The bigger picture
The large mailbox providers have been moving in one direction since Gmail and Yahoo set their sender requirements for 2024: authentication first, with a record that names the domain owner. Microsoft wrote the same requirement for bulk senders in 2025. What it now seems to do is apply the most basic part of it, a DMARC record that exists, to everyone. That is a small technical step with a large audience, because the domains it hits are the ones whose owners do not follow deliverability news.
We think it is a reasonable rule enforced in an unreasonable way. A DMARC record has been good practice for a decade, and p=none takes one line of DNS. Refusing mail without a word of notice, with a reason text that names three mechanisms when only one is missing, leaves the people who are hit to find out from their bounces. At Teneo we check SPF, DKIM and DMARC of every sending domain every hour in the console, and on 8 November we wrote to every customer to point them to the DMARC column there. The operator community, as usual, had the explanation days before the vendor.
Frequently asked questions
What does "550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records" mean?
It is a permanent refusal from Microsoft's consumer mail service (Outlook.com, Hotmail, Live, MSN). Since 5 November 2026 operators see it for mail from domains that publish no DMARC record, even when SPF and DKIM pass. The message is not retried and does not reach the recipient.
Is a DMARC record with p=none enough?
In the tests operators have reported so far, yes. A p=none record stops this refusal and changes nothing about how other providers treat your mail. Use the reports it brings in to move to a stricter policy later.
Does this affect Microsoft 365 business mailboxes?
Not in the tests reported so far. The refusals concern Microsoft's consumer domains. Business mailboxes hosted on Microsoft 365 accepted the same mail.
Is this the same as the 550 5.7.515 bulk-sender rule?
No. The 5.7.515 refusal belongs to the requirements Microsoft set in 2025 for domains sending more than 5,000 messages a day. The new refusal carries 5.7.1 and AS9031519 and hits domains of any size.
My subdomain has no DMARC record, but the main domain does. Am I covered?
Under RFC 7489 the main domain's record covers the subdomain, with its sp= policy. We have not seen how Microsoft's new check treats this case, so a record on the subdomain itself is the safe choice.
Sources: Microsoft Defender for Office 365 blog, "Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders", 2 April 2025, updated 29 April 2025; Microsoft support, "Fix NDR error 550 5.7.515 in Outlook.com"; RFC 7489, section 6.6.3; Spam Resource, "Microsoft newly rejecting mail lacking DMARC?", November 2026, and the public mailop list archive it summarises, cited as community reports; Teneo's own relay logs of 7 November 2026, with no customer named. Covers events up to 8 November 2026. No private communications were used.