Outlook.com is rejecting mail from domains without DMARC: how to fix 550 5.7.1

If people are telling you their emails to Hotmail or Outlook.com addresses have started bouncing, this is probably why. Since around 6 November 2026, Microsoft's consumer mail service has been rejecting messages from domains that don't publish a DMARC record.

The error

The sender gets a bounce like this:

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

Reports started on 6 November, on Microsoft Q&A, on the mailop mailing list, and in a write-up by Al Iverson at Spam Resource. The pattern in those reports is consistent:

• Who's rejecting: Outlook.com, Microsoft's consumer service, which handles outlook.com, hotmail.com and live.com addresses.
• Who's being rejected: domains with no DMARC record at all, even when the message passes SPF and DKIM.
• It isn't only bulk senders. Small businesses sending a handful of messages a day are seeing it.
• Business mailboxes aren't affected. Mail to Microsoft 365 (Exchange Online) domains is still being accepted in the reported tests.
• Adding a DMARC record fixes it. People in the Microsoft Q&A thread report that the same messages went through once they published one.

What Microsoft has said

Nothing yet about this specific change. At the time of writing there's no announcement, and the Microsoft Q&A thread has answers only from volunteers. So treat this as observed behaviour, not documented policy. It may be a deliberate tightening, or a rollout that gets adjusted.

What Microsoft has published is its April 2025 requirements for high-volume senders to Outlook.com. Those apply to domains sending more than 5,000 messages a day, and require:

• SPF: must pass for the sending domain.
• DKIM: must pass.
• DMARC: "At least p=none and align with either SPF or DKIM (preferably both)."

The rejection code Microsoft documented for that policy is different: 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. The 5.7.1 bounce people are seeing now doesn't match it, which is another reason to read this as a new, undocumented step. Microsoft's FAQ in the same post was already clear about smaller senders, though: "all senders benefit from these best practices."

Why so many domains have no DMARC record

SPF and DKIM are often set up for you. Microsoft 365's domain setup tells you to add the SPF record, and many email services sign with DKIM. DMARC is the one that's easy to miss, and Microsoft 365 doesn't publish it for you. Microsoft's own documentation says: "There are no admin portals or PowerShell cmdlets in Microsoft 365 for you to manage DMARC TXT records in your custom domains. Instead, you create the DMARC TXT record at your domain registrar or DNS hosting service."

So plenty of small businesses on Microsoft 365 or Google Workspace, sending perfectly legitimate mail, have SPF and DKIM passing and no DMARC record at all.

The fix: publish a DMARC record

Add one TXT record in DNS, at your domain registrar or DNS host:

• p=none means "monitor only". It doesn't change how receivers treat your mail. It meets the minimum Microsoft lists, and it's the starting point Microsoft recommends.
• rua= is where receivers send daily aggregate reports. Use a mailbox you'll actually check, or a DMARC reporting service. Outlook.com says it sends these reports to the address in your record.
• Some DNS providers want the full name, _dmarc.contoso.com, instead of just _dmarc.

Then make sure SPF or DKIM actually aligns with the domain in your From address. DMARC passes when either aligned check passes. If you send through Microsoft 365, turn on DKIM signing for your custom domain, so your messages are signed with your own domain.

Check it worked

From PowerShell:

Resolve-DnsName -Type TXT _dmarc.contoso.com | Select-Object -ExpandProperty Strings

Or from any terminal:

nslookup -type=TXT _dmarc.contoso.com

The Email security checker grades a domain's SPF, DKIM, DMARC and MX records in one go, and gives you the records to fix anything missing. DNS changes can take a while to propagate, so give it time before you resend.

Don't stop at p=none

p=none gets your mail delivered again, but it doesn't stop anyone spoofing your domain. Microsoft's guidance is to move gradually: start at p=none, read the reports until you know every service that sends as you, move to p=quarantine, and finish at p=reject. Its documentation says the goal is "a p=reject DMARC policy for all of your custom domains and subdomains".

And for domains you own but never send mail from, including your onmicrosoft.com domain if you don't use it for email, Microsoft recommends publishing v=DMARC1; p=reject; so nobody can send as them.

Checklist

• Check every domain you send from for a _dmarc TXT record.
• If there isn't one, publish v=DMARC1; p=none; with a rua= address today.
• Turn on DKIM for your custom domains in Microsoft 365, so DMARC can align.
• If a marketing platform, CRM or ticketing system sends as your domain, ask it to set up DKIM for your domain too.
• Plan your move from p=none to p=reject.
• Publish p=reject on domains that never send mail.