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

That single line is the whole story, and it is now landing in the logs of small businesses that have never touched a bulk-mail rule in their lives. Since November 5, 2026, Microsoft's consumer mail service — outlook.com, hotmail.com, live.com and msn.com — has been bouncing some messages from any sending domain that does not publish a DMARC record. Not just bulk senders. Not just marketers. A one-line reply from a two-person office can bounce, while the next message from the same mailbox sails through. Nobody at Microsoft announced it, and the fix is one DNS TXT record. This article walks through what is actually known about the change, how it differs from the rules Microsoft did publish, how to check your own domain in under a minute, and how to close the hole without breaking anything else.

The bounce nobody announced

The first public writeup came from MailRoute, an email filtering company, on November 6. Their engineers spotted the rejections in their own outbound logs on November 5 and found other administrators reporting the same behavior that day. On the Hacker News thread that followed, one administrator running a small server at Hetzner reported seeing the same rejection as early as November 1, and a sender at Intercom confirmed the bounces were visible across their traffic too. The bracketed code at the end of the bounce varies per message — AS9031519 in MailRoute's logs, AS9712514 and other values in reports from other administrators — which is consistent with a check running across many different inbound filters rather than one documented rule.

Three properties make this rejection different from a normal spam block. It is partial: one message to a Hotmail address goes through, the next bounces, and a resend may succeed. It is silent on the receiving side: the customer at the outlook.com address never knows a message was sent. And the wording is alarming without being informative — "lacks SPF/DKIM/DMARC Auth Records" sounds like total authentication failure, yet most of the domains being bounced had working SPF and many had DKIM. What they were missing was the DMARC record that ties those mechanisms to the From address.

As of the MailRoute post on November 6, Microsoft had published nothing about the change: no postmaster notice, no blog entry, no service-health message. And there is a second twist. Administrators testing on November 9 and 10 reported the rejections subsiding — one sent a message from a recordless domain to a hotmail.com address and watched it arrive. That pattern suggests a staged rollout being tuned in production, or a rollback in progress. Either way, treating this as a one-off glitch is the wrong read. Treat it as a rehearsal.

The rules Microsoft actually published

Microsoft does have documented sender requirements, and the new bounce matches none of them cleanly. In April 2025, the company announced that domains sending more than 5,000 messages per day to Outlook.com must pass SPF, DKIM and DMARC, with enforcement beginning May 5, 2025. The documented non-delivery reply for that rule is a different code entirely:

550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level

That requirement was explicitly scoped to high-volume senders, and small businesses reasonably assumed it did not apply to them. The November rejections reach senders of any size, and they arrive as a generic 5.7.1 rather than the documented 5.7.515. There is one older documented behavior in the same family: since July 2023, the consumer service has honored a sender's published DMARC policy, rejecting mail that fails validation when the domain publishes p=reject, with NDR code 5.7.509. But that mechanism requires a DMARC record to exist in the first place. The new behavior targets domains with no record at all — the population the published rules never touched.

The industry direction, at least, is no surprise. Google and Yahoo began requiring DMARC for bulk senders in February 2024, and Microsoft's April 2025 post followed the same arc. What is new is the floor dropping out: authentication is shifting from a requirement for heavy senders to a requirement for everyone, and it is happening through enforcement first and documentation later.

DMARC in one record

DMARC — Domain-based Message Authentication, Reporting and Conformance, specified in RFC 7489 — is a single TXT record at a predictable name, _dmarc under your domain. Real records from live lookups on November 10 show the range of what publish looks like:

_dmarc.google.com "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com" _dmarc.microsoft.com "v=DMARC1; p=reject; pct=100; rua=mailto:itex-rua@microsoft.com; ruf=mailto:itex-ruf@microsoft.com; fo=1" _dmarc.soup.place "v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:dmarc_rua@onsecureserver.net;"

The tags are simple. v=DMARC1 declares the version. p= states the policy receivers should apply to mail that fails validation: none (do nothing, just report), quarantine, or reject. sp= does the same for subdomains, pct= limits enforcement to a percentage of traffic, and rua/ruf list addresses for aggregate and forensic reports. The adkim and aspf tags set alignment strictness; both default to relaxed, which is why most records omit them. Microsoft's own record adds fo=1, asking for a failure report when any single mechanism fails rather than only when all do.

The piece most setups get wrong is alignment. DMARC passes only when SPF or DKIM passes for the domain in the visible From header — not just for any domain in the chain. A newsletter provider that sends with its own bounce domain can pass SPF all day and still fail DMARC for your domain, because the authenticated domain does not align with the address your recipients see.

Check your domain in thirty seconds

The check this rejection targets takes one command. From any terminal, replacing the domain with your own:

dig +short TXT _dmarc.example.com nslookup -type=TXT _dmarc.example.com 8.8.8.8

A line starting with v=DMARC1 means you have a record. Empty output or a non-existent domain answer means you do not, and that is the exact population the new rejection targets. Live checks on November 10, 2026 illustrate both outcomes: _dmarc.pigshell.com and _dmarc.foldableflight.com currently return nothing at all, while _dmarc.soup.place returns the quarantine record shown above. Note that even example.com, the IANA documentation domain, publishes a strict record today — v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s — which is a fair measure of how far the baseline has moved.

For a repeatable audit across several domains, a short script beats manual lookups. This one checks for the DMARC record, extracts the policy, and verifies an SPF record exists at the apex:

import dns.resolver def txt_records(name): try: answers = dns.resolver.resolve(name, "TXT") return [b"".join(r.strings).decode() for r in answers] except (dns.resolver.NoAnswer, dns.resolver.NXDOMAIN, dns.resolver.NoNameservers): return [] def audit(domain): dmarc = [t for t in txt_records("_dmarc." + domain) if t.startswith("v=DMARC1")] spf = [t for t in txt_records(domain) if t.startswith("v=spf1")] if not dmarc: print(domain, ": NO DMARC RECORD - exposed to the new rejections") return policy = "none" for tag in dmarc[0].split(";"): tag = tag.strip() if tag.startswith("p="): policy = tag[2:] print(domain, ": DMARC p=" + policy, "| SPF record present:", bool(spf)) for d in ["yourdomain.com", "yourdomain.net"]: audit(d)

The script uses dnspython, installable with pip install dnspython. Run it against every domain your organization sends from, including parked domains that still appear in From headers.

Why "some mail gets through" is the trap

The inconsistency of the new rejection is what makes it expensive. A sender sees a bounce full of acronyms, resends, watches the resend succeed, and concludes it was a transient fault. Meanwhile invoices, appointment confirmations and replies are landing in a void, and the humans at the Microsoft addresses never see any of it. MailRoute's warning is blunt: if your business depends on reaching people at personal addresses — patients, homeowners, applicants, parents, members — the cost of this failure mode is quiet and accumulates without anyone complaining.

The engineering read is that partial enforcement is almost certainly deliberate or at least load-bearing. Rolling a check out across a service the size of Outlook.com without staged sampling would be malpractice, and the varying AS codes plus the November 9 reports of subsiding rejections fit a fleet being tuned. The practical consequence does not change: "my test message arrived" proves nothing about your domain's standing, because arrival and rejection currently coexist for identical configurations.

The fix, staged

The immediate fix is the one DNS record. At your DNS host, create a TXT record named _dmarc with a monitoring-stage value:

Name: _dmarc Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The p=none policy is the safe starting point: it declares that your domain participates in DMARC and asks receivers to send you aggregate reports, but instructs them to take no action on failures. Nothing about how Gmail, Yahoo or anyone else treats your mail changes. The one precondition is alignment — at least one of SPF or DKIM must pass for the domain in your From address, or the record alone will not help. Microsoft's own guidance recommends exactly this staged path: none first, then quarantine, then reject, moving only after the reports show your legitimate sources aligned. Google publishes p=reject today, but that is the end state of the process, not the entry ticket.

Two operational notes. Point rua at a mailbox or report processor you actually read, because the aggregate XML reports are how you discover the third-party services sending as you. And audit your sending vendors: every service that puts your domain in its From header needs its own SPF include or DKIM signing aligned, or it will fail DMARC the day you tighten past none.

What to do this week

The sequence is short. Run the lookup on every domain you own. Where the record is missing, publish v=DMARC1; p=none; rua=... and confirm it resolves from two different resolvers. Where a record already exists, confirm your policy is intentional rather than inherited, and that your largest sending streams pass alignment — the Authentication-Results header on any message you receive tells you which mechanisms passed and under which domain. Then watch the reports for a few weeks before considering quarantine.

The broader lesson is one email administrators have learned repeatedly this decade: the authentication floor rises without announcements, and the cost of being below it is paid in messages nobody knows are missing. A domain with no DMARC record in November 2026 is in the same position as a domain with no SPF record a decade earlier — technically permitted, practically doomed. The record takes ten minutes to publish. The bounce takes longer to notice than most businesses can afford.

Originally published on Dispatch.