Outlook.com Has Been Rejecting Emails Without DMARC Since November 5 and Never Announced It

Since November 5, 2026, Microsoft's consumer email service (Outlook.com, Hotmail, Live, and MSN) began rejecting part of the messages coming from domains that do not publish a DMARC record. The pattern was reported by MailRoute, an email security company, in a post on its own blog published on November 6. Microsoft had not issued a statement, status post, or Postmaster notice by the time this article was published.

The detail that matters for anyone operating infrastructure: this is not the bulk sender rule that Microsoft had already announced. It's a new, silent behavior that affects small domains and low sending volumes, including one-off replies from an internal system or a single support agent.

What the Rejection Looks Like in Practice

The sender receives a bounce like this one, with a server code that varies by message:

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

On the first day of the new behavior, the same rejection arrived without the code in parentheses. According to MailRoute, most of the affected domains already had SPF working, and a good share also had DKIM. What was missing was specifically the DMARC record, which is what ties SPF and DKIM to the domain that appears in the message's "From" field.

Why This Differs From the May 2025 Rule

Microsoft already had a public policy: since May 2025, domains sending more than 5,000 messages a day to Outlook.com have had to pass SPF, DKIM, and DMARC, under penalty of a 550 5.7.515 Access denied error. That rule targeted bulk senders and marketing services, and most small companies correctly assumed it didn't apply to them.

The behavior identified now differs in three ways:

• It affects small senders: a single reply from an internal system can be rejected.
• It wasn't announced: as of November 6, there was no Postmaster notice, blog post, or entry on a Microsoft status page about the change.
• The bounce doesn't detail what failed: unlike the 5.7.515 error, which lists SPF, DKIM, and DMARC results separately, this one only reports that the records are missing.

The Tricky Part: Not Every Message Fails

The most dangerous part of the behavior, according to MailRoute, is its inconsistency. Microsoft only rejects part of the traffic from an exposed domain: one message to a Hotmail address goes through, the next one to the same address fails, and a resend might succeed.

We first saw these bounces in our own outbound logs on November 5.

Thomas A. Johnson, founder and CEO of MailRoute

This intermittency is what makes the problem go unnoticed: the sender sees a bounce full of acronyms, assumes it's a one-off failure, and moves on. The intended recipient never knows a message was sent. For anyone operating systems that talk to users at personal email addresses (sign-up confirmations, invoices, application status updates, appointment reminders), the cost is silent: nothing visibly breaks, but a fraction of the traffic simply disappears.

How to Check If Your Domain Is Exposed

The check takes seconds in any terminal. Just swap example.com for the domain you use to send transactional or corporate email:

dig +short TXT _dmarc.example.com

A line starting with v=DMARC1 indicates the domain already has a record. An empty output means no DMARC is published, and that's exactly the case the new Outlook.com rejection is targeting.

The Fix Is a DNS Record

The fix is a TXT record published with the domain's DNS provider:

• Name: _dmarc
• Value: v=DMARC1; p=none

The p=none policy is the safe starting point: it declares that the domain uses DMARC and asks receiving servers for reports, but it doesn't instruct anyone to reject or quarantine anything on failure. Nothing changes in how Gmail, Yahoo, or any other provider handles the rest of the domain's traffic.

Watch Out for SPF/DKIM Alignment

There's a condition that trips up anyone who publishes the record without checking the rest: DMARC only passes when SPF or DKIM pass aligned with the domain that appears in the message's "From" field. If neither one is aligned, the DMARC record alone won't resolve the rejection.

This is where a lot of corporate setups fail without the team noticing. MailRoute cites the example of Microsoft 365: by default, the service signs messages with Microsoft's own onmicrosoft.com domain until DKIM is explicitly enabled for the company's domain, and that default signature doesn't count toward DMARC alignment. In practice, this suggests any third-party email sending service can hide the same trap: if it signs messages with its own domain instead of the client company's domain, DMARC alignment fails until someone explicitly enables signing with the correct domain.

What Changes for Those Operating Infrastructure in Brazil

For Brazilian startups and companies, the practical takeaway is direct: any system that sends email to a customer's, applicant's, or end user's personal address (and in Brazil, hotmail.com and outlook.com are still widely used by individuals) is subject to this silent rejection if the sending domain lacks DMARC.

This covers common cases in a product stack:

1. Sign-up confirmation or password recovery triggered by an authentication service.
2. Billing notification or invoice sent by a billing system.
3. Automatic reply from a contact form or an HR job application.

The dig check takes seconds and should become a routine item in any domain audit, alongside SPF and the TLS certificate. Anyone already using a third-party email relay that signs DKIM with their own domain (instead of signing with the provider's shared domain) tends to solve the problem just by publishing DMARC, since alignment already exists.

Where This Is Headed

MailRoute's reading is that this is the pattern every major mailbox provider has been following: the requirement starts with bulk senders, gets announced with a deadline, and later becomes the baseline for everyone, without notice. DMARC at p=none has stopped being a best practice and become the bare minimum for any domain that sends email, not just for those blasting out high-volume newsletters.

The same record that prevents this rejection today is also the first step toward p=reject, a policy that instructs providers to reject messages that spoof the company's domain, a direct defense against phishing and business email compromise scams that use corporate domains as bait.