Outlook Rejecting Email Without DMARC: How to Check and Fix It

Since November 5, 2026, Microsoft's consumer mail services (outlook.com, hotmail.com, live.com and msn.com) have been rejecting some email from sending domains that have no DMARC record. The bounce reads 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records, and it hits low-volume senders as well as bulk ones. The fix is to publish a DMARC TXT record at _dmarc.yourdomain, even one with only p=none, and confirm that SPF or DKIM aligns with your From domain. You can do it in under ten minutes.

As of November 8, Microsoft had made no announcement, so everything below comes from mail operators' logs and independent tests. Those reports agree with each other, and the fix is low-risk enough to apply now regardless of whether Microsoft calls the change intentional.

What changed, and what is confirmed

Email vendor MailRoute first described the problem in a November 6 post. It said rejections first appeared in its outbound logs on November 5, and that Microsoft had published no postmaster notice, blog post or service-health entry. Transactional email service toSend reported a few hundred bounces in the first day. In the cases it examined, the sending domain had working SPF and DKIM but no DMARC record.

The strongest evidence comes from deliverability expert Al Iverson. On November 7 he deleted the DMARC records from several of his non-bulk domains and sent test mail. Mail to an outlook.com address was rejected with the 5.7.1 error. The same mail to a Microsoft 365-hosted corporate domain was accepted. Iverson says he is unsure whether the change is intentional policy. Either way, he recommends adding DMARC now.

Engagor's timeline adds more detail. UK host Mythic Beasts logged over 500 rejections in one day after seeing none before. A Microsoft Q&A thread collected more than 60 "same question" votes in two days. And on the second day, an (AS9031519) suffix started appearing in the bounce text. Microsoft has not documented what that code means.

What we know vs. what's unclear

One more caution: db8 notes that some administrators report failures even with correct SPF, DKIM and DMARC. DMARC is the common factor in most reports, but it may not explain every case.

How this differs from Microsoft's 2025 bulk-sender rule

Microsoft already has a published rule, and it is easy to confuse the two. Its support page for NDR 550 5.7.515 defines a "high volume" sender as one sending 5,000 or more messages to Microsoft consumer services from the same 5322.From domain. Those senders must pass SPF and DKIM and publish a DMARC record (p=none is enough), and at least one of SPF or DKIM must align with the From domain. That rule took effect in May 2025.

The November 2026 rejections differ in three ways:

1. Volume doesn't matter. Engagor cites an operator who sends about 20 messages a week and was still rejected.
2. Different bounce code. The published rule returns 550 5.7.515 Access denied and lists the SPF, DKIM and DMARC results. The new rejection is 550 5.7.1 and doesn't say which check failed (MailRoute).
3. No documentation. No Microsoft page covers the new behaviour.

This fits a long-running trend. Google's sender guidelines have required SPF, DKIM and DMARC for senders of more than 5,000 messages a day to Gmail since February 1, 2024. Rules that start with bulk senders tend to become everyone's baseline. If you run a small SaaS that sends password resets, receipts or onboarding email, assume DMARC is now required.

Recognising the bounce in your logs

The error looks different depending on where you see it, so match on the full text rather than the generic status code:

• Direct from Outlook.com: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519). The suffix was missing on day one.
• Wrapped by a Microsoft 365 tenant: a 550 5.7.23 headline that says "Sender Policy Framework violation", with the AS9031519 text in the detail line. Engagor warns that this sends admins chasing SPF problems that aren't there.
• Misleading headers: some received messages show dmarc=bestguesspass, which made senders think they had DMARC. They didn't. Check DNS, not headers.

Sources disagree on whether these bounces get retried. Engagor treats 5.7.1 as a permanent failure that is not retried. toSend says Outlook returns them as soft bounces, and its platform pauses a recipient for two hours after two soft bounces. Your mail server or email provider may handle it either way, so don't assume rejected messages will deliver themselves later.

Fix it: a step-by-step checklist

1. Check whether you have a DMARC record

Run this against the domain in your From address. That domain is what matters, not your website or your email provider's domain:

dig +short TXT _dmarc.yourdomain.com

If the output starts with "v=DMARC1, a record exists. Empty output means the domain is exposed (MailRoute). On Windows, nslookup -type=TXT _dmarc.yourdomain.com does the same job. Web checkers such as MXToolbox or Internet.nl's email test also work (db8).

Run the check for every domain you send from: your primary domain, any separate marketing or notification domain, and any old brand domains that still send mail.

2. Publish one DMARC record with p=none

Add a TXT record:

• Host/name: _dmarc
• Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The rua tag is optional, but you'll want it. It tells receivers to send aggregate reports, which you need before you ever tighten the policy. p=none asks for reports and takes no action on failing mail, so it can't block legitimate messages.

Two rules matter here:

• Publish exactly one record. With two v=DMARC1 records, receivers ignore both (db8, toSend).
• Don't start at p=reject, and don't weaken an existing quarantine or reject policy as a "fix". Domains that already have DMARC aren't the ones being hit.

3. Confirm alignment, not just a passing check

A DMARC record alone won't help if neither SPF nor DKIM passes for the From domain. Microsoft's own 5.7.515 guidance puts it this way: the return-path (5321.MailFrom) domain should match the From domain for SPF, and the DKIM signing domain should match the From domain. Common gaps:

• Microsoft 365: by default it signs with your onmicrosoft.com domain. That signature passes but doesn't count toward DMARC. Turn on DKIM for your own domain in the Microsoft Defender portal and publish the selector1 and selector2 CNAMEs. Microsoft 365 also does not create a DMARC record for you (db8).
• Transactional and marketing providers: finish their domain-authentication setup (custom DKIM, and a custom return-path if they offer one). Otherwise mail is signed with the provider's domain.
• Website and CMS mail: contact forms and plugins that use PHP mail() often send without DKIM. db8 suggests switching them to authenticated SMTP, for example in Joomla under System → Global Configuration → Server → Mail.

DKIM alignment is the more reliable of the two because SPF breaks when mail is forwarded.

4. Resend what bounced

Pull bounces since November 5 that match the 5.7.1 text or the AS9031519 code. Once DNS has propagated, resend the important ones: password resets, invoices, magic links and support replies. A 550 rejection means the message was never queued on Microsoft's side (Engagor). For users who signed up with Hotmail or Outlook addresses and never got their verification email, a short "please try again" email can recover lost signups.

5. Add monitoring

Set an alert on the bounce text, not on the generic 5.7.1 code, which other problems also produce. If you have a list of active domains (for example, for customers who send through your platform), add a scheduled DMARC check for each. toSend built exactly that into its dashboard after this incident.

What this means if you build software that sends email

If your product sends mail on behalf of customers' domains, such as helpdesks, CRMs, newsletter tools, booking apps or invoicing tools, your support queue is about to fill with tickets from customers whose email is "randomly" bouncing at Hotmail. Some practical moves:

• Check customer domains now. Run the _dmarc lookup across verified sending domains and flag the ones without a record.
• Make setup a single click where you can. toSend added a "Set up in Cloudflare" button. At minimum, show the exact record to paste.
• Fix your own transactional domain first. A SaaS whose signup emails bounce for Outlook users loses those users quietly.
• Separate streams. Send product notifications from a different subdomain than marketing mail, so each stream builds its own reputation.

If you're picking tools in this area, our directory lists AI email tools and AI customer support tools. Before you connect any of them to your domain, ask whether they support custom DKIM and a custom return-path.

What to watch next

• A Microsoft statement. Whether Microsoft calls this policy or a filtering error will decide whether it lasts. It's sensible to act as if it will.
• Whether rejections stop being intermittent. So far only some messages bounce. A full cutover would make missing DMARC a hard outage.
• Microsoft 365 business tenants. Reports so far say they aren't affected. Engagor notes that a Microsoft employee said in April 2025 there were no plans to extend the bulk-sender requirement to enterprise, but that was before this change.
• Your DMARC reports. After two to four weeks at p=none, use the reports to find every service sending as your domain. Then move to p=quarantine and eventually p=reject, which is what actually protects your domain from spoofing.

Do the lookup today. If it comes back empty, a one-line TXT record fixes it.