What changed at Outlook.com on November 5?
On Thursday, November 5, 2026, Microsoft's consumer mail service began rejecting some messages. The affected addresses end in outlook.com, hotmail.com, live.com or msn.com. Country versions such as hotmail.co.uk appear in the same reports.
The trigger is a missing DMARC record: senders with working SPF and DKIM but no DMARC saw mail turned away. The bounce reads: “550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)”.
MailRoute, an email security company, says it first saw the bounces in its own outbound logs on November 5. Dutch support firm db8 and DMARC vendor DmarcDkim.com published similar accounts on November 7. Administrators reported the same error on Microsoft's Q&A forum and on Spiceworks.
The rejection is partial, and a resend sometimes works. MailRoute says one message to a Hotmail address can go through while the next one bounces. That inconsistency makes the problem easy to dismiss as a glitch.
Microsoft has not published an announcement. The firms that documented the bounces checked on November 6 and 7. They found no postmaster notice, no blog post and no service-health entry. Microsoft's public guidance still describes only the 2025 rule for high-volume senders.
That earlier rule had a narrower scope, and small senders were outside its threshold. Since May 2025, Outlook.com has required domains sending 5,000 or more messages a day to pass SPF, DKIM and DMARC. Non-compliant mail is rejected with 550 5.7.515, but the November rejections are not limited to bulk senders.
Outlook.com is Microsoft's consumer service, and it hosts mailboxes at Microsoft-owned domains. The rule applies to anyone who writes to those addresses, whatever the sender's size.
What does the 550 5.7.1 bounce actually mean?
The bounce is a permanent failure, so the sending server does not retry. The message is dropped unless someone resends it after a fix.
DMARC is the record that connects the other two checks to the address a recipient sees. SPF lists the servers allowed to send for a domain, while DKIM attaches a cryptographic signature that receivers can verify.
DMARC passes when SPF or DKIM passes for the domain in the header From address, a requirement called alignment. A domain can have working SPF and DKIM and still fail DMARC if neither matches the From domain.
Two domains matter in a message. The header From address is what the recipient sees, and the envelope sender is the address used in the SMTP conversation. DMARC alignment compares the authenticated domain with the header From domain.
The bounce text is broader than the actual failure. It says the message lacks SPF, DKIM and DMARC records, but SPF was often correct in the documented cases. DKIM was sometimes present too, and the missing piece was the DMARC record.
A second error can appear first. Spiceworks user spiceuser-edd90 reported a 550 5.7.23 SPF validation error for a domain with a valid SPF record. Message trace showed the real rejection, the 5.7.1 DMARC message.
The rejection happens before delivery, so a whitelist will not recover the message. A responder on Microsoft Q&A put it plainly: “there's probably nothing you can change in your Hotmail/Outlook settings to fix this”.
The distinction matters for diagnosis, because senders who see the 5.7.23 code may edit SPF records that already work. The 5.7.1 message points to the missing DMARC record instead.
Who is affected by the Outlook.com DMARC rejections?
The practical answer is anyone who emails customers, clients or applicants at a Microsoft consumer address. That includes small offices that send only a handful of messages a day.
The messages most likely to matter are ordinary business mail. Invoices, quotes, appointment confirmations, order updates and replies to contact forms all fit the pattern. So do job applications and messages from schools, clinics, landlords and membership groups.
The cost is quiet. The sender gets a bounce full of acronyms, and the recipient never learns that a message was sent. From the customer's side, the business appears to have ignored them.
Microsoft 365 customers are exposed through a gap in setup. Connecting a custom domain adds the MX and SPF records the service needs, but it does not add a DMARC record.
Microsoft's documentation says “there are no admin portals or PowerShell cmdlets in Microsoft 365” for managing DMARC records on custom domains. The record has to be created at the registrar or DNS host.
DKIM adds another trap. Until DKIM is enabled for the custom domain, Microsoft 365 signs mail with an onmicrosoft.com domain. That signature does not align with the customer's From domain. DMARC then depends on SPF alone, and forwarded mail can fail.
Administrators carry the support burden. One Hacker News commenter described mitigating the problem for hundreds of customers over a weekend. Another said they had a valid DMARC record set to quarantine when the rejections began.
A small business may rely on a host or contractor and may not know who controls its DNS records. Finding the right person can take longer than adding the record.
Scope is the reassuring detail. The reports concern Microsoft's consumer mailboxes, and business mailboxes on a customer's own domain have not been reported as affected.
How do you check whether your domain has a DMARC record?
Start with the domain in the From address of the mail that bounced. If the organisation sends from several domains, check each one. The record lives at a DNS name called _dmarc followed by the domain.
From a terminal, run: dig +short TXT _dmarc.yourdomain.com; on Windows, use nslookup -type=TXT _dmarc.yourdomain.com instead. A result beginning with v=DMARC1 means a record exists, and an empty result means it does not.
Web tools do the same lookup without a terminal. MXToolbox has a DMARC checker, while Internet.nl runs a broader test of SPF, DKIM and DMARC with Dutch government support.
Check for duplicates while you are there. Two DMARC records on one domain cancel each other out, because receivers ignore both. Do not add a second record alongside an existing one.
A record alone is not proof that mail will pass. DMARC needs SPF or DKIM to align with the From domain. A valid record will still fail if neither aligns.
Do the check from outside the network. Split-horizon DNS can show a record internally that the public internet cannot see, so use a public resolver such as 1.1.1.1. That gives the view external receivers see.
The lookup is harmless and takes seconds, and it does not send mail or change anything. A domain owner can share the result with a provider when asking for the record to be added.
- •Run dig +short TXT _dmarc.yourdomain.com and look for a line starting v=DMARC1.
- •Confirm there is only one DMARC record for the domain.
- •Verify that SPF or DKIM passes for the domain in the From address, not a third-party domain.
- •Repeat the check for every domain the organisation uses to send mail.
How do you fix “Message lacks SPF/DKIM/DMARC Auth Records”?
The documented fix is a single TXT record at the _dmarc name. A minimal record is v=DMARC1; p=none, and adding rua=mailto:address provides aggregate reports about which servers send the domain's mail.
p=none is a monitoring policy that tells receivers to take no action when DMARC fails. It does not change how Gmail, Yahoo or other providers treat the mail. For Outlook.com, the reported rejections stop once the record exists and SPF or DKIM aligns.
Create the record at the DNS host, not inside Microsoft 365. If DNS is hosted by Microsoft, the record goes under the domain's DNS settings in the admin center. Otherwise it goes wherever the zone is managed, such as Cloudflare, GoDaddy or a web host.
Then make DMARC pass. For Microsoft 365, enable DKIM for the custom domain in the Defender portal and publish the selector1 and selector2 CNAME records. For newsletters, CRMs and help desks, confirm those services sign with the organisation's domain or are covered by SPF.
After the DNS change propagates, resend the bounced message. A 550 is not retried automatically, so the original message will not arrive on its own.
Expect propagation to take minutes, not seconds, because some DNS hosts cache negative answers for longer. A test message is a faster check than waiting on a dashboard.
A test message to a personal Outlook.com address is the clearest confirmation. Keep the bounce text if it fails. It contains the server name and timestamp that support staff will ask for.
If bounces continue with a valid record and aligned SPF or DKIM, the usual next step is escalation. DmarcDkim.com recommends sending the full bounce text to Microsoft through its sender support form. A few administrators have reported that pattern.
- •Publish one TXT record: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
- •Remove any duplicate DMARC record.
- •Enable DKIM for the custom domain in Microsoft 365 and publish the selector CNAMEs.
- •Check every third-party sender for alignment with the From domain.
- •Resend the message after the record resolves.
What is confirmed, and what is still unclear?
Several things are well supported. Bounces began on November 5, and low-volume senders are affected. The error code and text are consistent across logs, forums and vendor write-ups. Adding a DMARC record has restored delivery in multiple reported cases.
The partial rejection is also consistent. MailRoute, db8 and Microsoft Q&A users describe the same pattern: some messages delivered, some rejected, and resends that sometimes succeed.
A controlled test adds evidence. DmarcDkim.com reported on November 7 that a researcher removed DMARC records from several low-volume domains and sent test mail. Outlook.com rejected it with the 5.7.1 error, while a company domain on Microsoft 365 accepted the same message.
The server names support the split. Rejections came from hosts under olc.protection.outlook.com, which handle consumer mail, while the Microsoft 365 domain used mail.protection.outlook.com. That matches the reports that business mailboxes are outside the change.
What is not confirmed is intent. Microsoft has not said whether this is a planned rollout, a filter that fires too broadly or a temporary fault. The AS9031519 code does not appear in Microsoft's documentation, and no official figure exists for affected domains or messages.
The evidence also has limits. MailRoute and DmarcDkim.com sell email security and DMARC tools, and db8 supports website and email setups. Their logs agree with independent administrator reports, but none of them speaks for Microsoft.
Some cases do not fit the simple explanation. A Hacker News commenter said they had a valid DMARC record set to quarantine when the problem appeared. DmarcDkim.com notes that a few administrators report the error from domains that do publish DMARC.
Treat vendor data with care but do not dismiss it. MailRoute's claim rests on its own outbound logs, while the Microsoft Q&A reports are independent of any vendor. They show the same bounce text and the same fix.
No one has published a count of affected domains. The evidence is a set of logs and forum threads, not a census, which is normal for an unannounced change. It still limits how precisely the impact can be described.
That does not invalidate the pattern, but it does mean a missing record is the first thing to check. It is not the only possible cause.
What should senders watch next?
The first thing to watch is Microsoft's own channels. A postmaster notice would settle whether the change is deliberate and how far it reaches. So would a Defender blog post or a service-health entry.
The second is scope. If enforcement extends to business mailboxes or to more consumer domains, the number of affected organisations will grow. If it stays on consumer addresses, the impact will fall mostly on businesses that write to customers at personal addresses.
The third is the bounce itself, because documented error codes and clearer text would help senders diagnose the failure. The current message names three protocols when one record is usually missing.
The wider trend is not in doubt. Gmail required bulk senders to authenticate from February 2024, and Microsoft followed in May 2025. Each time, the threshold started with large senders and later became the baseline.
That progression has a cost. A small organisation now needs to understand DNS records, DKIM selectors and alignment to send a reply. The burden falls hardest on senders with no IT department.
It also concentrates power. A handful of mailbox providers decide which mail reaches their users. They can change the rules between one message and the next.
Finn Brunton's history of spam traces how filters and authentication became the boundary between wanted and unwanted mail. The book is a useful reminder that deliverability is a policy choice, not a property of the network.
Senders who use a marketing platform or website builder should ask the provider a direct question. Does mail sent on our behalf carry our domain in the From address and a DKIM signature for it? The answer determines whether a DMARC record will be enough.
For now, the advice is narrow and practical. Check the From domain, publish one DMARC record, confirm that SPF or DKIM aligns, and resend the message. Then keep watching for the notice that has not yet arrived.