Since November 5, Microsoft's consumer mail servers have been rejecting part of the mail sent from any domain that has no DMARC record. The bounce is a hard 550. It hits outlook.com, hotmail.com, live.com and msn.com recipients. It does not care whether you send five messages a day or five million. And four days in, Microsoft has published nothing about it. No postmaster notice, no blog post, no entry on the Outlook.com known issues page.

The rejection text is this:

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

On the first day the AS9031519 code wasn't there. It showed up on November 6. That code appears in none of Microsoft's documentation, which Microsoft's own AI answer bot on the Q&A forum admitted when people started asking.

Who found it and how

MailRoute, a mail filtering company, saw the bounces in its outbound logs on November 5 and published a writeup the next day. Mythic Beasts, a UK host, said on November 6 that it had seen the message over 500 times the day before. On Microsoft's Q&A forum, one asker reported that about half the clients who emailed them since the previous day had bounced, from a mix of providers. By the weekend more than 70 people had marked that thread as the same question.

Then people tested it on purpose. Al Iverson removed the DMARC records from a handful of personal domains on November 7 and reproduced the rejection. EasyDMARC did the same on November 8 with a Zoho Mail domain where SPF and DKIM both passed and aligned, and only the DMARC record was missing. The test message to a live.com address bounced.

Every domain that got rejected, in every case someone checked, had working SPF, usually had DKIM, and had no TXT record at _dmarc. Publishing one stopped the bounces. Engagor, which collected reports from operators at MXroute, Fastmail, one.com and Zoho, says that held in every confirmed case. Two senders who insisted they had DMARC turned out not to.

The rejections are intermittent. One message from a domain bounces, the next one lands, a resend an hour later goes through. That makes it worse. A domain owner who sends a test and sees it arrive will conclude they're fine. They aren't. And because a 550 is permanent, the sending server won't retry on its own. The mail is gone until a human resends it.

The published rule was for 5,000 messages a day

Microsoft did announce sender requirements once. On April 2, 2025, the Defender for Office 365 team posted that domains sending more than 5,000 messages a day to Outlook.com would need SPF to pass, DKIM to pass, and a DMARC record at p=none or stronger, aligned with one of them. Noncompliant mail would go to Junk starting May 5, 2025. Rejection would come later, with a date "to be announced." The rejection code for that program is 550 5.7.515, a different code with a different message.

That follow-up post never came. Engagor looked for it through November 8 and found nothing.

Google and Yahoo ran the same play in 2024 and ran it properly. They announced on October 3, 2023, enforced starting February 2024, and only required DMARC from senders above 5,000 messages a day. Everyone else needed SPF or DKIM. Four months of notice, a published threshold, and staged enforcement.

What Microsoft shipped on November 5 is a rule with no threshold, no notice and no documentation. Either someone flipped a flag that was meant for the 5,000 a day tier and it applied to everyone, or this is the planned next phase and the announcement got skipped. From outside, those look identical. So does the result for a plumber in Ohio whose quote to a Hotmail customer just bounced with a message about auth records.

One detail suggests the check was written in a hurry. Dan Malm at one.com reported that only domains whose _dmarc lookup returns NXDOMAIN were affected. Domains where the lookup returns NOERROR with no data got through. Nobody has corroborated that yet. If it holds, Microsoft's check treats two states that both mean "no DMARC policy" under RFC 7489 as different things, which is the kind of bug you get when a filter rule is written against raw DNS responses instead of a DMARC library.

Check your domain, then publish one record

This takes under a minute per domain.

dig +short TXT _dmarc.example.com

If the output starts with "v=DMARC1", you have a record and this bounce is not your problem. If you get nothing back, add a TXT record named _dmarc with this value:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The p=none policy tells receivers to take no action on failures. It changes nothing about how Gmail or anyone else treats your mail today. It does satisfy Microsoft's check. The rua address is optional but you want it, because the aggregate reports are the only way to find the forgotten sending service (the CRM, the invoicing tool, the contact form on the website) before you move to p=quarantine or p=reject and it starts bouncing.

Four things trip people up:

  • Alignment. DMARC passes only when SPF or DKIM passes for the same domain that's in the From header. A DKIM signature from your provider's domain counts for nothing here.
  • Microsoft 365 is the biggest source of this. A new tenant signs mail with onmicrosoft.com until you enable DKIM for your own domain in the Defender portal and publish the selector1 and selector2 CNAMEs. Microsoft 365 also never creates a DMARC record for you. So Microsoft's business customers are bouncing off Microsoft's consumer servers over a record Microsoft never told them to add.
  • Two records at _dmarc means zero records. Receivers discard both. Check that you didn't paste one next to an old one.
  • Permanence. Grep your outbound logs for AS9031519 and resend anything that mattered. Nothing will retry those for you.

Some admins with SPF, DKIM and DMARC all correct also reported bounces, some wrapped in a 550 5.7.23 SPF violation from Exchange Online. In the two cases Engagor examined in detail, the domain had no DMARC record after all. I'd treat the rest as unverified until someone posts headers.

Notice is the part Microsoft skipped

I have no argument with the requirement. A DMARC record at p=none costs nothing, takes one DNS entry, and I've been telling people to publish one since the Google and Yahoo change nearly three years ago. Any domain that still lacks one in November 2026 is behind, and the fix is the same fix it was in 2024.

The process is a different matter. Microsoft runs one of the three largest consumer mailbox populations on Earth. It changed an acceptance rule for every sender on the internet, made the change a hard reject instead of a Junk folder, made it intermittent so it's hard to confirm, and told nobody. Operators at five or six hosting and mail companies spent the weekend reverse engineering the rule from bounce strings. A forum moderator under Microsoft contract said contributors "cannot confirm whether these reports have already been escalated." That is the entire official response as of Sunday.

I've run mail for long enough to know what an unexplained bounce does to a support queue. It doesn't matter that the fix is one DNS record. The person getting the bounce doesn't know that, their customer doesn't know that, and the error text points at three different acronyms without saying which one failed.

My prediction: within two weeks, a post appears on the Defender for Office 365 blog describing this as the planned second phase of the 2025 sender requirements, and it will not mention that enforcement began before the post. Until then, if you run DNS or hosting for other people, scan every zone you manage for a missing _dmarc record tonight. Monday morning's tickets are already in flight.