Fix Outlook.com Error 550 5.7.1: Message Lacks SPF/DKIM/DMARC Auth Records

What This Error Means

Outlook.com rejected your message because the sending domain is missing an email authentication record. It is almost always the DMARC record. In the rejections traced so far, the sending domains already had SPF, and many had DKIM, but no _dmarc record. Publishing a DMARC record (even p=none) that SPF or DKIM can pass in alignment is the fix.

The error comes from Microsoft's consumer mail servers (*.olc.protection.outlook.com), which handle outlook.com, hotmail.com, live.com and msn.com addresses. It started appearing on November 5, 2026. The full text is:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
[XXXXXXXXXXXXX.namprd03.prod.outlook.com 2026-11-06T15:13:33.067Z 08DF3B1587DB27E3]

On November 5 the same rejection appeared without the (AS9031519) code:

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

Some senders see it chained after an SPF error, which points at an SPF problem as well (see Microsoft 365 Error 550 5.7.23):

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

This is a permanent rejection (5xx). The message was not delivered and will not be retried. Resending without fixing DNS may get through some of the time, because Microsoft is not rejecting every message from an affected domain. That is not a sign the domain is fine.

What Is New About It

As of November 6, 2026, Microsoft has not published an announcement for this rejection. Its documented sender rule is the one from May 2025: domains sending more than 5,000 messages a day to Outlook.com must pass SPF, DKIM and DMARC, or get 550 5.7.515 Access denied, sending domain ... doesn't meet the required authentication level (see Bulk Sender Requirements).

This error is different in three ways:

• It hits low-volume senders. Ordinary person-to-person mail from small organizations is being rejected, not only bulk mail.
• It does not say which check failed. A 5.7.515 bounce lists Spf=, Dkim= and DMARC= results. This one only says records are missing.
• It is applied to part of the traffic. The same domain can have one message accepted and the next rejected.

The practical reading: Microsoft now expects every domain that sends to Outlook.com to publish DMARC, not only bulk senders.

Step-by-Step Fix

Step 1: Check the domain in the From address

Run the mxio DMARC Checker on the domain in the rejected message's From: address. DMARC is published for that domain, not for the bounce (envelope) address.

• "No DMARC record found" is the most common result for this error. Go to Step 2.
• A record exists — go to Step 3; the record has to be able to pass, not just exist.
• The checker could not get an answer (timeout, SERVFAIL) is not the same as "no record". Fix the domain's nameservers first.

If the From domain is a subdomain (mail.example.com), receivers fall back to the organizational domain's record (_dmarc.example.com). One record at the organizational domain covers its subdomains unless they publish their own.

Step 2: Publish a DMARC record

Add one TXT record at your DNS host:

p=none is enough to clear this error: it asks receivers to report, not to reject. The rua= address receives daily aggregate reports and is optional, but without it you cannot see who sends mail as your domain before tightening the policy later. A trailing semicolon (p=none;) is valid.

The mxio DMARC Wizard builds the record for you. Host-specific steps: Cloudflare, GoDaddy, Namecheap, Route 53, Azure DNS.

Publish only one _dmarc TXT record. Two DMARC records on the same name make the result undefined, and receivers ignore both.

Step 3: Make sure SPF or DKIM passes in alignment

A DMARC record only helps if DMARC can pass. DMARC passes when either:

• SPF passes for the envelope sender, and that domain matches the From domain, or
• DKIM passes with a signature whose d= domain matches the From domain.

The common gaps by platform:

• Microsoft 365 / Exchange Online signs with your tenant's onmicrosoft.com domain until you enable DKIM for your own domain. That signature passes but does not align. Publish the selector1 and selector2 CNAMEs Microsoft shows in the Defender portal and turn DKIM signing on for the domain. See Setting Up DMARC for Office 365.
• Google Workspace needs DKIM turned on in the Admin console and the google._domainkey TXT record published.
• Email security gateways and outbound relays often sign with their own selector, not the email platform's. Example: MailRoute signs relayed mail with mr01._domainkey (CNAME to mr01.dkim.mailroute.net). Checking only selector1/selector2 on such a domain reports "no DKIM" when the gateway's signature is fine. Use the mxio DKIM Checker with the selector your sending path uses.
• SPF over the 10-lookup limit returns PermError, which DMARC treats as a fail. Check with the mxio SPF Checker and see Too Many DNS Lookups.

Step 4: Verify the fix

1. Confirm the record is served. Re-run the DMARC Checker, or from a terminal:

   dig +short TXT _dmarc.example.com

2. Wait out the TTL. Most DNS hosts serve a new record within minutes; a previously cached "no record" answer can last up to the zone's negative-cache TTL (often 5 minutes to 1 hour).
3. Send a test to an Outlook.com address and open the delivered message's headers in the mxio Header Analyzer. You want dmarc=pass in Authentication-Results.
4. Resend the rejected messages. Outlook.com does not retry a 5xx rejection; the sender has to send again.

Fixes by Scenario

If You Already Pass DMARC and Still Get This Bounce

Check that DMARC actually passes on a delivered message (Step 4), not only that a record exists. If it passes and Outlook.com still rejects with this text, the problem is on Microsoft's side. Some senders report exactly that. Keep the complete bounce, including the bracketed server name, timestamp and ID, and submit it through Microsoft's sender support form at olcsupport.office.com.

After p=none: Moving to Enforcement

p=none fixes the rejection, but it does not protect your domain from being spoofed. The path from there is none → quarantine → reject, advanced when every legitimate sender is identified and aligning, not on a fixed schedule. The aggregate reports from your rua= address are how you find those senders.

mxio DMARC Reporting reads those reports and lists every source sending as your domain, and Managed DMARC advances the policy when your senders are ready. See No DMARC Record Found and DMARC p=none for the full rollout.

Related Issues

• No DMARC Record Found — Setting up DMARC from scratch
• DMARC Policy p=none — What monitoring mode does and when to move on
• DMARC Alignment Failure — When SPF or DKIM passes but does not align
• Microsoft 365 Error 550 5.7.23 — SPF validation failed at Microsoft
• DKIM Record Not Found — Missing or unpublished DKIM keys
• Email Bounce Codes — Complete SMTP error code reference