Why is Outlook.com rejecting our email with "Message lacks SPF/DKIM/DMARC Auth Records"?

Update, 10 November 2026: Microsoft has confirmed these rejections were caused by a faulty update to its spam enforcement rules (incident EX1545193), not a new policy, and has rolled it back. Mail flow was restored on 9 November. See the follow-up for what Microsoft said and why DMARC is still worth keeping.

The short version

Since 5 November 2026, Outlook.com, Hotmail, Live and MSN have been refusing some mail from domains that publish no DMARC record, whatever their sending volume. Publish a DMARC record (p=none is enough to start) and make sure SPF or DKIM passes for the domain in your From address. Microsoft hasn’t announced the change, so treat it as the new baseline rather than a glitch to wait out.

Status as of 8 November 2026: this is based on bounces that email administrators have reported, and that others have reproduced, since 5 November 2026. Microsoft hasn’t published a notice, a policy update or a service-health entry about it. We’ll update this post when it does.

What the bounce looks like

Mail to an Outlook.com, Hotmail.com, Live.com or MSN.com address is refused at the SMTP stage with:

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

The earliest bounces had the same text without the (AS9031519) code. Each one also carries a bracketed server name and message ID that differ from message to message, so don’t search for the whole line.

Unlike most authentication bounces, this one doesn’t tell you which of SPF, DKIM or DMARC it objected to. In the reports so far, the common factor is a sending domain with no DMARC record at all, often with SPF and DKIM both passing.

Who it affects

• Consumer mailboxes only, so far. Reports cover outlook.com, hotmail.com, live.com and msn.com. Mail to Microsoft 365 business domains has been accepted in the same tests.
• Low-volume senders too. This isn’t the bulk-sender rule. A small business sending a few invoices a day is in scope.
• Some messages, not all. Only a share of messages from an affected domain is refused, and a retry sometimes goes through. One delivered message doesn’t prove your domain is fine.

How it differs from the 5,000-a-day rule

Since 5 May 2025, Microsoft’s published sender policy has required domains sending more than 5,000 messages a day to Outlook.com to pass SPF and DKIM and publish DMARC at p=none or stronger, aligned with SPF or DKIM. Mail that falls short goes to junk first, and is then rejected with a different bounce:

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

The November bounce (5.7.1, “lacks … Auth Records”) reaches domains far below that threshold. The practical reading: a DMARC record is no longer a bulk-sender requirement at Microsoft’s consumer service, it’s the price of delivery.

The fix

1. Check whether you have a DMARC record.

   dig +short TXT _dmarc.example.com
   

   A result starting with "v=DMARC1 means one exists. No result means you’re in the group being refused. The Domain Checker shows the same thing alongside SPF and DKIM without a terminal.

2. Publish one if it’s missing. A TXT record at _dmarc:

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

   p=none changes nothing about how your mail is handled. It declares that the domain uses DMARC and asks receivers for reports, which is what Outlook.com is looking for. Include an rua address: the reports are how you’ll find the senders you didn’t know about. See how to publish a DMARC record for the tags and the authorization record a third-party rua needs, or build the string with the DMARC Record Wizard.

3. Make sure SPF or DKIM passes aligned. DMARC passes only when SPF or DKIM passes for the same domain as the visible From address. A record on its own won’t rescue a sender whose SPF passes for its own bounce domain and whose DKIM signs as someone else’s. That’s how SPF and DKIM can both pass and DMARC still fail.

4. On Microsoft 365, turn on DKIM for your own domain. Until you do, Microsoft 365 doesn’t DKIM-sign mail from example.com at all (Microsoft’s DKIM guide), so DMARC has only SPF to go on, and SPF breaks when mail is forwarded.

5. Check every other sender. Your CRM, invoicing tool, helpdesk and newsletter platform each send as your domain, and each needs aligned SPF or DKIM of its own. Aggregate reports list them; most domains find at least one they’d forgotten.

If you already have DMARC and still see the bounce

A smaller number of senders with SPF, DKIM and DMARC all in place have reported the same bounce on a small share of their mail, with a retry a few minutes later going through. That pattern looks more like a temporary fault than a policy, and there’s no fix on the sending side beyond confirming your records are published and passing. Keep the full bounce text and check your aggregate reports for the day: if Outlook.com reports your mail as DMARC-aligned and passing, the problem isn’t your records.

Where to go from p=none

p=none gets your mail accepted. It doesn’t stop anyone sending as your domain. Once the reports show every legitimate source aligned, move to p=quarantine and then p=reject: quarantine by day 30 and reject from day 60 is the rollout to aim for. Read the risks of moving to p=reject too early before you do.