Outlook.com Is Bouncing Mail From Domains Without DMARC

Since November 5, 2026, mail to Microsoft's consumer addresses (outlook.com, hotmail.com, live.com, msn.com) has been bouncing for some senders with this error:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

What the reports have in common is a sending domain with no DMARC record. Small senders are getting it too: offices, schools and one-person businesses, not only bulk mailers. Publishing a DMARC record stops the bounce, and the record can be the gentlest one there is.

Who's seeing it

• Recipients: Microsoft's consumer service only. In a controlled test on November 7, deliverability writer Al Iverson deleted the DMARC record from a few of his own low-volume domains. His mail to outlook.com bounced. Mail to a business domain hosted on Microsoft 365 was accepted.
• Senders: any volume. The Microsoft Q&A thread on this error filled up within a day, with posters saying their senders are nowhere near bulk volume.
• Not every message. Reports call the bounces sporadic: one message bounces and the next one gets through. That makes the problem easy to miss and easy to blame on something else.

Didn't Microsoft announce this?

Partly. In April 2025 Microsoft announced requirements for high-volume senders to Outlook.com: domains sending over 5,000 messages a day must pass SPF and DKIM and publish DMARC at "at least p=none", aligned with either SPF or DKIM. Mail that falls short is refused with a different code, 550 5.7.515 (Microsoft's support page for it). The same post asked whether senders under 5,000 a day need to bother. Microsoft's answer: "While enforcement first targets large senders, all senders benefit from these best practices."

So the direction was announced. What changed this month has no notice of its own, as of November 8:

• It reaches low-volume senders, which the 2025 rule did not.
• It carries a different code (5.7.1 plus AS9031519), and none of Microsoft's published pages we found mention that identifier.
• Microsoft hasn't said whether it's a deliberate policy step or an incident. No Microsoft employee has answered in the Q&A thread.

Plan as if it's permanent. Microsoft said in 2025 that this is where all senders were headed. The fix takes five minutes and does nothing to the rest of your mail.

Why this isn't DMARC enforcement

Strictly speaking, DMARC has nothing to say about a domain with no record. The standard says that when no record is found, receivers "MUST NOT apply the DMARC mechanism to the message" (RFC 9989 §4.10.1). What Microsoft is doing is its own local policy: it refuses mail from domains that haven't published a record. Any receiver may set rules like that.

That's also why the gentlest record is enough to stop the bounce. A p=none policy asks receivers for reports and nothing else. The standard says discovered p=none policies "MUST NOT modify existing mail handling processes" (RFC 9989 §5.4). Publishing one changes nothing at Gmail, Yahoo or anywhere else.

The fix

1. Check whether you have a record. From a terminal:

dig +short TXT _dmarc.example.com

Output that starts with "v=DMARC1 means you have one. No output means you don't. Or run your domain through our free check, which also tells you whether your mail would pass.

2. Publish one. Add a TXT record at your DNS host:

The rua tag says where receivers should send aggregate reports. It's optional for stopping this bounce, but without it p=none gives you nothing back. Those reports are how you find out which of your senders fail (RFC 9989 §5.1.5).

Three details catch people:

• Publish it at your main domain. Mail from news.example.com with no record of its own falls back to the record at example.com (RFC 9989 §4.10.1), so one record covers your subdomains.
• Publish exactly one. If a name has two DMARC records, receivers discard both (RFC 9989 §4.10), and you're back to having none. Edit the existing record instead of adding a second one.
• Don't start at p=reject. Your own mail from a service you forgot about would start bouncing everywhere, not just at Microsoft. Start at none, read the reports, then tighten. We wrote up why the jump to reject goes wrong.

Make it pass, not just exist

Reports so far say a record is what stops this bounce. Microsoft's published bar for bulk senders is higher: DMARC has to pass, meaning SPF or DKIM passes for a domain that matches the one in your From address (RFC 9989 §4.4). If the rule keeps tightening, that's the bar it will tighten to. Two common ways it fails:

• SPF passes for someone else's domain. SPF checks the envelope sender, the hidden address bounces go to (RFC 7208 §2.4), not the From line. Many newsletter, CRM and invoicing tools use their own domain there. SPF passes, but for their domain, so it doesn't count toward yours. Set up the DKIM records the tool gives you, so it signs with your domain.
• DKIM was never switched on. Microsoft 365 doesn't DKIM-sign mail from your custom domain until you publish its two CNAME records and enable signing (Microsoft's DKIM guide). Microsoft 365 also has no setting that creates a DMARC record for a custom domain. Microsoft's own docs say to add it at your DNS host. That's why so many Microsoft 365 domains are caught by this bounce.

If you're the one not receiving mail

If you use an Outlook.com or Hotmail address and your contacts' mail bounces, no setting on your side fixes it. The record has to be published in the sender's DNS. Send them this page, or the result of a check on their domain.

What we're watching

We'll update this post if Microsoft says anything about the AS9031519 rejections. Meanwhile, the safe position is the one Microsoft described in 2025: SPF and DKIM passing for your own domain, and a DMARC record aligned with at least one of them. dmarc.quest checks all three for free, and if you point your rua at us, we read the reports and tell you which senders are failing before Microsoft does.