Outlook Is Bouncing Mail Without DMARC. Fix It Before Launch.

Picture launch day. Forty beta users sign up, your welcome email fires, and nothing shows up in half of their inboxes. No error on your dashboard. No angry tweet. Just silence.

That's the kind of quiet failure founders have been reporting this week. Since about November 5, 2026, Outlook.com has reportedly been bouncing some mail from domains with no DMARC record. Microsoft hasn't announced the change, per the write-ups below. The fix takes about ten minutes, so let's walk through it.

Outlook.com started rejecting some mail from domains that publish no DMARC record, and small senders are included. MailRoute's post, dated November 6, says the rejections hit outlook.com, hotmail.com, live.com and msn.com addresses. A second write-up from dmarcdkim.com, dated November 7, describes the same pattern.

Here's why it surprised people. Microsoft's published rule, in place since May 2025, applies to domains sending more than 5,000 messages a day. A founder with 200 users figured that rule wasn't about them. Apparently it now is, at least some of the time.

One admin quoted by dmarcdkim.com saw about half of their clients' mail bounce. Others saw far less. That inconsistency is the dangerous part. A test email to your own Hotmail account might sail through while a real customer's password reset bounces.

It's a permanent error: 550 5.7.1, with text saying the message lacks SPF, DKIM or DMARC authentication records. Later bounces add a tag, AS9031519. The very first ones didn't, so search your logs for the phrase "Message lacks SPF/DKIM/DMARC" instead of one exact string.

A 550 is a hard failure. Your sending service won't retry it on its own. So every welcome email, invoice or reset link that bounced since November 5 is simply gone until you resend it.

Don't confuse this with 5.7.515. That older code belongs to the high-volume rule. And ignore a misleading "5.7.23 SPF validation error" headline if you see one. The write-ups say SPF passes in those cases and the missing DMARC record is the real cause.

Because email is how your first customers find out you exist. Signup confirmations, receipts, onboarding nudges, investor updates. A big slice of any early list uses Outlook, Hotmail or Live addresses, especially outside the tech bubble.

I've watched founders spend weeks on a landing page and zero minutes on DNS. It's an easy trap. DNS feels like plumbing, and plumbing doesn't ship features. But a bounced onboarding email can look exactly like a user who lost interest, and you'd read that as a product problem.

There's also a trust angle. If you cold email prospects or investors from a fresh domain, a missing authentication record is one more reason a message lands in junk or never arrives. Fixing it costs nothing.

Look up the DMARC record for the domain in your From address. On a Mac or Linux terminal, the command is dig +short TXT _dmarc.yourdomain.com. On Windows, use nslookup with the TXT type. Empty output means no record, which means you're exposed.

Three more quick checks from the DEV Community guide:

• Confirm there's exactly one SPF record on the root domain (it starts with v=spf1). Two records cause an error.
• Find your DKIM selector in the DKIM-Signature header of a sent message, then confirm the record exists.
• Send a real message to a Gmail account, choose "Show original" and look for dmarc=pass.

Subdomains without their own record fall back to the main domain's record, so one record at the root usually covers them.

Start with a monitoring-only policy. At your DNS host (not inside Microsoft 365), add a TXT record named _dmarc with a value like: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. The p=none part tells receivers to report on failures but not to block anything, so it doesn't change how other providers treat your mail.

Keep only one DMARC record. Two make the policy invalid, per dmarcdkim.com. If one exists already, edit it.

Lower your DNS TTL before you change anything, so mistakes fix themselves quickly. And if you use Cloudflare, set DKIM and return-path CNAMEs to DNS-only rather than proxied, or they won't resolve properly.

Then resend the bounced mail. Password resets and invoices first.

DMARC passes only when SPF or DKIM aligns with the domain in your From address. Publishing the record while your sending service signs with its own domain gets you a record that exists but a check that fails.

The DEV Community guide lists the common traps by sender:

• Postmark needs a custom Return-Path CNAME, or SPF won't align.
• Amazon SES needs Easy DKIM (three CNAMEs) and a custom MAIL FROM subdomain.
• SendGrid needs real domain authentication. Single Sender Verification doesn't count.
• Microsoft 365 signs with an onmicrosoft.com domain until you enable DKIM for your own domain.

One more oddity: if Microsoft 365 headers show dmarc=bestguesspass, that means no DMARC record exists. Treat it as a fail.

Treat it like any launch task: write it down, assign it, check it off. You can track this in a spreadsheet, Notion, or a planning tool like Foundra that helps first-time founders lay out launch steps in order. The tool matters less than having a named owner and a date.

A sensible sequence looks like this. Week one: publish p=none, verify alignment for every service that sends as your domain (the app, the newsletter tool, the support desk, your own inbox). Weeks two to four: read the aggregate reports that land at your rua address and fix anything that fails. After that, consider tightening the policy.

Make a list of every tool that sends email as you. Founders always forget at least one. The billing system. The scheduling link. The survey tool someone connected in March.

Once the reports show your legitimate mail passing, step up gradually. The usual path in the guides is p=quarantine at a small percentage (say 25%), then 100%, then p=reject if you want full enforcement. Rejecting means receivers will refuse mail that fails, including mail that someone forges in your name.

Is that worth doing? For most early startups, yes, eventually. Forged mail from your domain is a real risk once you have customers who trust your brand. But don't rush. A mistaken reject policy can block your own invoices, which is a much worse Tuesday than the one you're trying to avoid.

MailRoute also points out it's a vendor selling its own service, so read its product claims with that in mind. The DNS advice itself matches what independent write-ups say.

• Reports from MailRoute and dmarcdkim.com say Outlook.com began rejecting some mail from domains with no DMARC record around November 5, 2026.
• The bounce is 550 5.7.1, a permanent failure that won't retry by itself.
• Low-volume senders are affected, even though Microsoft's published rule covers only 5,000+ messages a day.
• Check with dig +short TXT _dmarc.yourdomain.com. Empty output means you need a record.
• Publish v=DMARC1; p=none with a reporting address, then confirm SPF or DKIM aligns with your From domain.
• Resend anything that bounced since November 5.
• Review reports for a few weeks before tightening your policy.

Did Microsoft announce this change? Not according to the write-ups cited here. MailRoute said there was no announcement as of November 6, 2026, so treat the reports as community findings.

Do I need DMARC if I send only a few emails a day? Based on current reports, yes, at least for reaching Outlook.com addresses. Low-volume senders are seeing bounces too.

Will p=none hurt my deliverability elsewhere? No. It asks receivers to report failures, not to block mail, so it doesn't change how other providers treat your messages.

Is SPF plus DKIM enough? Reports say no. The rejection happens when no DMARC record exists, even if SPF and DKIM pass.

How do I know if my customers are affected? Search your sending service's bounce logs for "Message lacks SPF/DKIM/DMARC" from the past week and compare against Outlook, Hotmail, Live and MSN addresses.

Do I need a developer to fix this? Usually not. It's a DNS edit at your domain registrar or DNS host, plus enabling domain authentication in your email sending tool.

1. Outlook.com Is Quietly Rejecting Email From Domains Without DMARC, MailRoute, November 6, 2026
2. Outlook Rejecting Emails Without DMARC? SPF and DKIM Are Not Enough, DEV Community
3. Outlook: Message lacks SPF/DKIM/DMARC Auth Records, dmarcdkim.com, November 7, 2026
4. Strengthening the email ecosystem: Outlook new requirements for high-volume senders, Microsoft Tech Community