Since November 5, mail sent to outlook.com, hotmail.com, live.com and msn.com has been bouncing with a rejection most senders have never seen: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519). The trigger, according to two providers that examined their own logs, is one absent DNS record — DMARC. Microsoft has published nothing about it, and the rejection is partial, so the failure stays invisible until a customer asks why an invoice never arrived.
What the bounce says, and what it leaves out
The wording implies total authentication failure. In the mail MailRoute examined, most sending domains had working SPF and many signed with DKIM; what they lacked was the _dmarc TXT record that ties either mechanism to the From address. It also differs from Microsoft’s existing rejection: the May 2025 rule for domains sending over 5,000 messages a day returns 550 5.7.515 Access denied and names the failed checks. This one names none. Al Iverson of SpamResource tested scope on November 7 — mail to outlook.com bounced, the same setup to a Microsoft 365 corporate domain was accepted. The gate is consumer-only so far.
Four days, two explanations that do not fit together
- May 5, 2025 — the high-volume rule takes effect: SPF and DKIM must pass and DMARC must be published and aligned.
- November 5, 2026 — the first 5.7.1 bounces with AS9031519 appear in MailRoute’s logs and on the Mailop list.
- November 6 — MailRoute publishes the missing-DMARC explanation; SpamResource notes mail is rejected even when SPF and DKIM pass.
- November 7 — Iverson reproduces the bounce; Microsoft Q&A fills with senders far below 5,000 a day.
- November 8 — Windows Latest reproduces it and collects reports that domains with valid SPF, DKIM and DMARC bounce too, that a resend sometimes works, and that one recipient lost roughly half their clients’ mail.
- November 9 — still no postmaster notice, blog post or service-health entry.
Two explanations survive. Either Microsoft quietly extended its DMARC requirement to every sender, and one record is the fix. Or a rolling deployment is refusing mail at some servers, and a correctly configured domain can still lose messages while missing DMARC is only the loudest symptom.

We checked 1,000 of the most-reached domains
We queried DNS on November 9 for _dmarc TXT records across the 1,000 highest-ranked domains in Cisco Umbrella’s public top-million list. A naive count says 827 (82.7%) publish no DMARC record, and that number is close to meaningless: most are CDNs, ad exchanges and API endpoints that never send mail. Restricting to the 219 domains that publish an SPF record — an explicit statement that the domain sends mail — leaves 64 without DMARC (29.2%). Restricting to the 155 that publish SPF and a mail exchanger gives the population that matters: 39 (25.2%) have no record, 17 publish p=none, and 99 (63.9%) enforce. One in four of the most-reached mail domains is exposed by its DNS alone.

Japan is where the exposure sits
A second sample drew 200 random domains from the 8,535 .jp entries in the same list. Of the 110 that accept mail, 58 (52.7%) publish no DMARC record — 2.1 times the global rate — 35 publish p=none, and only 17 (15.5%) enforce. That is 84.5% of the sampled Japanese mail domains telling receivers to do nothing when someone forges them. The one-record remedy reaches fewer of them than the advice implies: of the 58 without DMARC, only 11 publish SPF, so 47 need SPF and DKIM work before a record could pass. We measured SPF and DMARC only; DKIM selectors cannot be enumerated, so a few of the 47 may pass on a signature we could not see.
Where the one-record fix stops working
p=none clears today’s gate only when SPF or DKIM already aligns with the From domain. If mail leaves through a relay that keeps its own domain in the From line, or a Microsoft 365 tenant still signing as onmicrosoft.com, the record changes nothing. If the domain never sends mail, p=none buys reports and no protection. It is a floor, not a destination: the version that stops forgery is quarantine, then reject, adopted after reports show clean alignment. This site’s own record, checked today, is v=DMARC1; p=none behind a Hostinger SPF — enough for the new gate, no defence against someone sending as huanghuajian.com.
What to watch
- A Microsoft postmaster or Tech Community notice, and whether the 5,000-per-day page is rewritten.
- Whether corrected domains stop bouncing within 48 hours. If they do not, the cause is deployment, not policy.
- Whether 550 5.7.23 SPF rejections climb in the same window; they already appear in the same threads.
- Whether Japanese registrars and hosts ship DMARC defaults. Hostinger does for this domain; most of the tail does not.
Sources: MailRoute, SpamResource, Windows Latest, Microsoft Tech Community, Cisco Umbrella top-million list. DNS measurements: huanghuajian.com, 2026-11-09.

