Your own mail server: from 44.6% to 22.4% in ten years
In a fresh snapshot, Tranco top-1M shows that only 22.4% of domains publishing MX records accept mail on their own server. Ten years ago, there were 44.6%. Data from Artyom Berezin’s RIPE Labs study (published July 30, 2026, snapshot of July 18, 2026, source — daily DNS snapshots of the OpenINTEL project).
The figure may look like a verdict against self-hosting mail, but it’s not quite so. Below is what exactly was measured, and a symptoms glossary: if emails aren’t arriving, where to start the diagnosis.
What the data show
- On a typical day in the sample, about 659,000 domains with MX records and 618,000 with SPF.
- Google Workspace accepts mail for 21.8% of domains with MX, Microsoft 365 for 16.8%. Together 38.6%.
- The next largest named provider is Proofpoint, at 1.9%. The gap between second and third place is almost ninefold.
- DMARC records are published by 458,467 domains. But in practice only about 46.9% of them actually enforce something (
p=quarantineorp=rejectwithpct=100). - The most common DMARC record in the dataset is literally
v=DMARC1; p=none;, published by 58,064 domains. Another 32,682 domains publish the same string without a semicolon at the end.
How is a “own server” defined? The provider is determined by the primary MX record — the one with the smallest preference value — and matched to a dictionary of known providers. Everything that doesn’t match any pattern falls into the “self-hosted” bucket. This means that 22.4% includes not only true self-hosters, but also small regional hosts, corporate gateways, and anything not in the dictionary. The author also honestly reports the reverse figure: 36,455 unique MX hosts remained unidentified.
So the correct phrasing isn’t “self-hosting is dead,” but “the share of mail that two American providers accept grew to 38.6% over ten years, while everything else shrank.” For 22.4% of the 659 thousand, that’s still roughly 148 thousand domains — not that small.
Glossary: when mail doesn’t arrive
Next — by symptoms. The order roughly corresponds to how often this happens in practice.
Symptom: outgoing mail doesn’t leave at all, the connection hangs
Reason. Port 25 is closed on the host side. This is normal, not an outage: Hetzner, for example, explicitly states in its FAQ that ports 25 and 465 are blocked by default on all cloud servers. Unblock — by request due to limit, and only after a month of service and payment of the first bill. Port 587 is not blocked.
Remedy. Check whether the outbound 25 is open before configuring anything else:
# should establish a connection and receive a 220 banner
timeout 10 nc -vz gmail-smtp-in.l.google.com 25 ; echo "code: $?"
If the connection can’t be established — you don’t need to read further yet; sort out the hosting first. An alternative is to send via relay on 587, but then the reputation will be that of the relay, not your server.
Symptom: Gmail accepts, but marks as spam
Reason. Most often — incomplete authentication setup or exceeding complaint threshold. Google states the requirements explicitly: since February 1, 2024, senders of more than 5,000 emails per day to Gmail addresses must have SPF and DKIM configured, DMARC on the sending domain, a direct and reverse DNS record (PTR), TLS transmission, and unsubscribe for mailings. The DKIM key for sending to personal Gmail addresses should be at least 1024 bits. The share of spam complaints in Postmaster Tools should be below 0.3%, with an ideal working level below 0.1%.
Remedy. First verify that the domain passes checks — send a message to any header-check service and look at the lines in Authentication-Results. Then register the domain in Google Postmaster Tools: without it you won’t see your complaint share and you’re working blindly.
Many readers interpret the 5,000 emails-per-day threshold as “that doesn’t apply to me, I send twenty.” It does: the basic requirements — SPF or DKIM, PTR, TLS and RFC 5322 compliance — apply to all senders, not only bulk senders. The difference is that bulk senders have a longer list.
Symptom: Microsoft 365 and Outlook bounce or silently drop
Reason. The same class of problems plus an additional policy: in 2025 Microsoft announced new requirements for high-volume senders toward Outlook — with mandatory SPF, DKIM, and DMARC. The exact thresholds and measures changed after the announcement, so refer to the Defender for Office 365 blog, not the paraphrase.
Remedy. The practical part is the same as with Gmail, but with one extra detail: Microsoft is noticeably more sensitive to the reputation of the subnet, not only your specific address. A cheap VPS in a “dirty” range will be a problem regardless of how perfectly DKIM is set up.
Symptom: some emails reach, some don’t, patterns aren’t visible
Reason. Usually this is SPF passing for direct sends and failing on forwarding, or a mismatch between the domain in From: and what DKIM is signing (DMARC alignment failure). The latter especially tends to show up when some emails are sent through a third-party service.
Remedy. Enable DMARC reports and read them for a week. That’s exactly what rua= is for — not as a checkmark, but to see all sources sending on behalf of your domain. After that you can sensibly tighten the policy.
Symptom: DMARC is configured, reports come in, but spoofing continues
Reason. Policy p=none. This is the monitoring mode: it doesn’t prescribe anything to the receiving side. According to RIPE Labs data, the vast majority sit on this — 58,064 domains publish exactly v=DMARC1; p=none;, and overall more than half of DMARC domains publish nothing.
Remedy. Move step by step, not in one leap:
v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100
↓ after 2–4 weeks, once all sources are identified
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25
↓ gradually increasing pct to 100
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
What you must not do is set p=reject right away without looking at the reports. You’ll almost certainly forget all the systems that send mail on behalf of your domain: billing, feedback form on the site, monitoring, an old script on another server. They will all start failing at the same moment, and you’ll learn about it from people, not from logs.
Minimal set of controls you need to start
Diagram based on RIPE Labs and OpenINTEL data, Tranco top-1M snapshot as of July 18, 2026
The order of steps:
- Ensure the host allows an outgoing port 25 and configures a PTR for your domain. Without PTR the rest is meaningless.
- Raise MX and A/AAAA, verify that the PTR name, MX name, and server HELO match.
- SPF with a strict ending (
-all, not~all), after listing all sources. - DKIM with a key of at least 1024 bits, preferably 2048.
- DMARC with
p=noneand a workingrua=, and only then tighten. - MTA-STS and TLS-RPT — when everything above is running stably.
Separately, what is often considered last: the mailboxes abuse@ and postmaster@ must exist and be monitored by a real person. This isn’t RFC formalism — that’s where notifications about spam coming from your address arrive, and silence in reply can move your domain from “we’re investigating” to “blocked.”
What follows from this
RIPE Labs data do not say “do not run your mail server.” They say something else: over ten years, sender requirements have grown so much that half of domain owners preferred to outsource this work, and among those who did set up DMARC, more than half never enabled it.
If you have time to read the reports and maintain reputation, your server works. If the server is set up with a “set it up and forget it” approach, mails will start disappearing not immediately, but after a few months, and finding the moment when everything broke will be difficult.An adjacent topic, if you’re choosing a platform for such a server: onboarding a new VPS within the first hour — including how to check the reputation of the issued IP.
Who currently runs their own mail server — how much time does it take per month, and what was the most non-obvious delivery failure? And a counter-question to those who moved to Google or Microsoft: what was the last straw?