Self-host a mail server on a VPS.
Mailcow, Mail-in-a-Box, iRedMail — and the host that lets you.
Self-hosted email is harder than it should be in 2026, and almost all the difficulty sits in three places — port 25 blocked at most hosts, fresh-IP reputation, DNS records that must align perfectly. This guide names the prerequisites, compares the three serious stacks, and walks the deliverability path.
- 01
Three brick walls before any install: outbound port 25 must be open, the IP needs a clean reputation history, and the PTR record must match the HELO hostname. Without all three, no software stack will deliver mail to Gmail.
- 02
The host matters more than the software. NordBastion VPS opens port 25 by default and sets PTR records from the panel within an hour — the no-KYC posture means there is no identity-verification step.
- 03
Pick the stack to your operating taste: Mail-in-a-Box (script, 2 GB, default), Mailcow (Docker, 6 GB, modern UI), iRedMail (flexible, manual, ops-hand).
Three brick walls. Hit any of them and the rest of the guide is wasted.
The reason "just install a mail server" is bad advice is that the install is the easy 10% of the problem. The other 90% is infrastructure-level prerequisites that the software cannot do for you. Confirm all three are met before installing anything.
Wall 1 — outbound port 25. SMTP delivery is TCP/25 from your server to the recipient's mail exchange. Most hyperscalers and budget VPS providers block this outbound by default at the hypervisor level to limit spam. Test it first: nc -zv smtp.gmail.com 25 — if the connection times out, your host blocks port 25 and no mail will ever leave. Open a ticket asking for unblock, or move to a host that does not block it.
Wall 2 — IP reputation. Check the IP against Spamhaus, SORBS, Barracuda and Cisco Talos (mxtoolbox.com/blacklists.aspx). If it appears on any list, the IP has prior history; deliverability will be poor until you delist or move. Fresh IPs without prior history are fine — they start in the "neutral / unknown sender" bucket which is the right starting point.
Wall 3 — PTR record alignment. The PTR (reverse DNS) for your VPS IP must match the HELO hostname your Postfix announces. If your server announces "mail.example.com" but the PTR for the IP says "static-12-34-56-78.example-host.net", Gmail will defer or reject. The PTR is set by the VPS provider on the IP, not by you on your domain. Most providers expose a panel control for this; some require a support ticket. NordBastion exposes it from the panel.
Pass all three, and you are clear to install. Fail any one of them, fix it first.
Why most hosts block port 25. And the no-KYC angle.
Outbound SMTP is the spammer's favourite. A compromised VPS with port 25 open can pump 100,000 messages a day before anyone notices, and the abuse complaints all land in the host's inbox. To keep that under control, most VPS providers either block port 25 outbound at the network edge, or require an identity-verification + acceptable-use sign-off before unblocking it on a per-customer basis.
That model breaks for a privacy-first host. The whole proposition of a no-KYC VPS is that customers do not have to identify themselves. Adding a "but for port 25 you do" step would be a doctrinal contradiction. So the privacy-host industry splits into two camps: hosts that refuse port 25 entirely (rules out self-hosted mail), and hosts that open it for everyone without an identity check (the rarer, more interesting category).
NordBastion is in the second camp. Every <a href="/vps/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">VPS we ship</a> has outbound TCP/25 open from the moment it boots. There is no identity verification, no acceptable-use sign-off, no manual unblock ticket. Abuse is monitored on outbound traffic patterns rather than customer identity — a VPS that suddenly emits 10× its baseline volume gets flagged, regardless of who owns the account. The trade-off works because the spam-traps live at the protocol layer, not the identity layer.
The practical implication: NordBastion + a clean fresh IP + a panel-set PTR record is the three-wall checklist passing in under an hour. The rest of the guide is the actual install.
The three stacks compared. Mailcow vs Mail-in-a-Box vs iRedMail.
Mail-in-a-Box. A single shell script that turns a fresh Ubuntu 22.04 install into a complete mail server — Postfix, Dovecot, Roundcube webmail, Nextcloud-equivalent contacts/calendar, SpamAssassin, DNS guidance. Defaults are sensible, the admin UI is minimal, the resource footprint is 2 GB RAM comfortably. Best fit for someone who wants the result without learning Docker. Updates land on the cadence of the upstream project, typically two or three a year.
Mailcow. A Docker Compose-based stack — Postfix, Dovecot, Rspamd, ClamAV, SOGo, Nginx, MariaDB, Redis, Solr — with a polished web admin (2FA, ActiveSync, calendars, address books, mailbox quotas). Needs 6 GB of RAM as a practical baseline; comfortable on 8. Best fit for someone who wants a modern, modular setup with first-class spam filtering and ActiveSync for mobile. Released continuously; the moby docker-compose.yml ships from the project repo.
iRedMail. The traditional choice — a shell script that installs the classic Postfix + Dovecot + Amavisd-new + ClamAV stack on top of Debian / Ubuntu / CentOS. The admin UI (iRedAdmin) is functional rather than pretty. Best fit for the operator who already has opinions about each component and wants direct config-file control. The Pro edition adds a richer admin; the open-source edition is fully usable.
What they all share. All three produce a fully functional mail server with SMTP / IMAP / submission / DKIM / SpamAssassin or Rspamd / webmail. All three rely on the same protocol-level deliverability mechanisms (SPF / DKIM / DMARC / PTR). All three need the same monthly maintenance. The choice is about ergonomics, not about whether mail will work.
The DNS records. All five, perfectly, or nothing.
Modern mail deliverability is gated on five DNS records. Get all five right, you land in the inbox at Gmail and Outlook. Miss one or get one half-right, you land in spam — or worse, get silently dropped at the SMTP layer with no bounce.
1. MX. example.com. MX 10 mail.example.com. — tells the world where to deliver mail for the domain.
2. A. mail.example.com. A 1.2.3.4 — the IP of your mail VPS.
3. PTR (reverse). 4.3.2.1.in-addr.arpa. PTR mail.example.com. — set on the IP at the VPS provider. Must match the HELO. NordBastion: set this from the panel within the hour the VPS provisions.
4. SPF. example.com. TXT "v=spf1 mx -all" — declares that only the MX hosts may send mail for the domain. The -all (hard fail) is correct when self-hosting; ~all (soft fail) is the older permissive form to avoid.
5. DKIM. default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=<long-key-from-mailcow-admin>" — the public key the receiver uses to verify the DKIM signature your server adds to every outbound message. The private key stays in the mail server; the public half goes in DNS.
6. DMARC. _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]" — tells receivers what to do with messages that fail SPF/DKIM (reject), and where to send aggregate reports. Start with p=none for the first week to monitor, then move to p=reject.
Verify the whole stack with mxtoolbox.com Email Health Check after every change. Green across the board is the only acceptable state.
Deliverability. Gmail, Outlook, the warm-up.
A fresh IP, even with perfect DNS, starts in the "neutral sender" bucket at Gmail and Outlook. The first month is a reputation-building exercise. The goal is to look exactly like a small legitimate sender: low volume, steady cadence, perfect authentication, recipients who open and reply.
Week 1. Send mail only to your own external accounts (Gmail, Outlook, Yahoo, Proton). Read each message in the recipient inbox, mark "Not spam" if it lands in spam, reply. The reply is the reputation signal that matters most. Volume: 5–20 messages a day.
Weeks 2–4. Add a handful of correspondents who reply naturally. Subscribe to one or two mailing lists that send to your new address (technical announcements, project newsletters); engagement on inbound from established senders helps your outbound. Volume: 50–200 a day.
Months 2–3. At this point the IP has a track record. Migrate inbound from your old provider via SMTP forwarding so the new address starts receiving real traffic. Continue to monitor DNSBL listings monthly. By month three, deliverability is roughly indistinguishable from a hosted provider.
What kills the warm-up. Bulk outbound on day one. Sending to a stale contact list with dead addresses (Gmail counts bounces as a strong negative). Newsletter campaigns. Any of these in week 1 sets the IP back weeks. The discipline is patience, not technique.
Maintenance. An hour a month, or it breaks.
A self-hosted mail server is not "set and forget" — the email ecosystem moves continuously, and the cost of falling behind is silent deliverability degradation that you only notice when a friend says "I never got your email." The monthly maintenance routine is small but non-negotiable.
Monthly checklist. (1) DNSBL check — mxtoolbox blacklist scan, delist if listed. (2) Certificate renewal verification — Let's Encrypt should auto-renew but verify. (3) Updater run — Mailcow update.sh or MIAB upgrade or apt upgrade on iRedMail. (4) Log scan — Rspamd / Postfix for unusual rejection rates. (5) Backup verification — restore the latest backup to a scratch directory and confirm the mail spool decompresses cleanly.
Quarterly. Full backup restore drill to a second VPS, verify webmail login works. Review SpamAssassin / Rspamd rules — bayes scores drift, retrain on recent ham/spam. Check the DMARC aggregate reports for unauthorised use of the domain.
On a major version landing. Snapshot the VPS first (NordBastion panel: one click). Take a fresh database backup off-server. Run the upgrade. Verify SMTP send, IMAP retrieve, webmail login, mobile sync, every account on the server. Roll back via snapshot if anything fails. Time: 30–60 minutes once or twice a year.
The breaking point. People abandon self-hosted mail when they skip three months of updates, then a major DSA / DMARC change lands, then deliverability silently degrades, then a friend tells them mail is bouncing. Build the monthly hour into the calendar from day one and the breaking point never arrives.
Questions, answered.
Eight questions that come up when starting and running a self-hosted email server in 2026.
Is it still realistic to self-host email in 2026?
Yes — but only if you understand the three structural problems and accept the operational cost. Problem one: port 25 outbound is blocked by default at most VPS providers and unblocking it requires sales-team conversation. Problem two: fresh IP space has a "cold" deliverability reputation that takes weeks to warm up against Gmail and Outlook. Problem three: the once-a-month maintenance cycle (DNSBL checks, TLS renewal, blocklist removal) is non-negotiable. With those handled, self-hosted email is healthier in 2026 than it was in 2020.
Which stack should I pick — Mailcow, Mail-in-a-Box or iRedMail?
Mail-in-a-Box for the "I want this to work" reader. One install script, sensible defaults, runs on 2 GB. Mailcow for the "I want a modern admin UI and Docker" reader; needs 6 GB, gives you Rspamd, ActiveSync, SOGo and a polished web admin. iRedMail for the "I have a specific stack I want" reader; very flexible, very manual, the old hand's choice. All three produce a fully functional mail server; the choice is about the ergonomics, not the result.
Why is port 25 blocked at most VPS providers?
Because spammers abuse it. Hyperscalers and budget VPS providers block outbound TCP/25 at the hypervisor or firewall by default to keep abuse complaints down — unblocking it requires opening a support ticket, identity verification, and an "AUP for email" sign-off. Privacy-first hosts that refuse the identity verification cannot offer the unblock; mainstream hosts that offer the unblock require KYC. The combination "no-KYC AND port 25 unblocked" is rare and is the reason this guide is on this site at all.
Does NordBastion unblock outbound SMTP for mail-server customers?
Yes — outbound port 25 is open on every NordBastion VPS without a support-ticket request. We do not run an identity-verification step before allowing SMTP, because the no-KYC posture is the doctrine; outbound abuse is monitored on traffic patterns, not on customer identity. This is the differentiator that makes a self-hosted mail server actually possible on a privacy host.
What is a PTR record and why does my mail keep getting rejected without one?
A PTR (pointer) record is the reverse DNS lookup of your IP — the answer to "what hostname does this IP belong to?" Many large mail providers (Gmail, Microsoft, Yahoo) reject inbound mail from servers whose PTR does not match the HELO hostname of the SMTP conversation. You set the PTR on the IP, not on your domain — on a VPS, that means asking the VPS provider to set the PTR for your IP to mail.example.com. NordBastion sets PTR records on request from the panel within an hour.
How long does IP reputation warm-up take?
Two to six weeks of normal traffic to get out of the "new sender" bucket at Gmail and Outlook, longer if you send infrequently. The accelerators are: low and steady outbound volume (50–200 messages a day for the first week, scale up gradually), perfect SPF + DKIM + DMARC alignment on every message, zero DNSBL listings, recipient engagement (opens and replies). The killers are: bulk outbound on day one, missing or misaligned authentication records, and sending to spam-traps.
Do I need a dedicated VPS for mail or can I run it next to my other services?
Dedicated is strongly recommended. Mail-server software (Postfix, Dovecot, Rspamd, ClamAV, the database, the webmail) has a particular RAM and storage profile, and the reputation of the IP is tied to the mail traffic specifically — co-locating with a Tor exit relay or a Bitcoin node is asking for the IP to be listed somewhere unhelpful. A second VPS at $5.90/month is cheap insurance.
What is the ongoing maintenance load?
A monthly checklist: verify the IP is not on Spamhaus / SORBS / Barracuda DNSBLs (5 min — mxtoolbox.com); confirm Let's Encrypt certificates renewed (1 min); scan the Rspamd / Postfix logs for unusual patterns (5 min); run the Mailcow / MIAB updater (10 min); verify the latest backup restores cleanly (15 min once a quarter). Total: an hour a month, with a heavier hour twice a year when major versions land.
Port 25 open, PTR from the panel, no KYC, pay in crypto.
Mail-in-a-Box runs on Ravelin (2 vCPU, 4 GB, $5.90/mo). Mailcow wants Iron (4 vCPU, 8 GB, $24.90/mo). Both ship with port 25 already open.
Last reviewed · 2026-05-20 · Sources · Mailcow / Mail-in-a-Box / iRedMail upstream docs, Gmail Postmaster Tools, RFC 5321 / 6376 / 7489 · Cadence · yearly
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Bitwarden-compatible password vault under your own control.
Files, calendar, contacts, photos — owned, not rented.
A meta search engine that does not log you — because you own it.
What “no KYC” actually means — and what it does not.