In short: since Friday, November 6, 2026, mail administrators have reported that Microsoft rejects messages sent to its consumer mailboxes (outlook.com, hotmail.com, live.com, msn.com) when the sending domain has no DMARC record. All types of email are affected, including transactional email, and not only high volumes. The fix is one DNS record: publish a DMARC record, even with p=none.
Status of the information: at the time of writing, Microsoft has not published an official announcement. What follows relies on administrator reports, on our own observations at Sweego (rejections are seen on transactional emails) and on tests run by deliverability specialist Al Iverson, published on Spam Resource. The situation may still evolve.
What is happening?
According to Spam Resource, several administrators on the Mailop mailing list reported, starting Friday night (US time) on November 6, 2026, messages rejected when sent to Outlook Consumer (Hotmail and Outlook.com, not Microsoft 365) if the sending domain publishes no DMARC record.
Observed facts:
- Rejection happens even when SPF and DKIM pass. Only the missing DMARC record is the problem.
- The error message is:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records. - Affected domains are consumer mailboxes: outlook.com, hotmail.com, live.com, msn.com. Corporate Microsoft 365 mailboxes do not seem affected: in Spam Resource’s tests, a message to a Microsoft 365-hosted domain was accepted.
- Rejections can be sporadic. Only a share of your messages may be affected.
What changed compared to 2025
Microsoft already required SPF, DKIM and DMARC from bulk senders, meaning those sending more than 5,000 messages per day to its domains. What administrators now describe is filtering that also hits smaller senders. Spam Resource does not rule out a misconfiguration on Microsoft’s side, but considers that requirements are heading toward tighter rules, as already seen at Gmail and Yahoo.
| Before | Observed since November 6, 2026 |
|---|---|
| DMARC required from bulk senders (over 5,000 messages/day) | Rejections also reported for non-bulk senders |
| Valid SPF and DKIM seen as enough for small volumes | Valid SPF and DKIM are no longer enough without DMARC |
Who is affected?
Any domain sending email to Outlook, Hotmail, Live or MSN addresses without a DMARC record. This includes:
- transactional emails (sign-up confirmations, password resets, invoices, application notifications);
- emails sent from applications, websites or internal tools;
- low volumes, which were not targeted by the requirement until now.
High-volume senders, such as those sending newsletters, generally already have a DMARC record, since the requirement already applied to them. The exposed domains are mostly those that never had to publish one.
What to do: publish a DMARC record
Publish a DMARC record for every domain used in your From address. The minimum is a monitoring policy, p=none, which has no impact on the delivery of your emails.
Create a TXT DNS record:
| Field | Value |
|---|---|
| Name | _dmarc.yourdomain.com |
| Type | TXT |
| Value | v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com |
The rua address receives aggregate reports, which let you check that all your legitimate sending sources are properly authenticated.
Key points:
- DMARC requires SPF or DKIM to pass and be aligned with the domain in the From address.
- If you send from several domains or subdomains, check that each one is covered by a DMARC record. By default, a subdomain inherits the policy of its parent domain, unless you define a specific policy with the
sptag. - DNS changes usually propagate within a few hours.
- Once you have analyzed the reports and your sources are compliant, you can tighten the policy progressively:
p=quarantine, thenp=reject.
Tracking DMARC reports
DMARC reports arrive as XML files, which are hard to read as-is. A dedicated tool can receive and parse them, and identify which sources send on behalf of your domain. SenderAudit offers this (aggregate report parsing, SPF and DKIM alignment, identification of authorized or suspicious sources), along with a free plan and online DMARC, SPF and DKIM checkers. Other DMARC monitoring tools exist, some with free tiers.
Source
- Al Iverson, “Microsoft newly rejecting mail lacking DMARC?”, Spam Resource, November 7, 2026.
Frequently asked questions
Do I need a strict DMARC policy (p=reject) for Microsoft to accept my emails?
Based on published observations, having a DMARC record is enough to avoid the rejection, including with p=none. No strict-policy requirement has been reported so far.
Publishing DMARC is not a mere formality, though: it calls for a global review of all the email sent with your domains and subdomains. You need to list every source sending on your behalf (application, invoicing tool, CRM, customer support, internal servers, service providers, etc.) and check that each one passes SPF or DKIM with alignment. Without this inventory, moving to p=quarantine or p=reject may block legitimate emails. This is what the p=none phase with rua reports is for: spotting these sources before tightening the policy.
Are my transactional emails affected?
Yes. The filtering applies to the sending domain, not to the type of message. Rejections are observed on transactional emails.
Are my emails to Microsoft 365 business addresses affected?
Not according to the reported tests: they were accepted without DMARC. This may change.
Does my sending provider handle DMARC for me?
No. The DMARC record is published in the DNS zone of your sending domain, which you control. Your provider can tell you what value to use and check your setup.
My emails bounce with error 550 5.7.1. What should I do?
Publish a DMARC record on the affected domain, wait for DNS propagation, then send a new test message.
Send your first Email & SMS quickly!
Send your transactional email & sms via API in minutes
