# Outlook is bouncing small senders' mail without DMARC, MailRoute reports **Summary:** MailRoute reports Outlook.com rejecting small senders without DMARC. Check the policy and aligned authentication; adding a record alone cannot guarantee delivery. - Canonical: https://markhuang.ai/news/outlook-small-senders-missing-dmarc - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-11-08 - Section: News - Tags: Outlook.com, DMARC, Email Deliverability, Email Authentication, DNS - Source: [MailRoute](https://mailroute.net/blog/outlook-rejecting-email-without-dmarc) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A cream paper envelope stopped at a blue mail slot beside a red return arrow](https://cdn.markhuang.ai/news/outlook-small-senders-missing-dmarc/hero.webp) *Conceptual illustration generated with OpenAI gpt-image-2: an ordinary message can meet an authentication check at its destination.* A one-line reply from a small office can bounce when it reaches Outlook.com, even if the sender already uses email authentication. That is the finding in [MailRoute's November 6 report](https://mailroute.net/blog/outlook-rejecting-email-without-dmarc): the company says it began seeing rejections on November 5, 2026, involving domains without a DMARC record. It describes intermittent failures affecting mail to Microsoft's consumer addresses, including Hotmail, Live, MSN, and Outlook.com. The reported change matters because Microsoft's published authentication requirement targets domains sending more than 5,000 messages a day. MailRoute says ordinary replies are getting caught too. A small organization that dismissed the bulk-mail rules now has a concrete reason to check its domain and its returned messages. The report gives domain owners a specific error to look for. Publishing DMARC may resolve these rejections if the mail already authenticates for the domain readers see in the From address. The reports do not establish a universal Microsoft rollout, and a DNS record cannot guarantee delivery. ## A different bounce from the bulk-mail rule MailRoute reproduces this rejection: ```text 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) ``` The company says many affected domains already had working SPF, and some also had DKIM. Both help a receiving mail service check where a message came from. MailRoute attributes these failures to missing DMARC, which connects those checks to the sender address a person sees. [Microsoft's high-volume sender announcement](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) describes a different error, `550 5.7.515`, and an enforcement date of May 5, 2025. Its requirements include passing SPF and DKIM, plus a DMARC policy of at least `p=none` with alignment through either authentication method. Its FAQ says enforcement initially targets large senders. MailRoute says no announcement accompanied the November behavior it observed. The linked Microsoft guidance does not establish a November expansion to every small sender. The report warrants checking delivery failures now. It leaves the scope of the change unresolved. ## DMARC checks which domain authenticated SPF checks whether a sending server is authorized for the message's envelope-sender domain, an address used behind the scenes during delivery. DKIM checks a digital signature associated with a signing domain. Neither result, on its own, necessarily authenticates the domain shown to the recipient. A mail service could authenticate a message under its own domain while displaying your business's address in the From field. DMARC asks whether a successful SPF or DKIM check belongs to a domain that matches that visible address. The [DMARC specification, RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), calls this alignment. Depending on the policy, the domains must match exactly or share an organizational domain, such as two subdomains of `example.com`. For a message evaluated under a valid DMARC policy, either aligned authentication route is sufficient for a DMARC pass: ```mermaid flowchart TD S["SPF passes and its domain aligns with From"] --> D["DMARC passes if either route succeeds"] K["DKIM passes and its domain aligns with From"] --> D D --> R["Receiver still applies its own delivery rules"] ``` Adding a policy may resolve the cases MailRoute describes. It cannot repair a failed signature or make an unrelated sending domain match yours. The bulk-sender requirement for both SPF and DKIM to pass is also stricter than DMARC's own either-route test. ## Check the policy before pasting a fix Start with the returned message. If it contains the reported missing-authentication error, ask whoever manages your email and DNS to inspect the domain in your visible From address. For `example.com`, MailRoute suggests this lookup: ```bash dig +short TXT _dmarc.example.com ``` A record beginning `v=DMARC1` indicates a published DMARC policy, though its contents still need checking. If you send from a subdomain, a parent-domain policy may apply; an empty lookup at the subdomain alone does not settle the question. RFC 9989 explains how receivers find the applicable policy. If there is no applicable policy and your provider confirms aligned authentication, MailRoute recommends a TXT record at `_dmarc` with this value: ```text v=DMARC1; p=none ``` That publishes a policy without asking receivers to quarantine or reject messages because they fail DMARC. Preserve an existing policy while investigating. Replacing `p=reject` with `p=none` would weaken the domain owner's stated handling preference, and adding a second DMARC policy record at the same name can invalidate policy discovery. > **Info:** > > The minimal record above does not request aggregate reports. Despite MailRoute's wording, `p=none` alone does not tell receivers where to send them. The [specification requires a `rua` destination](https://www.rfc-editor.org/rfc/rfc9989.html) to request aggregate reporting. Ask your provider to configure a destination you can monitor if you want that feedback. ## A successful resend is only one result MailRoute says a message can fail while another from the same domain succeeds. A successful resend therefore does not resolve the intermittent behavior it reports. After a configuration change, check authentication results in received messages and continue watching returned mail. The [Hacker News discussion](https://news.ycombinator.com/item?id=50416158) includes similar administrator reports, alongside a commenter who describes trouble despite having a DMARC policy. Those accounts cannot tell us how widespread the problem is or whether every failure has the same cause. Check the returned error before assuming that missing DMARC explains it. I think this is worth checking even for a domain that sends only ordinary correspondence. Ask your provider to confirm both the applicable DMARC policy and authentication for your domain, then check delivery. DMARC establishes authorized use of a domain; the receiving service still decides what mail to accept.