> TAKE IT BACK STEP 05 / 06
root@takeitback:~/guide/05-email$ cat readme.md
STEP 05

Run your own email

The hardest and most rewarding rung. Self-hosted mail gives you complete ownership of your correspondence — but deliverability is genuinely tricky, so this page is honest about the work and the fallbacks.

DIFFICULTYAdvanced
TIMEA weekend
COST$5–15/mo (VPS)
REPLACESCorporate email providers

Read this first

Email is the one service where "just self-host it" comes with real caveats. Sending mail that reliably reaches other inboxes depends on your server's reputation, and large providers distrust new senders by default. Very doable — but go in clear-eyed.

// two honest warningsRun mail on a VPS with a clean IP, not your home connection — residential IPs are blocked from sending by nearly everyone. And keep your current address live through a long overlap; do not cut over cold.

Which OS for a mail server

Mail stacks are built and tested on Linux, and the VPS you should use for mail will run Linux. macOS and Windows can manage the server, but shouldn't host the mail itself — the tabs are honest about that.

This is the path. Use a curated all-in-one stack rather than assembling parts by hand:

  • Mailcow — Docker-based, modern admin, actively maintained. A good default.
  • Mail-in-a-Box — one script turns a fresh server into a complete mail system. The simplest on-ramp.
  • Docker Mailserver — leaner, config-file driven, for more control.
mail-in-a-box, on a fresh ubuntu vps root@vps:~$ curl -s https://mailinabox.email/setup.sh | sudo bash

Don't host mail on macOS — reputation, uptime, and residential-IP issues make it a poor fit. Instead, use your Mac as the admin workstation: SSH into the Linux VPS that runs the mail stack, and manage it from there.

you@mac:~$ ssh root@your-mail-vps
# then follow the Linux tab on the server

Same guidance: Windows isn't a mail-server host. Manage the Linux VPS from Windows Terminal or WSL2 over SSH, and run the stack there.

$ ssh root@your-mail-vps
# the mail stack lives on Linux; Windows just drives it

The three records that decide everything

Whether big providers trust your mail comes down to three DNS records proving your server is a legitimate sender. Your stack generates the values; you paste them into your domain's DNS. These are the same no matter what you administer from:

DNS records for your mail domain # SPF — which servers may send as you
@ TXT "v=spf1 mx ~all"
# DKIM — cryptographically signs every message
mail._domainkey TXT "v=DKIM1; k=rsa; p=MIGf..."
# DMARC — what receivers do on failure
_dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:you@yourdomain.com"

You also need a reverse DNS (PTR) record — set through your VPS provider — matching your server's hostname. Missing rDNS gets mail rejected outright.

Warm the domain slowly

A brand-new domain that suddenly sends a hundred messages looks exactly like a spammer. Start with a trickle to addresses that will mark you "not spam," and build over a couple of weeks.

Keep a safety net

Until you fully trust the setup, route outbound mail through a reputable SMTP relay so your messages inherit an established reputation while yours grows. You still own the inbox and the data; only the last delivery hop is borrowed.

// test your scoreSend a message to a mail-testing service before trusting the setup. It scores your SPF, DKIM, DMARC, and rDNS and tells you exactly what's still weak.

Before you move on