Every year, on schedule, someone writes the obituary for self-hosted email. The argument is always the same shape: Gmail and Microsoft control the inbox, residential and small-VPS IP ranges are pre-blocked before you've sent a single message, and the only rational move is to hand your mail to a SaaS provider and get on with your life. I've heard some version of this argument every year for the last five, and every year I've kept running my own Postfix and Dovecot stack on a cheap VPS, for one domain, for myself. It still works. Mail still arrives. Nothing is on fire.
This isn't a claim that self-hosting email is easy, or that it's the right call for a company, or that the SaaS-is-inevitable crowd is wrong about the trend line. Big-provider gatekeeping over inbox placement has gotten worse over the past decade, and it will keep getting worse. But "harder than it used to be" and "impossible" are different claims, and the gap between them is where most of the panic lives. What follows is what I've actually learned running a single-user mail server for five years on hardware I don't own, on an IP address I was handed by a low-cost VPS provider, with no dedicated IP reputation service and no enterprise deliverability contract. It is not a full Postfix tutorial — there are entire books for that — but it's the set of decisions and tripwires that actually determined whether my mail landed in an inbox or vanished into the void.
Why the obituary keeps getting written
To understand why self-hosted email is still viable, it helps to understand why people keep declaring it dead, because the reasons are real, just overstated for the case that actually matters here — a single person running a single domain.
The email ecosystem in 2026 is dominated by a small number of large receiving providers: Google, Microsoft, and to a lesser extent Yahoo/AOL (now under the same corporate umbrella) and Apple's iCloud. These providers process such an enormous volume of spam, phishing, and outright criminal traffic that they've had to build increasingly aggressive, opaque, and centralized trust systems. A message from an unfamiliar sending domain with no prior sending history, arriving from an IP with no track record, on a low-cost VPS provider whose IP ranges have historically hosted spam operations, is exactly the profile of the vast majority of malicious mail these systems see all day. You are, from the receiving server's point of view, statistically indistinguishable from a spammer until you prove otherwise.
That's the real phenomenon behind "self-hosted email is dead": it's not that it's technically impossible, it's that the burden of proof has shifted entirely onto the sender, and most people evaluating whether to self-host are looking at the burden of proof, not the five-year steady state after you've cleared it. The people declaring it dead are usually one of three groups: businesses trying to send at volume without warming up a domain properly, people who set up SPF or DKIM incorrectly and gave up after their first blacklisting, or people extrapolating from running email at a scale and threat model that was never the point of self-hosting to begin with. None of those describe "one person, one domain, low and steady volume, five years."
The three things that actually matter
If you strip away everything else, there are three technical controls that do almost all of the work of establishing trust with a receiving mail server, and getting any one of them wrong will sink you regardless of how well-configured the rest of your stack is.
SPF: proving who's allowed to send
Sender Policy Framework is a DNS TXT record that tells the world which mail servers are authorized to send mail claiming to be from your domain. It exists because SMTP, as designed in the 1980s, has no concept of authentication at the envelope level — anyone can claim to be sending from any domain in the MAIL FROM command. SPF closes that gap by publishing an allow-list.
linkhub.dk. IN TXT "v=spf1 mx a:mail.linkhub.dk -all"
The most common way people break this isn't omitting SPF, it's getting the failure mode wrong. The record ends in either -all (hard fail — receiving servers should reject mail from unlisted sources), ~all (soft fail — accept but mark as suspicious), or ?all (neutral — essentially meaningless). A lot of guides recommend starting with ~all "to be safe," and that's reasonable advice for the first few weeks of a new domain, but if you never tighten it to -all you're leaving the door open for anyone to spoof your domain with mail that receiving servers will still consider plausible. After five years of stable sending, there's no reason to still be on a soft fail.
The other common mistake is publishing two SPF records instead of merging them into one, which causes a permanent SPF PermError on every validation check — a subtle failure that doesn't show up until you actually inspect the raw headers of a delivered (or non-delivered) message.
DKIM: proving the message wasn't tampered with
DomainKeys Identified Mail signs your outgoing mail with a private key, and publishes the corresponding public key in DNS. The receiving server checks the signature against the body and a specific set of headers; if anything was altered in transit, or if the signature doesn't validate against your published key, the check fails. This does two things: it proves the message came from someone holding your private key (i.e., your mail server), and it proves the message content is unmodified.
selector1._domainkey.linkhub.dk. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Two practical notes from five years of running this. First, use a 2048-bit key, not 1024-bit — 1024-bit DKIM keys are considered weak by modern standards and some providers are starting to distrust them outright; the extra DNS record size is a non-issue. Second, rotate your selector occasionally (the selector1 portion of the record name) — it costs nothing, and it means a leaked private key from years ago is no longer useful even if it somehow surfaces.
DKIM failures are usually self-inflicted: a mailing list or forwarding service that rewrites the body or subject line before relaying your message will break the signature, because DKIM signs exact byte content. This is one of the genuine, unavoidable frictions of self-hosted email in 2026 — some mailing list software still doesn't handle DKIM-aware forwarding gracefully, and there's nothing on your end that fixes it.
rDNS: proving your server is who it says it is
Reverse DNS, or the PTR record, is the one people skip most often, usually because their VPS provider buries it three menus deep in a control panel, or requires a support ticket instead of a self-service DNS UI. Your mail server announces itself in the SMTP handshake with a HELO/EHLO hostname — for example, mail.linkhub.dk. The receiving server then does a reverse lookup on your connecting IP address and checks whether it resolves back to a hostname that's consistent with what you claimed. If your IP's PTR record resolves to something like 203-0-113-42.cheapvps-pool.net instead of anything resembling your mail domain, that mismatch alone is enough for a meaningful fraction of receiving servers to reject or heavily downgrade your mail, no matter how clean your SPF and DKIM are.
This is genuinely the single highest-leverage, lowest-effort fix available to anyone self-hosting on a VPS, and it's also the one most commonly skipped, because unlike SPF and DKIM — which you control entirely through your own DNS zone — the PTR record lives in IP space controlled by your hosting provider, and setting it requires going through them. If a VPS provider makes this difficult or impossible, that alone is a reason to not host mail with them, regardless of price.
What I deliberately don't have: DMARC
I don't publish a DMARC record, and I want to be upfront that this is a considered choice rather than an oversight, because it's the kind of omission that draws immediate "well actually" responses from anyone who's set up email deliverability professionally.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of SPF and DKIM. It does two things: it tells receiving servers what to do with mail that fails SPF/DKIM alignment for your domain (p=none for monitor-only, p=quarantine to send it to spam, p=reject to refuse it outright), and it gives you aggregate XML reports from participating receivers about mail claiming to be from your domain across the internet — which is primarily useful for detecting spoofing and phishing campaigns using your domain's name.
_dmarc.linkhub.dk. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@linkhub.dk"
For a single-user personal domain, the actual threat DMARC defends against — someone spoofing your domain to phish your customers, employees, or the general public at meaningful volume — mostly doesn't apply. Nobody is running a phishing campaign impersonating a personal blog's mail domain, because there's no brand value or trust relationship to exploit. The aggregate reports would tell me about occasional automated backscatter and misconfigured servers accidentally including my domain, not anything actionable.
That calculus changes immediately if you're running email for a business, a domain with any public trust relationship, or multiple users — anywhere a spoofed message in your name could plausibly deceive someone into acting on it. In those cases, DMARC at p=quarantine or p=reject is not optional; it's one of the few controls that meaningfully reduces the risk of your domain being used in a phishing campaign against your own contacts. But for personal use, it's a genuine case of a control that exists to solve a problem you don't have, and adding it purely for completeness is exactly the kind of unnecessary complexity that makes self-hosting feel harder than it is.
The part that actually determines your fate: IP reputation
SPF, DKIM, and rDNS are necessary. They are not sufficient. The single largest variable in whether your mail lands in an inbox or a spam folder — bigger than any of your Postfix configuration — is the reputation of the IP address you're sending from, and that reputation is inherited, not configured.
Cheap VPS providers make their margins by packing customers densely and recycling IP address blocks constantly. The IP you're assigned today may have belonged to a spam operation eighteen months ago, and some receiving networks maintain long institutional memory about entire ranges, not just individual addresses. Some blocks are listed on Spamhaus's Policy Block List or similar reputation lists before you've configured anything at all, purely because of the class of provider they belong to.
Before committing to any provider for a mail server — and ideally before committing to them for anything, since a provider that doesn't care about this probably doesn't care about abuse handling in general — check the actual IP you've been assigned against the major blocklists:
- Spamhaus ZEN (covers SBL, XBL, and PBL in one query)
- Spamcop
- Barracuda Reputation
- A general aggregator like MXToolbox's blacklist check, which queries dozens of lists at once
If the IP is already listed, ask for a different one before spending a weekend configuring Postfix on infrastructure that was never going to work regardless of configuration quality. This single check, done before any other setup step, would have saved a large fraction of the "I tried self-hosting and it was blacklisted immediately" stories that fuel the self-hosting-is-dead narrative — most of them never checked what they were building on.
Once you're on a clean IP, reputation is something you build passively over time simply by sending legitimate mail consistently and never spiking volume unpredictably. Five years of low-volume, consistent, non-spammy traffic from the same IP is itself a reputation asset that can't be shortcut or purchased — it's the actual mechanism behind why self-hosting personal email tends to get easier the longer you do it, not harder. New self-hosters are comparing their first week against my fifth year, which is not a fair comparison and not evidence that the underlying approach doesn't work.
Microsoft, not Gmail, is the real adversary
Every self-hosting guide spends most of its deliverability advice on Gmail, because Gmail is the largest consumer mail provider and because Google exposes reasonably good tooling — Google Postmaster Tools gives you a direct reputation score, spam-rate feedback, and authentication success rates for your domain, all in one dashboard. Gmail's filtering is aggressive, but it's legible: you can usually tell what's wrong and watch it improve.
Microsoft (Outlook.com, Hotmail legacy addresses, and Microsoft 365 tenants) is a different animal entirely, and in my experience it is the actual adversary for anyone self-hosting personal email in 2026. Mail to Microsoft-hosted addresses doesn't bounce when it's rejected — it simply disappears. No NDR, no spam-folder placement, nothing in your logs beyond a "250 OK" from their edge server that gives no indication the message was silently dropped somewhere in their filtering pipeline afterward. The only way to know it happened is that the recipient tells you they never got anything.
Microsoft does provide two tools for senders trying to fix this — Smart Network Data Services (SNDS) for reputation data on your sending IP, and the Junk Mail Reporting Program (JMRP) for feedback loops — but both are built around the assumptions of a bulk sender or ISP, not a hobbyist running one domain. Getting meaningful signal out of them as an individual is slow and often unproductive. In practice, the only reliable test is empirical: send real test messages to an outlook.com or Microsoft 365 address periodically and confirm they arrive, because nothing else will tell you.
Yahoo/AOL and Apple's iCloud sit in between — both have gotten measurably stricter about authentication requirements in recent years (both now effectively require DMARC alignment for any meaningful sending volume, part of a broader industry shift following Google and Yahoo's 2024 bulk-sender authentication requirements), but for low-volume personal mail from an authenticated, reputable IP, neither has been a persistent problem in my experience the way Microsoft has.
What's actually in the stack
For a personal, single-domain mail server, I've deliberately kept the stack lean. It's tempting, especially after reading enough deliverability horror stories, to build a defense-in-depth pipeline with content scoring, Bayesian filters, and reputation management dashboards. Almost none of that is warranted at this scale, and the complexity itself becomes a maintenance liability — a spam filter you don't understand well enough to debug is worse than no spam filter, because you'll blame the wrong layer when something breaks.
The base: Postfix and Dovecot
Postfix handles SMTP — accepting inbound mail and relaying outbound mail. Dovecot handles IMAP — letting mail clients actually retrieve and read stored mail. This split is standard and hasn't meaningfully changed in the years I've run it; both projects are mature, well-documented, and conservative about breaking changes, which matters enormously for something you intend to run with minimal intervention for years at a time.
TLS, enforced, not opportunistic
Every connection, inbound and outbound, uses TLS via a Let's Encrypt certificate with an automated renewal hook restarting Postfix and Dovecot on renewal. I don't allow plaintext SMTP AUTH or plaintext IMAP under any circumstance — this is a one-time config decision that closes off an entire category of credential-theft risk for essentially zero ongoing cost.
smtpd_tls_security_level = encrypt smtp_tls_security_level = may smtpd_tls_auth_only = yes
Note the asymmetry: I enforce TLS for inbound connections to my server (encrypt) but only prefer it opportunistically for outbound connections to other servers (may) — mandating TLS for every server I send to would mean silently failing to deliver to the (shrinking, but nonzero) set of receiving servers that still don't support it, and I've decided that failed delivery is worse than the marginal security cost of opportunistic encryption on outbound legs to servers I don't control.
MTA-STS and TLS-RPT, the newer layer
These weren't part of my original setup five years ago but are worth calling out for anyone setting up fresh in 2026: MTA-STS (Mail Transfer Agent Strict Transport Security) lets you publish a policy declaring that mail to your domain must be delivered over TLS with a valid certificate, closing a downgrade-attack vector that opportunistic TLS alone leaves open. TLS-RPT gives you reports when other servers fail to establish TLS to yours. Neither is strictly necessary for a personal domain's deliverability, but both are cheap to add now and represent where the ecosystem is quietly moving — treat them as a small investment against tightening requirements later rather than an urgent fix.
Greylisting: unglamorous and still effective
Greylisting temporarily rejects mail from senders your server hasn't seen before, with a "try again later" SMTP response, and only accepts it on a retry after a delay. Legitimate mail servers retry automatically per the SMTP spec; a large fraction of unsophisticated spam-sending infrastructure doesn't bother, either because it's optimized for blasting volume across many targets rather than reliably delivering to any one of them, or because it's not RFC-compliant to begin with. This single, boring technique — running via Postgrey in front of Postfix — has quietly filtered out more junk for me over five years than any content-based scoring system would have, for a fraction of the operational complexity.
The one cost is a delivery delay of a few minutes for first-time senders, which is a non-issue for personal mail and would be a real consideration for anything time-sensitive or business-critical.
Fail2ban and rate limiting
Any internet-facing SMTP AUTH or IMAP endpoint will be probed constantly for weak credentials. Fail2ban watching the Postfix and Dovecot auth logs, banning IPs after a handful of failed attempts, handles the overwhelming majority of this automatically. Combined with a strong, randomly generated password (not a passphrase you've reused anywhere else) and TLS-only auth, brute-force credential attacks against a personal mail server are a solved problem, not an ongoing risk requiring active attention.
Monitoring and testing: knowing when it's broken
The scariest failure mode in self-hosted email isn't a loud one — it's the silent one, where mail simply stops arriving at one specific provider and you don't find out until someone mentions three weeks later that they never got your message. A few habits close most of that gap:
- Periodic test sends to a Gmail and an Outlook/Microsoft 365 address, checking the raw headers (not just "did it arrive") for spam scoring and authentication results.
- mail-tester.com or similar for an occasional independent score covering SPF/DKIM alignment, blacklist status, and content heuristics in one pass.
- MXToolbox blacklist monitoring run on a schedule rather than only when something already seems wrong — catching a fresh listing within a day is far easier to remediate than one that's been sitting for weeks.
- Mail queue monitoring — a growing Postfix deferred queue is usually the earliest signal that a specific destination has started silently rejecting or throttling you, well before a human notices.
None of this requires dashboards or alerting infrastructure at personal scale — a monthly manual check has been sufficient for five years — but it does require actually doing it, rather than assuming silence means success.
Pitfalls that actually bite
A few specific failure modes are worth naming directly, because they're common enough to account for a large share of "self-hosting doesn't work" reports, and every one of them is avoidable.
Port 25 blocked outbound. Many budget VPS providers block outbound port 25 by default, precisely because it's the most abused port for spam operations run on rented compute. This isn't a mail server misconfiguration at all — it's the hosting provider silently preventing you from sending anything, and it usually requires a manual support ticket (sometimes with justification) to unblock. Check this before anything else when setting up on a new provider.
Accidental open relay. A misconfigured Postfix instance that relays mail for anyone, not just your authenticated users or your own domain, will be discovered and abused by spam operations within hours, and will get your IP blacklisted almost immediately — deservedly. This is a base Postfix configuration concern (smtpd_relay_restrictions), not an edge case, and it's worth explicitly testing from an external host after any configuration change, not just trusting the config file.
rDNS/HELO mismatch after IP changes. If your VPS provider ever reassigns your IP (migration, hardware failure, plan change), and you update DNS but forget to have them update the PTR record — or vice versa — you're back to the exact mismatch problem described earlier, and it can take days to notice, because it degrades deliverability rather than breaking it outright.
Treating a blacklisting as permanent. A first-time, low-volume domain occasionally lands on an automated blocklist through no fault of its own — a shared IP briefly compromised before you had it, an overzealous heuristic list, a stale entry from a previous tenant. Nearly all reputable blocklists have a delisting request process, and it typically works within a day or two once you've fixed the underlying cause (or confirmed there wasn't one). Panic-migrating providers at the first listing is usually a wasted, higher-cost overreaction to a routine, correctable event.
The economics, and the actual point
None of this is meaningfully cheaper than paying for hosted email. A cheap VPS runs a few dollars a month, comparable to or more than budget options like a basic Fastmail plan, and that ignores the time cost of initial setup and occasional maintenance. If cost were the only consideration, self-hosting personal email would be a mediocre argument.
The actual case is the same one behind everything else on this site under the "digital sovereignty" banner: control. My mail isn't subject to a SaaS provider's terms-of-service changes, account suspension without appeal, or silent policy shifts about what content or behavior is acceptable. I hold the private keys, the mail spool, and the full audit trail, on infrastructure I chose and can move at will. That's not a claim that everyone should do this — for most people, most of the time, a reputable hosted provider is the correct trade-off between convenience and control. It's a claim that the trade-off is a real choice, not a foregone conclusion, and "you'll get blacklisted immediately" isn't a technically accurate reason to skip evaluating it.
Backups and disaster recovery for a mail server you actually depend on
It's worth being honest about a risk that has nothing to do with deliverability: unlike a SaaS inbox, if your VPS disk fails, your provider has an outage, or you fat-finger a destructive command at 1am, there's no support ticket that gets your mail back. You are the entire recovery plan. Five years without a serious incident doesn't mean the risk isn't there — it means I haven't been tested yet, and I try to configure around that assumption rather than around my own track record.
In practice, that means three things running independently of the mail server itself. First, nightly backups of the Dovecot mail store (Maildir format, so it's just files, not a proprietary database dump) to a separate host, not just a separate disk on the same VPS — a provider-level failure that takes the VPS down shouldn't also take down the backup. Second, the same for the Postfix and Dovecot configuration itself, plus the DKIM private key and TLS certificates, all of which are individually small but collectively annoying to lose and reconstruct — regenerating a DKIM key means republishing DNS and waiting out propagation, which is a bad time to discover you don't have the old one and every message signed under it is now unverifiable. Third, and most often skipped: actually testing a restore periodically, not just confirming the backup job exits with status zero. An untested backup is a belief, not a plan, and mail is exactly the kind of data where you don't discover a corrupted or incomplete backup until the day you need it.
The other side of disaster recovery is DNS itself. Your SPF, DKIM, rDNS, and MX records are the actual root of trust for everything described above, and they typically live with a registrar or DNS provider entirely separate from your mail VPS. Losing access to that account, or having a registrar have its own outage at the wrong moment, is arguably a bigger single point of failure than the mail server itself, since it can take down inbound delivery, outbound authentication, and your ability to fix either, simultaneously. Use a registrar account with its own strong, unique credentials and two-factor authentication, and keep an offline copy of your zone file — restoring a mail server from backup is a bad day; reconstructing a DNS zone from memory afterward is a worse one.
A few questions I've actually been asked about this setup
Do you run your own spam filtering, or just rely on greylisting and authentication? Just those, plus Dovecot's basic sieve rules for personal organization. I looked at running Rspamd at one point and decided against it — for one mailbox, the false-positive risk of a statistical filter I'd tuned myself was higher than the nuisance of the occasional piece of spam that gets through greylisting and authentication checks. I'd make a different call running mail for multiple people.
What happens when you're travelling and sending from a different network? Nothing changes on the sending side — outbound mail still goes through my own server via authenticated SMTP over TLS from whatever client I'm using, so the receiving server sees the same IP and reputation regardless of where I physically am. The one thing worth watching is some hotel and airport networks block outbound SMTP ports entirely; running on the standard submission port (587) rather than 25 for client submission avoids most of that.
Have you ever considered just using a small paid provider instead, like Fastmail or Migadu, to get the sovereignty benefits without running the server yourself? This is a genuinely reasonable middle ground, and I don't think self-hosting is obviously superior to it — a small, values-aligned paid provider gets you out from under the big-platform gatekeeping concern without taking on the operational burden described in this post. The reason I still run my own is mostly that I already have the Linux administration habit from everything else documented on this site, so the marginal cost for me specifically is low. For someone without that existing skill set and interest, a provider like that is probably the better trade-off, and I wouldn't try to talk anyone out of it.
What would make you stop self-hosting? Realistically, either of two things: a receiving provider making authentication requirements that are simply unachievable for an individual sender rather than merely inconvenient — for instance, requiring a dedicated IP allocation tied to a corporate sending-domain registration process with no individual path — or my own VPS provider becoming unreliable enough that the operational burden stops being worth it. Neither has happened in five years, but both are the kind of structural shift worth watching, distinct from the routine "you'll get blacklisted" warnings that haven't materialized.
Where this goes next
The trend lines are real: authentication requirements have tightened meaningfully since Google and Yahoo's 2024 bulk-sender rules, and I'd expect DMARC-adjacent requirements to keep creeping toward becoming a de facto requirement even for smaller senders over the next few years, alongside continued growth of MTA-STS adoption among receiving servers. None of that changes the conclusion for personal-scale self-hosting — it just means the baseline configuration effort five years from now will look a little more like what large commercial senders already do today. That's a manageable, incremental cost, not a cliff.
What won't change is the core mechanism: authenticate properly, land on a clean IP, send consistently, and don't skip the boring parts. Five years in, on a cheap VPS, for one person, that's still been enough.