Outlook.com Now Rejects Mail Without DMARC: We Tested the New 550 5.7.1

Outlook.com and Hotmail have started refusing mail from domains that publish no DMARC record, even when SPF and DKIM pass. MailRoute says it first saw the refusals in its outbound logs on 5 November 2026, senders compared notes on the mailop list on 6 November, and Spamresource reproduced it on 7 November. The refusal comes during the SMTP session and reads:

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

We reproduced it on the evening of 7 November too, with one question the first reports left open: what happens when the domain in From has no DMARC record of its own, but its parent domain does? That is how many companies send, from a subdomain such as mail.example.com with DMARC published only at example.com.

The short answer: publish a DMARC record at the domain in your From address or at its organizational domain. In our test, either one stopped the refusal, even with p=none, and a domain with neither was refused by every Outlook.com and Hotmail mailbox we sent to.

Disclosure: DMARKOFF builds DMARC monitoring tools. The seed mailboxes came from GlockApps, which is made by the same team. All domains and accounts were our own.

TL;DR

• No DMARC record anywhere: refused. All 16 Outlook.com and Hotmail seed mailboxes refused our message at SMTP with 550 5.7.1 … Message lacks SPF/DKIM/DMARC Auth Records, although SPF and DKIM were set up to pass and align, and did wherever the same message was accepted.
• A record at the parent domain is enough. With no record at the subdomain and p=reject at its parent, the same message was accepted by all 16.
• A record at the subdomain is enough too, with nothing at the parent.
• p=none is enough. In a follow-up on 8 November, p=none on the subdomain, or only on its parent, stopped the refusal as well.
• DMARC decided acceptance, not the folder. With identical records, sent in the same minutes, one subdomain reached the Outlook.com and Hotmail inbox and the other landed in spam. The two also sent from different Mailgun IPs.
• Our Microsoft 365 mailboxes accepted it. All five took the message with no DMARC record anywhere, as Spamresource's Microsoft 365 domain did.
• Not sporadic in our run. Early reports said only some messages were refused. We sent one message per mailbox, and 16 of 16 were refused.

The test

 
We used two subdomains of our test domain mailpath.io that we had already set up in Mailgun for our SPF experiments. Both published v=spf1 include:_spf.mailgun.org -all, so SPF passed for Mailgun's servers, and Mailgun signed every message with a DKIM domain matching the From domain. Each subdomain was both the From and the MAIL FROM domain.

mailpath.io itself publishes v=DMARC1; p=reject; sp=reject, so under DMARC's usual lookup, a subdomain without a record of its own still has a policy: its parent's. To create a domain with no DMARC at all, we then removed the parent's record too, for about 15 minutes. The next morning, we ran three more phases with p=none and p=reject records, to tell the effect of the record from that of the domain. Every record had a TTL of 300 seconds, and each phase went out more than five minutes after the previous phase's last delivery, so receivers couldn't still be using a record they had fetched during it.

Each case went once to the same 24 seed mailboxes: 16 at Outlook.com and Hotmail (including Outlook.de and Outlook.fr addresses), 5 in Microsoft 365, and 3 at Gmail for reference. We read the SMTP replies in Mailgun's log and the folders in GlockApps. Phase A ran from 21:11 to 21:15 UTC on 7 November, phase B from 21:22 to 21:25, and phases C to E between 07:17 and 07:46 UTC on 8 November.

Results

 

refused: rejected during the SMTP session with 550 5.7.1. The other cells are the folder GlockApps found the message in; all of those messages were accepted with 250.

The refusals came from Microsoft's front ends in North America and Europe alike, one after another while the batch was being sent, between 21:22 and 21:24 UTC.

Mailgun's log for the subdomain with no DMARC record anywhere: 16 failed deliveries, each refused with 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) (first five rows, recipients hidden, times UTC+3)

In GlockApps, the same message is missing from every Outlook.com and Hotmail seed, while Microsoft 365 put it in the inbox:

GlockApps, the message with no DMARC record anywhere: missing at Hotmail, Outlook, Outlook.de and Outlook.fr, inbox at Exchange (Office365), two of three Gmail seeds in the inbox

A DMARC record at the parent domain was enough

 
Ten minutes earlier, the same subdomain had no record of its own either, but its parent did. Outlook.com and Hotmail accepted all 16 messages. They went to the spam folder (more on that below), but they were accepted and not refused:

GlockApps, the same subdomain while only the parent domain published DMARC: spam at Hotmail and Outlook, inbox at Exchange (Office365) and Gmail, nothing missing

In our test, a DMARC record at mailpath.io was enough for mail from m01.mailpath.io to be accepted without a record at the subdomain itself. That is consistent with DMARC's policy inheritance; the test doesn't show Microsoft's exact lookup, and since our From and MAIL FROM domains were the same, it doesn't show which of the two the check reads either. A p=none record at the parent was enough as well: in phase D, with no record at the subdomain and p=none; sp=none at mailpath.io, Outlook.com and Hotmail accepted all 16.

The opposite holds as well. Our second subdomain kept its own record while the parent had none, and Outlook.com and Hotmail accepted it in the same minutes as the other was refused:

Mailgun's log for the subdomain with its own DMARC record and none at the parent: delivered to all six Hotmail seeds with 250. The filter covers both phases (12 deliveries); the six latest rows are phase B (recipients hidden, times UTC+3)

What it means for you: check whether a DMARC record applies to the domain you send from, at that domain or at its parent. In our test, a subdomain without a record of its own was fine as long as its parent had one.

The record decided acceptance, not the folder

 
Every phase of m01 that Outlook.com and Hotmail accepted ended in spam: with p=reject at the parent (A), p=none at the parent (D), its own p=none (C) and its own p=reject (E). Every phase of m00 reached the inbox. In phase E, the two subdomains had the same records and went out in the same three minutes, and the 16 Outlook.com and Hotmail seeds still split by domain: m01 in spam, m00 in the inbox. Microsoft 365 and Gmail put both in the inbox.

So the folder didn't follow the DMARC record. It followed the sender, and a sender here is more than the domain: in these tests, Mailgun sent each of our subdomains from a different pair of IP addresses, so they don't separate the domain's history from its IPs. One more difference: in our earlier experiments, m01 was a control that sent mail without an aligned DKIM signature, while m00 always signed for its own domain. We haven't tested which of these, if any, is the reason.

What it means for you: in our test, a DMARC record stopped the refusal; it didn't move a sender out of Outlook's spam folder. After you add one, check where each sending domain's mail lands.

Microsoft 365 accepted our test messages

 
All five Microsoft 365 seed mailboxes accepted the message without DMARC and put it in the inbox. Spamresource also saw acceptance at a corporate domain hosted at Microsoft 365, and the reports so far name Microsoft's consumer domains: Outlook.com, Hotmail, Live and MSN. Neither test shows how every business tenant handles the same mail.

How this differs from Microsoft's 2025 rules for bulk senders

 
Since 5 May 2025, Microsoft's published requirements for domains that send more than 5,000 messages a day to its consumer service ask for SPF and DKIM to pass and for a DMARC record of at least p=none, with SPF or DKIM aligned with the From domain. Microsoft's rollout announcement names the refusal for that case: 550 5.7.515 Access denied, sending domain … does not meet the required authentication level. Its pages disagree on whether such mail goes to junk first.

Our observations differ from those requirements in two ways:

• A different reply: 550 5.7.1 … Message lacks SPF/DKIM/DMARC Auth Records (AS9031519), not 5.7.515.
• No volume threshold that we could see: our test subdomains send a few dozen messages on the days we test, far below 5,000. MailRoute describes small, low-volume senders hit the same way.

Microsoft hasn't announced it, so we can't say whether it's a deliberate change, a test, or something that will be rolled back.

What to do

 

1. Check whether DMARC applies to every domain you send from. Look at the domain in the From address, not the one in your website's address, and at its organizational domain.
2. If neither has a record, publish one at the organizational domain. Start with p=none: v=DMARC1; p=none; rua=mailto:<your report address>. In our follow-up, p=none stopped the refusal, at the subdomain and at the parent alone, and Spamresource and MailRoute recommend it too when SPF or DKIM already passes and aligns. The rua tag gets you aggregate reports, which show who sends mail in your name before you tighten the policy.
3. Don't forget domains that only send transactional mail, such as the domain of an app, a ticketing system or an old brand. They're the ones most likely to have SPF and DKIM set up by a vendor and no DMARC at all.
4. Give the new record a few minutes. A resolver that has cached the answer "no record" can keep it for the zone's negative-caching time: 15 minutes in our Route 53 zone.
5. Watch your bounces for AS9031519. If it appears for a domain that has a record, check that exactly one valid record is published at _dmarc.<domain>, and that SPF or DKIM passes and aligns for the service that sends the mail. Our guide to DMARC bounce errors walks through the other causes.

You can check a domain's DMARC record, and whether it comes from the parent domain, with DMARKOFF's free DMARC checker.
 

Run DMARC Check

 

Limitations

• One message per mailbox and case, over two days. Other senders reported refusals for only part of their mail, so a larger sample might show some getting through.
• Mailgun's shared IPs. We didn't test other ESPs or a sender's own servers. Mailgun sent each subdomain from its own pair of IPs, so the folder difference between them can't be tied to the domain alone.
• Seed mailboxes. GlockApps' Outlook.com and Hotmail seeds are real consumer mailboxes, but their folders also reflect their own history: the spam placement in phase A says nothing about DMARC.
• A change Microsoft hasn't announced. It can be widened, narrowed or rolled back at any time. These results describe 7 and 8 November 2026.

Methodology and data

 
Sending. Mailgun's US shared IPs, the same two for each subdomain in every phase, with Mailgun signing with a DKIM domain matching From. Both subdomains had been verified in Mailgun since October 2026. The refused messages have no receiver Authentication-Results we could read; authentication was set up to pass, and the same subdomain was accepted ten minutes earlier.

DNS. The subdomain's DMARC record was deleted at about 21:05 UTC and the parent's at about 21:17. Both came back at 21:29. On 8 November, both went to p=none at about 07:14, the subdomain's was deleted at about 07:22, and both were back at p=reject at about 07:28. The zone is hosted at Amazon Route 53; the records had a TTL of 300 seconds and the zone a negative-caching time of 900 seconds, so phase E went out more than 15 minutes after D. We checked the records through a recursive resolver: direct queries to Route 53's name servers were refused from the test machine.

Observations. The SMTP replies in Mailgun's log and the folders in GlockApps, for eight tests of 24 seed mailboxes each.

Data. Mailgun's events (recipients reduced to their domain) and GlockApps' per-provider results for the eight tests are kept with our other experiments.

FAQ