Microsoft Just Killed Self-Hosted Email for Another 200,000 People

Or: why your perfectly configured mail server is one IP reputation decision away from oblivion

You’ve done everything right. SPF record: ✅. DKIM signatures: ✅. DMARC policy: ✅. PTR record matching your hostname: ✅. You’re not on Spamhaus. You’re not on any public blocklist you can find. You’ve been running your own mail server for years without a problem.

Then, one Tuesday morning, you notice your emails to Outlook.com and Hotmail are bouncing. You dig into the logs. 550 5.7.1 Unfortunately, messages from [your IP] weren't sent. Please contact your Internet service provider. You check Microsoft’s SNDS (Smart Network Data Services) — your IP is clean. You submit a mitigation request. You wait.

The response comes back: “This IP is not eligible for mitigation.”

No explanation. No criteria. No appeal. Just: no.

That’s exactly what happened to Zen Internet in March 2026 — except at their scale, that “no” affected 200,000 customers.

What Actually Happened with Zen Internet

Zen Internet is a well-regarded UK ISP — not a spam operation, not a bulk mailer. In early March 2026, Microsoft blacklisted entire IP ranges belonging to Zen’s network. Suddenly, any email sent from a Zen IP to an Outlook or Hotmail address was silently rejected or bounced.

Zen’s postmaster team did everything by the book. They contacted Microsoft’s anti-spam support. They filed mitigation requests through the proper channels. The response was a form letter stating the IPs were “not eligible for mitigation” — and that’s where the process ended.

Microsoft didn’t explain what triggered it. They didn’t say what criteria an IP needs to meet to become “eligible” again. They just said no.

The self-hosting community has been sharing the exact same story in threads on r/selfhosted and r/homelab for months. Home users, small businesses, VPS operators — all with correctly configured servers, all hitting the same wall. Microsoft has essentially made itself into an email gatekeeper with no appeals process, and they’re not shy about it.

Why This Keeps Getting Worse

Here’s the thing: this isn’t a bug. It’s a feature. Microsoft has been quietly tightening the screws on external mail servers for years.

In 2023, they partnered with Proofpoint to handle filtering for Outlook.com. In 2024, they rolled out AI-based sender reputation scoring that works at the IP and domain level simultaneously. The result is a system that makes decisions faster and with less human oversight — which sounds great until you’re the false positive.

The new requirements Microsoft now effectively enforces (whether or not they’re documented):

  • IP reputation history — your IP needs to have a “positive sending history.” New IPs, residential IPs, and IPs in blocks that have ever sent spam (even from previous owners) are at a structural disadvantage.
  • Volume thresholds — low-volume senders look suspicious to statistical models. If you send 20 emails a day from your server, the algorithm doesn’t have enough signal to confidently classify you as legitimate.
  • Engagement signals — Microsoft pays attention to whether recipients open, reply to, and keep your messages. If you’re sending to cold addresses or people who never interact, the model downgrades your score.
  • Infrastructure similarity to spam operations — running your own Postfix/Exim on a VPS looks, from a certain angle, a lot like a spam bot. Single IP, no abuse desk, no dedicated postmaster infrastructure.

None of this is published as a clear policy. You find out when your email stops working.

The Uncomfortable Reality for Self-Hosters

Let me be honest about what this means: self-hosted email to Microsoft’s ecosystem is now genuinely fragile in a way it wasn’t five years ago.

I’ve been running my own mail server since 2019. I got through the SPF/DKIM/DMARC learning curve. I fought the PTR record battles. I eventually got things working reliably — mostly. But “mostly” is the keyword there. Because I’m one IP reputation event away from the same dead end that Zen Internet hit, and I have zero leverage if that happens.

The cold math:

  • About 40% of the world’s consumer email goes through Microsoft (Outlook, Hotmail, Live).
  • If your emails don’t reach Microsoft addresses, your mail server is not functional for nearly half the internet.
  • Microsoft’s mitigation process has a known failure mode where legitimate senders get stuck with no recourse.

If you’re running a mail server for a small business, a community project, or personal domains, you need to have a plan for this.

Your Actual Options in 2026

Instead of delivering mail directly from your server, you route it through a reputable relay with established IP reputation. Your server handles the receiving; the relay handles the sending.

Good options that work reliably with Microsoft:

  • Brevo (formerly Sendinblue) — free tier covers 300 emails/day, solid deliverability
  • Mailgun — pay-as-you-go, good API, used by enough legitimate senders to maintain reputation
  • Amazon SES — cheapest at scale, but the setup is more involved

Configuration is straightforward in Postfix:

# /etc/postfix/main.cf
relayhost = [smtp-relay.brevo.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

The trade-off: you’re trusting a third party with your outgoing mail. If you were running self-hosted mail specifically to avoid that dependency, this feels like a step backwards. It is — but it’s a working step backwards.

Option 2: Switch to Managed Mail Hosting

If you want someone else to handle deliverability headaches entirely, a few providers are worth looking at:

  • Migadu — small Swiss company, custom domains, excellent deliverability track record, honest pricing
  • Fastmail — custom domains, reliable, solid privacy stance, Australian company
  • Purelymail — the cheapest option, community-run, works well for low-volume personal use

You lose the “I control everything” aspect, but you gain reliability that’s genuinely hard to replicate solo.

Option 3: Keep the Setup, Accept the Risk

If most of your email communication is internal or goes to Gmail/Fastmail/ProtonMail users, the Microsoft problem might not actually affect you much. Worth measuring before changing anything.

Check your outbound mail logs for the last 30 days:

grep "status=sent" /var/log/mail.log | grep -oP 'to=<[^>]+>' | \
  grep -oP '@[^>]+' | sort | uniq -c | sort -rn | head -20

If Microsoft domains are a small percentage of your actual sending, the risk profile looks very different.

Option 4: Give Up on Outbound, Keep Inbound

This is underrated. Keep your own server for receiving mail (full control of your inbox, no data leaving your server), but use a relay for outbound. Best of both worlds if privacy is your main concern.

Is It Still Worth Running Your Own Mail Server?

Yes — with caveats.

Running your own mail server still makes sense if: you want control over your inbox and storage, you care about privacy, you have multiple domains to manage, or you enjoy the operational challenge (no judgment, some of us are like that).

It no longer makes sense as a “set it and forget it” thing. The maintenance surface has expanded. You need to monitor deliverability actively, not just check that the server is up. You should have a relay fallback ready before you need it. And you should accept that the Microsoft deliverability problem might never fully resolve — not because of anything you did wrong, but because the economics of email filtering favor large senders over small ones, permanently.

The self-hosting community likes to talk about email as a fully decentralized, peer-to-peer protocol where everyone can participate equally. That was true in 1998. In 2026, it’s aspirationally true. In practice, a handful of providers control enough of the inbox market that their filtering decisions are effectively policy.

Zen Internet’s 200,000 users found that out the hard way. Better to know it going in.

The Bottom Line

Microsoft’s email filtering is a black box with no meaningful appeals process. If your IP gets flagged — fairly or not — you’re at their discretion. For self-hosters, that’s not a hypothetical risk anymore; it’s a known failure mode that happens to real people running well-configured servers.

The fix isn’t a better SPF record. It’s routing your outbound mail through something Microsoft already trusts, or moving to a managed provider that handles this fight on your behalf.

Either way: stop assuming your mail server “just works” to Outlook addresses. Verify it. Today.

P.S. — My mail server is still running. Outbound goes through Brevo now. Receiving stays local. I tell myself it’s still “self-hosted email” and nobody has successfully argued otherwise.