Outlook: Message lacks SPF/DKIM/DMARC Auth Records

Since November 5, 2026, the date of the first reports, Microsoft's consumer mail service rejects part of the mail sent to outlook.com, hotmail.com, live.com and msn.com addresses from domains that publish no DMARC record. The sender gets this bounce:

 

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

The rejection hits even low-volume senders.

What changed at Outlook.com

Until this month, Outlook.com required DMARC only from domains that send more than 5,000 messages a day. Three kinds of evidence show that this has changed:

• Mail operators on the mailop list, Fastmail and MailRoute reported the bounce for customers with valid SPF and DKIM, aligned with the From domain, and no DMARC record.

• A controlled test. On November 7, a deliverability researcher deleted the DMARC record from several low-volume domains and sent test mail. Outlook.com rejected it with the 550 5.7.1 error. A company domain on Microsoft 365 accepted the same message.

• The fix. Admins on Microsoft Q&A added a DMARC record, and the messages that bounced before went through.

The rejections are partial. One admin on Microsoft Q&A saw about half of the clients who wrote to them bounce, others saw a smaller share.

The server name in the bounce shows which Microsoft system rejected the message:

Recipient	Microsoft server	Mail from a domain without DMARC
outlook.com, hotmail.com, live.com, msn.com	*.olc.protection.outlook.com	partly rejected with 550 5.7.1
Company domains on Microsoft 365	*.mail.protection.outlook.com	accepted

No announcement from Microsoft

The Defender for Office 365 blog on Tech Community, the Outlook.com postmaster site and Microsoft Learn describe only the 2025 bulk sender rule. That rule has its own error:

 

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

Microsoft's documentation does not mention the code AS9031519. The 2025 rule came with a blog post a month before enforcement, and that post promised future dates on the same blog. Whether this change is a planned rollout or a filter that fires too widely, the fix is the same.

Why so many domains have no DMARC record

Most affected domains broke no published rule, so their owners had little reason to add DMARC.

Microsoft 365 makes the gap easy to miss:

• Setup leaves DMARC out. When a custom domain is connected to Microsoft 365, the setup adds the MX and SPF records it needs, and Microsoft 365 has no place for DMARC: "There are no admin portals or PowerShell cmdlets in Microsoft 365 for you to manage DMARC TXT records in your custom domains." A domain set up exactly as Microsoft 365 suggests now gets some mail rejected by Outlook.com, Microsoft's own consumer service.

• Default DKIM does not count. Until DKIM is turned on for the custom domain in Microsoft Defender, Microsoft 365 signs with the onmicrosoft.com domain. That signature does not align with the From domain, so DMARC depends on SPF alone, and forwarded mail fails DMARC. This is not the cause of the bounce; step 5 fixes it.

How to fix "Message lacks SPF/DKIM/DMARC Auth Records"

1. Confirm the error. The bounce is for a recipient at outlook.com, hotmail.com, live.com or msn.com, and it contains "Message lacks SPF/DKIM/DMARC Auth Records".

2. Look up the DMARC record.

 

dig +short TXT _dmarc.example.com

On Windows, use nslookup -type=TXT _dmarc.example.com. Or run the free DMARC check. An empty answer means the domain is affected.

3. Publish a DMARC record. Add a TXT record at the DNS host, not in Microsoft 365:

Type	Name	Value
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:example.com@rua.dmarcdkim.io

p=none asks receivers to take no action on mail that fails DMARC, so it does not change delivery at Gmail, Yahoo or other providers. The rua tag sends daily aggregate reports, Microsoft's included, to DmarcDkim.com, which shows which services pass DMARC and which fail. A record without rua is a dead end: it leaves the domain owner blind, with no safe path to p=quarantine or p=reject. The DMARC check suggests the complete record for the domain, with its own report address.

4. Keep one record. Under the DMARC specification, a domain with two DMARC records has no valid policy, and receivers ignore both. Edit an existing record instead of adding a second one.

5. Make DMARC pass, not just exist. DMARC passes when SPF or DKIM passes for the domain in the From address. In Microsoft 365, turn on DKIM for the custom domain at security.microsoft.com/dkimv2: publish the selector1 and selector2 CNAME records, then switch signing on. Other services that send as the domain, such as a newsletter tool, CRM or help desk, need DKIM for the domain too.

6. Send the bounced mail again. A 550 is a permanent failure, so the sending server does not retry it. Run the lookup from step 2 until the new record shows, then resend.

7. Escalate if the bounces continue. A few admins report the same error from domains that do publish DMARC. If the DMARC check shows a valid record and aligned SPF or DKIM, and the bounces go on, send the full bounce text to Microsoft through the Outlook.com sender support form.

An Outlook.com user who hears about these bounces cannot fix them. The record belongs to the sender's domain. Forward the bounce to the sender's IT admin.

Misleading signs during troubleshooting

"SPF validation error" (5.7.23). Some bounce notices lead with this headline. The SPF record passes, and the detail lines of the same notice name the real cause: the message "lacks SPF/DKIM/DMARC Auth Records".

dmarc=bestguesspass in Microsoft 365 headers. It sits next to spf=pass and dkim=pass in the Authentication-Results header and looks like a pass:

 

dmarc=bestguesspass action=none header.from=example.com

Microsoft defines it as "no DMARC TXT record exists for the domain. If the domain had a DMARC TXT record, the DMARC check for the message would pass." Treat it as a missing record.

A resend that goes through. One delivered resend does not prove the domain is fixed. Check DNS instead.

Safe senders on the recipient side. Outlook.com rejects the message during the SMTP conversation, before mailbox rules run. Safe senders lists and junk settings do not help.

How DMARC rules tightened, provider by provider

When	Provider	Change
February 2024	Gmail, Yahoo	Senders of 5,000+ messages a day need SPF, DKIM and an aligned DMARC record, p=none at least. Other senders need SPF or DKIM.
May 2025	Outlook.com	The same rule for senders of more than 5,000 messages a day. Microsoft first announced Junk, then switched to rejection with 550 5.7.515 before the start date.
November 2025	Gmail	"Ramping up its enforcement on non-compliant traffic", with temporary and permanent rejections.
November 2026	Outlook.com	Rejects some mail from domains with no DMARC record, including low-volume senders.

In under three years, the response hardened from Junk and delays to rejections, and the volume threshold that kept small domains out of DMARC has started to fall.

What comes next

The pattern points in one direction:

• DMARC for small senders at Gmail and Yahoo. The two have moved in step since 2024. Expect them to follow Outlook.com and drop the volume threshold for the record.

• A pass, not just a record. Today's bounce fires on a missing record. The bulk sender rules at Outlook.com, Gmail and Yahoo already require an aligned pass, so expect the check to move from the record to the result.

• Enforcement after monitoring. No provider requires p=quarantine or p=reject yet, and since May 2026 DMARC is a Proposed Standard (DMARCbis, RFC 9989). Treat p=none as the first step of a rollout, not the end of one.

DMARC is no longer a bulk sender rule

Outlook.com changed the rule without notice, and the next provider may do the same. A domain owner who reads DMARC reports sees which sources fail DMARC before a provider starts to bounce them.

Run the free DMARC check on the domains that send mail, and follow the Microsoft 365 DMARC, DKIM and SPF setup guide to align DKIM. Then let DmarcDkim.com DNS monitoring flag the day a DMARC record goes missing, and DMARC Analytics show which sources pass at Microsoft.