Outlook AS9031519: What Rejected Mail Without a DMARC Record, Nov 5-9, 2026

From November 5, 2026, mail to people at hotmail.com and outlook.com addresses started coming back with a bounce that named three protocols, explained none of them, and carried a reference nobody had seen before: AS9031519. On Microsoft’s own support forum, one Outlook.com user wrote that “about 50%” of the clients who had emailed them since the previous day were getting it.

The pattern held across hosting providers, mail services and Microsoft 365 tenants. Domains that published SPF, often DKIM too, but no DMARC record were refused intermittently, so a resend sometimes landed and hid the problem.

Below: what the bounce said, what Microsoft said, when it really started, why some notices blamed SPF, and what to do now. The rule that does exist, for domains sending more than 5,000 messages a day, is covered in our Microsoft DMARC enforcement guide.

What did the AS9031519 bounce say?

Every sender got the same core text, Message lacks SPF/DKIM/DMARC Auth Records, from Outlook.com’s inbound servers. What wrapped it depended on the system that sent the mail. These are the four forms we found, with their sources:

# 1. Outlook.com's reply as a Postfix server logged it (Spam Resource test, 2026-11-07)
postfix/smtp[364346]: DC040473: to=<x@outlook.com>, relay=outlook-com.olc.protection.outlook.com[52.101.40.101]:25, dsn=5.7.1, status=bounced (host outlook-com.olc.protection.outlook.com[52.101.40.101] said: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) ...)

# 2. The same reply with Microsoft's server name and timestamp (Lazy Admin, 2026-11-06)
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) [BN2PEPF000055DA.namprd21.prod.outlook.com 2026-11-06T09:39:53.095Z 08DF3765B6D5F6F3]

# 3. Day one: the same text without the AS9031519 suffix (MailRoute)
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records

# 4. What Microsoft 365 senders read: Exchange Online's NDR text, an arrow, then Outlook.com's reply
550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

• Non-Microsoft servers (Postfix, Zoho, hosting providers) logged the raw reply, 550 5.7.1, from a host under olc.protection.outlook.com. OLC is Outlook Consumer, the infrastructure behind Microsoft’s free mailboxes.
• On the first day, the same text arrived without the (AS9031519) suffix, according to MailRoute’s outbound logs.
• Microsoft 365 senders got Exchange Online’s non-delivery report: its own 550 5.7.23 line first, then Outlook.com’s reply after an arrow.

Only Microsoft’s consumer domains refused this mail: outlook.com, hotmail.com, live.com and msn.com. When Al Iverson removed the DMARC record from several low-volume domains on November 7, outlook.com rejected his test message while a corporate domain hosted on Microsoft 365 accepted the same send (Spam Resource).

It was also intermittent. One sender on Microsoft Q&A put a resend’s chance of getting through at “50/50ish”, so one delivered test message proved nothing.

What did Microsoft say caused it?

Microsoft tracked the problem as Microsoft 365 Service Health incident EX1545193, titled “Some users may be intermittently unable to send email messages to Outlook.com, Hotmail.com, or Live.com email addresses”. Its final update, posted on November 10, gives the cause in one sentence:

A recent update to the spam enforcement rules caused email messages to be incorrectly marked and blocked, which led to impact.

The bulletin dates the impact from November 6, 2026, 18:00 UTC to November 9, 2026, 11:02 UTC. It says Microsoft has “fully rolled back this update” and names one next step: reviewing its update procedures and “improving our mail detection logic to lower the false positive rate”.

Two details matter. The bulletin never mentions DMARC. And it attributes the non-delivery reports to a “Service Provider Foundation (SPF) violation”, which is not what SPF stands for: RFC 7208 defines the Sender Policy Framework. Read the bulletin as a spam-filter false positive, not as an SPF verdict.

Service Health is visible only to Microsoft 365 tenant administrators, which is why most senders never saw it. An archived copy of Penn Computing’s public extract of Microsoft’s incident reports carries the full text. In public, a Microsoft support moderator on Microsoft Q&A called it a service degradation under investigation on November 9. On November 10 the same moderator confirmed the rollback and wrote that “users may need to resend those messages”. The Register’s update quotes the same root-cause sentence.

When did the rejections start?

Microsoft’s stated start is November 6, 2026, 18:00 UTC. The evidence of Outlook rejecting emails without DMARC starts earlier:

So search from November 5, not from Microsoft’s start. A log query that begins at November 6, 2026, 18:00 UTC misses everything refused on November 5 and the morning of November 6.

Why did 550 5.7.23 blame SPF?

550 5.7.23 is a code from Exchange Online’s own NDR table. Microsoft’s NDR reference defines it as “The message was rejected because of Sender Policy Framework violation” and explains that “The destination email system uses SPF to validate inbound mail, and an issue affects your SPF configuration.” In the notices Microsoft 365 senders posted, that line comes first, then an arrow, then Outlook.com’s 550 5.7.1 reply. Senders on Postfix, Zoho or any other system never saw 5.7.23 at all: they got the raw 5.7.1.

That points one way: the SPF wording most likely came from Exchange Online’s report, not from a failed SPF check. The operators who tested it had SPF passing (Mythic Beasts described “completely valid SPF and DKIM”), and Microsoft’s moderator described a rule that “incorrectly identified some legitimate emails as SPF violations”. Microsoft has not put it in those words, so treat this as our reading of the evidence.

If you edited SPF in a hurry because of this notice, check that the record still authorizes every service that sends as your domain. The SPF checker shows each mechanism and the lookup count.

Why did headers say dmarc=pass with no DMARC record?

Several Microsoft 365 users on Microsoft Q&A wrote that their own outbound headers said DMARC passed, yet a public lookup found no record. Microsoft’s header documentation explains how that happens. It defines a DMARC result beside pass, fail and none, dmarc=bestguesspass, which “indicates that no DMARC TXT record exists”. It adds: “If the domain had a DMARC TXT record, the DMARC check for the message would pass.” Microsoft’s own example line reads: dmarc=bestguesspass action=none header.from=contoso.com.

So bestguesspass is a prediction, not a result. RFC 9989 registers dmarc=none for exactly this case, “No DMARC Policy Record exists for the Author Domain” (RFC 9989 §9.2); bestguesspass is Microsoft’s own value, and a reader skimming for “pass” sees a pass. The posts did not include the raw header, so this is the most likely explanation, not a confirmed one.

The lesson is to check DNS, not headers. dig +short TXT _dmarc.example.com prints the record if one exists; no output means none. To read a full header, see how to read the Authentication-Results line, or paste it into the email header analyzer.

Did Microsoft start requiring DMARC for small senders?

No. Microsoft announced nothing, and its published rules are unchanged. The Policies tab of the Outlook.com Postmaster site still says “We strongly recommend all senders implement SPF, DKIM, and DMARC”, and makes them a requirement only for domains sending more than 5,000 emails a day, whose non-compliant mail goes to Junk and may be rejected with 550 5.7.515. Its Troubleshooting tab lists that code and has no entry for the AS9031519 text. The Microsoft 550 5.7.515 Diagnostic scores a domain against that rule.

The standard says the same thing from the other side. Under RFC 9989 §4.10.1, when a domain publishes no DMARC policy record, receivers “MUST NOT apply the DMARC mechanism to the message”. Refusing a domain with no record is therefore not DMARC enforcement. It is Outlook.com’s own filtering, which RFC 9989 §5.4 leaves to “local policy”, and it matches Microsoft’s explanation: a spam rule, not a DMARC rule. What changed in RFC 9989 covers the rest of DMARCbis.

What did change is the evidence. From November 5 to November 9, a missing DMARC record could cost a domain part of its mail at Outlook.com, whatever the sending volume. Microsoft’s bulk rule and this fault point the same way, and a record costs one TXT line.

How many domains were exposed?

In DMARCguard’s February 27, 2026 scan of 5,499,028 domains (the full Tranco list), 1,584,176 (28.8%) published an SPF record or a DKIM key at one of the selectors we probe, but no DMARC record: the same combination as the domains in the operators’ tests above.

Read it as exposure, not damage. A published SPF record is not a passing one, many ranked domains send no mail at all, a DMARC lookup that failed during the scan counted as no record, and Outlook.com refused only part of the mail from an affected domain. The full breakdown is in State of Email Authentication 2026. If your domain is in that group, step 3 below is one TXT record.

What should you do now that Microsoft rolled it back?

Microsoft’s rollback stopped new rejections. It did not deliver the mail that was refused, and it did not change why your domain was exposed. Four steps fix both.

1. Find the bounces. Search from November 5, 2026 to November 9, 2026, 11:02 UTC. Match the text, not the code: 550 5.7.1 is a general policy code, and the day-one form had no AS9031519 suffix.

   • Microsoft 365: in the Exchange admin center, open Mail flow > Message trace, set the dates, add the recipients *@outlook.com, *@hotmail.com, *@live.com and *@msn.com (one wildcard per value), and set Delivery status to Failed. Message trace reaches back 90 days (Microsoft Learn), so run it soon.
   • Postfix: this lists every refused recipient from current and rotated logs.
   Find AS9031519 bounces in Postfix logs bash

   # Postfix: recipients Outlook.com refused with this text, from current and
   # rotated logs (both the AS9031519 form and the day-one form match).
   # Debian/Ubuntu log to /var/log/mail.log; RHEL-family to /var/log/maillog.
   zgrep -h 'Message lacks SPF/DKIM/DMARC Auth Records' /var/log/mail.log* \
     | grep -o 'to=<[^>]*>' | sort | uniq -c | sort -rn

2. Resend what matters. A 550 is a permanent failure, so nothing was retried. Start with invoices, confirmations and replies to people who never heard back.

3. Keep the DMARC record, and make it report. If you published v=DMARC1; p=none in a hurry, keep it. p=none asks receivers to take no action on failures, so it does not ask Gmail, Yahoo or anyone else to reject your mail. Add a rua= address so aggregate reports (RFC 9990) start arriving; without one, nobody learns which of your services fail. Make sure the reports reach you, or build the record with the DMARC generator.

   DMARC record with reporting dns

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

4. Earn your way to enforcement. p=none is a starting point. Once the reports show every legitimate service passing aligned SPF or DKIM, move to p=quarantine and then p=reject. Moving off p=none walks through it.

A missing record does not explain every report. Some senders said they were rejected with SPF, DKIM and DMARC all in place, on Microsoft Q&A and in Windows Latest’s coverage. Those reports are unverified, and several on Microsoft Q&A turned out to have no published record after all, with headers that showed a pass. Microsoft’s explanation, a spam rule, does not limit the fault to missing records either, and nobody tested a domain that publishes a DMARC record with neither SPF nor DKIM aligned. If you had a record and still bounced, keep the full bounce and the message headers, and read your aggregate reports before changing anything.

If you only receive mail at an Outlook.com address, there is nothing to change on your side. The sender’s domain owns the record, so forward the bounce to the sender and ask them to check it.

Frequently asked questions

Is Outlook.com still rejecting mail from domains without DMARC?

No. Microsoft says it rolled the faulty spam rule back and puts the end of impact at November 9, 2026, 11:02 UTC, and senders on Microsoft Q&A reported delivery returning that day. If the AS9031519 text still appears, send the full bounce to Microsoft’s sender support; a 550 5.7.515 bounce is the separate bulk-sender rule.

Does Outlook now require DMARC for small senders?

No. Microsoft announced no new requirement. Its Postmaster policies still strongly recommend SPF, DKIM and DMARC for every sender and require them only for domains sending more than 5,000 emails a day. The November 2026 rejections were a spam-rule fault that Microsoft rolled back, not a rule change.

What does AS9031519 mean?

AS9031519 is a reference Outlook.com appended to its 550 5.7.1 rejection during the November 2026 spam-rule fault. Microsoft documents neither the code nor its text, “Message lacks SPF/DKIM/DMARC Auth Records”. Operators’ tests tied it to mail from domains with no DMARC record, which Outlook.com refused intermittently from November 5 to 9.

Do I need to resend emails that bounced?

Yes. Outlook.com answered with a permanent 550 error, so the sending server did not retry, and Microsoft’s rollback delivered nothing after the fact. Search your logs or message trace from November 5 to November 9, 2026 for the rejection text, then resend the messages that still matter.

Should I keep the p=none DMARC record I added?

Yes. A p=none record asks receivers to take no action on DMARC failures, so it does not ask any provider to reject your mail, and publishing one is what stopped these bounces for the senders who added it. Add a rua= address so aggregate reports show which services send as your domain.

Can an Outlook.com user fix this from their mailbox?

No. Outlook.com refused the message during SMTP delivery, before it reached any mailbox, so safe-sender lists and mailbox settings never see it. The fix belongs to the sending domain: forward the bounce to the sender and ask whoever runs their email or DNS to publish a DMARC record.

What should you take away from AS9031519?

• The AS9031519 bounce came from a Microsoft spam-rule fault, EX1545193, which Microsoft rolled back; it puts the end of impact at November 9, 2026, 11:02 UTC. It was not a new DMARC requirement.
• It started on November 5, before Microsoft’s stated start, so search your logs from then.
• The 5.7.23 SPF wording most likely came from Exchange Online’s report. Check SPF, but do not rewrite a working record.
• Resend what bounced, keep the DMARC record, and add rua=.

Check your domain’s DMARC record, free and with no signup: the DMARC checker shows whether it is live and parses. To see which services fail alignment, start monitoring your DMARC reports: free plan, no credit card.