Outlook Rejects Email Without DMARC: Fix It in 5 Minutes

Outlook.com started rejecting email from domains that publish no DMARC record on November 5, 2026 — even when SPF and DKIM both pass. The bounce reads "550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)", and it is permanent: the message is not delivered and is never retried.

The fix is one DNS record. Add a TXT record at _dmarc.yourdomain.com containing v=DMARC1; p=none, and the rejections stop. It takes about five minutes, it costs nothing, and it changes nothing about how other mail providers treat your mail. The rest of this article explains what changed, who is affected, and how to check your own domain before a customer tells you their email bounced.

What Changed on November 5, 2026

Microsoft's consumer mail service — Outlook.com, Hotmail, Live, and MSN — quietly began refusing some mail from domains with no DMARC record. The first reports surfaced in MailRoute's own outbound logs on November 5, and administrators started comparing notes on the mailop operators' mailing list on November 6. Independent researchers reproduced the rejection on November 7 and 8, and every test reached the same conclusion.

What makes this different from every previous Outlook sender rule is the scope. Microsoft's published rule, in force since May 2025, applies to bulk senders: domains sending more than 5,000 messages a day to Outlook.com must pass SPF, DKIM, and DMARC, or get a 550 5.7.515 rejection. The new rejection hits ordinary, low-volume senders too. A one-line reply from a small office can bounce.

As of November 8, Microsoft has published nothing about it — no announcement, no blog post, no postmaster notice, and no entry on any known-issues list. That silence is part of the problem: site owners first learn about it from a bounce message, or from a customer asking why their email never arrived. The change can also be widened, narrowed, or rolled back at any time, since nothing about it is documented.

What the Bounce Actually Says

The full bounce line looks like this:

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

Every part of that line matters. The 550 means permanent failure: a compliant mail server bounces the message back to the sender and does not retry. The 5.7.1 is the enhanced status code for a security or policy rejection. The text is new — it does not match any bounce Microsoft has documented before — and the AS9031519 code is not defined in any Microsoft documentation, which Microsoft's own AI-generated support answer concedes.

Two details in the bounce are easy to misread. First, the wording says "SPF/DKIM/DMARC" as if any of the three might be missing, but the tests show DMARC is the deciding factor: domains with valid, aligned SPF and DKIM still get rejected when they have no DMARC record.

Second, only some messages bounce. Microsoft is refusing part of the mail from affected domains, not all of it, so the problem can look intermittent — one email to an Outlook address goes through, the next one bounces.

Why SPF and DKIM Passing Does Not Save You

SPF and DKIM answer different questions from DMARC, and that is why passing both is not enough. SPF says which servers are allowed to send mail for your domain. DKIM proves the message was not altered in transit. Neither one tells the receiver what to do when a message fails those checks, and neither one ties the result to the domain your recipient actually sees in the From address.

DMARC is the policy layer that sits on top of both. It says: when a message claims to be from this domain, check SPF and DKIM against the From domain, and if neither passes in alignment, apply this policy. The DMARC specification (RFC 7489) defines that alignment rule, and it is the piece Microsoft is now effectively requiring.

Without a DMARC record, there is no policy for the receiver to apply — and Outlook.com has started treating that absence as a reason to refuse the message outright.

The controlled tests make this unambiguous. DMARKOFF sent test mail from subdomains with aligned SPF and DKIM but no DMARC record to 16 Outlook.com and Hotmail seed mailboxes: all 16 refused the message at the SMTP stage. The same message, from the same setup, was accepted by Gmail. And when a DMARC record was added — even at p=none, the weakest policy — the same mailboxes accepted the mail.

Who Is Affected

The rejection comes from Microsoft's consumer mail platform, the servers behind *.olc.protection.outlook.com. That means the recipients are consumer mailboxes: outlook.com, hotmail.com, live.com, msn.com, and their country variants such as outlook.be. The rejecting servers span Europe, Asia-Pacific, and North America, so this is a global change, not a regional rollout.

Microsoft 365 business tenants are not affected as recipients — mail to a business domain hosted on Microsoft 365 was accepted in the tests. But that distinction only helps you if your customers use business mail. If your customers, clients, or applicants use personal Outlook or Hotmail addresses, your mail to them is exposed whenever your sending domain has no DMARC record.

Volume does not protect you either. The May 2025 bulk-sender rule only covered domains sending over 5,000 messages a day. The new rejection applies to any domain without a DMARC record, regardless of volume. Small businesses, freelancers, and transactional mail from a website — order confirmations, password resets, contact-form replies — are all in scope if the sending domain has no DMARC record.

How to Check Whether Your Domain Is Exposed

A DMARC record is a TXT record published at _dmarc under your domain — for example, _dmarc.frostrank.com. If that name returns no TXT record starting with v=DMARC1, your domain is exposed. Checking takes less than a minute, and you do not need access to your mail server to do it.

Use the free DNS Lookup tool and enter your domain. Look at the TXT records in the results: you are looking for a record whose name starts with _dmarc. If it is there and starts with v=DMARC1, you have a DMARC record and this rejection should not hit you. If there is no _dmarc record at all, your domain is exposed and you should add one today.

Check the exact domain in your From address, not just your main domain. If your mail goes out from a subdomain such as mail.yourdomain.com, check _dmarc.mail.yourdomain.com as well. The tests showed that a DMARC record at the parent (organisational) domain is enough to stop the rejection, but checking the subdomain directly removes all doubt — and if you use several subdomains to send mail, each one deserves its own check.

The Fix: Publish a DMARC Record

Add one TXT record at your DNS host — the same place you manage your domain's DNS records:

Name:  _dmarc
Type:  TXT
Value: v=DMARC1; p=none

That is the entire fix. The p=none policy tells receivers to take no action on mail that fails DMARC checks — it only asks them to send you aggregate reports. It changes nothing about how Gmail, Yahoo, or any other receiver treats your mail, and it cannot cause legitimate mail to be rejected. It simply publishes the policy Outlook.com is now looking for.

Three rules apply when you add the record. First, publish exactly one _dmarc record per domain: two DMARC records on the same name make the result undefined, and receivers ignore both.

Second, remember that DMARC only passes when SPF or DKIM passes in alignment with your From domain — a DMARC record alone will not help if neither of those lines up. Third, DNS changes take time to propagate, so allow up to a few hours before re-testing, and longer if your DNS provider sets a long TTL on TXT records.

Best DMARC Checker Tools (Free)

You do not need a paid service to verify a DMARC record. Any tool that shows TXT records for a domain will do the job, because a DMARC record is simply a TXT record at a specific name. The free options below cover every level of need, from a one-off check to ongoing monitoring.

For most small sites, the free check is enough. Publish the record, verify it appears in a TXT lookup, and send a test email to an Outlook.com address. Paid DMARC monitoring only earns its keep when you send enough mail — or from enough services — that you need the aggregate reports to see who is sending as your domain before you tighten the policy.

p=none vs Quarantine vs Reject: Which Policy?

DMARC has three policies, and the right one depends on how confident you are that all your legitimate mail passes. The p=none policy takes no action on failing mail and only requests reports — it is the safe starting point, and it is all Outlook.com needs to stop rejecting your mail. Start here.

Once p=none has been live for a few weeks and the aggregate reports show that all your legitimate mail passes, move to p=quarantine, which sends failing mail to the spam folder. Only move to p=reject — which blocks failing mail outright — when the reports show no legitimate mail failing at all. Moving to reject too early is how real mail gets blocked, so treat each step as a separate decision, not a race.

One warning: do not skip straight to p=reject because it sounds more secure. If any service sends mail as your domain without aligned SPF or DKIM — a contact form, an invoicing tool, a newsletter service — reject will block it. The reports from p=none exist precisely to find those senders first.

What If It Still Bounces After You Add the Record?

If mail still bounces after you publish the record, work through this checklist before assuming the fix failed. First, confirm the record is actually visible: query _dmarc.yourdomain.com with the DNS Lookup tool and confirm the TXT value starts with v=DMARC1. If it is not there, the record was added at the wrong name — the most common mistake is adding it at the bare domain instead of at _dmarc.

Second, check for duplicates. If your DNS host shows two TXT records at _dmarc, delete one: two records make the result undefined. Third, confirm SPF or DKIM passes in alignment with your From domain, because DMARC cannot pass without one of them. EasyDMARC reproduced the rejection with aligned SPF and DKIM but no DMARC record — the reverse case, aligned authentication with no DMARC record at all, is what this change targets.

Finally, give it time. DNS caching means some receivers will keep seeing the old answer for a while after you publish. If the record is visible in a fresh lookup and the bounce persists, wait a few hours and test again with a new message — a bounced message is never retried, so each test needs a fresh send.

Frequently Asked Questions

Does Outlook.com really reject mail without DMARC now?

Yes. Since November 5, 2026, Outlook.com, Hotmail, Live, and MSN have been rejecting some mail from domains with no DMARC record, even when SPF and DKIM pass. MailRoute first reported the rejections from its own outbound logs, and independent tests on November 7 and 8 reproduced them. Microsoft has not announced the change.

What does the 550 5.7.1 AS9031519 bounce mean?

It means Outlook.com refused your message because your sending domain publishes no DMARC record. The 550 makes it a permanent failure — the message is not delivered and will not be retried. The AS9031519 code is new and is not defined in any Microsoft documentation. Adding a DMARC record at _dmarc for your domain stops it.

Is p=none enough to stop the Outlook rejections?

Yes. Tests confirmed that a DMARC record with p=none — the weakest policy, which takes no action on failing mail — is enough for Outlook.com to accept the mail. The rejection is about the absence of a record, not about the strength of your policy. Start with p=none, then tighten to quarantine or reject later once your reports show all legitimate mail passing.

Will adding DMARC break my existing email?

Not with p=none. That policy tells receivers to take no action on mail that fails DMARC checks; it only asks them to send you aggregate reports. It cannot cause legitimate mail to be rejected or sent to spam. Risk only appears if you later move to quarantine or reject before confirming that every service sending as your domain passes DMARC.

What is the best DMARC checker?

Any tool that shows TXT records for a domain will verify a DMARC record, because the record is simply a TXT record at _dmarc under your domain. A free DNS lookup is enough for the check itself. Paid DMARC monitoring tools are worth it only when you need the aggregate reports parsed — for example, before moving from p=none to quarantine or reject.

Does this affect Gmail or Yahoo?

No. This rejection comes from Microsoft's consumer mail platform only. Gmail and Yahoo have their own sender requirements — Gmail has required DMARC for bulk senders since 2024 — but they are not issuing this bounce. The practical lesson is the same everywhere, though: every major receiver now expects a DMARC record, so publishing one protects your mail at all of them.

The Bottom Line

Microsoft changed the rules without telling anyone, and the cost of the change falls on the smallest senders — the ones least likely to have a DMARC record and most likely to find out from a customer. The fix, fortunately, is proportionate: one TXT record, five minutes, no cost, and no risk at p=none.

Check your domain now, before a bounced order confirmation or a missed reply costs you a customer. If the _dmarc record is missing, add it today — and while you are in your DNS settings, confirm your SPF and DKIM records are there too, because DMARC only works when at least one of them passes in alignment with your From address.