Replace Gmail

Start here: you probably should not do this#

Every other migration here trades convenience for control, and the worst case is that something is annoying. Email is different: the worst case is that mail you send stops arriving, you never find out, and the damage is to relationships and invoices rather than to a service you can restart.

What you give up when you leave Gmail for a server you run:

• Delivery that just works. Google has spent twenty years building sending reputation. You start at zero on an IP address whose history you did not choose.
• Spam filtering at Google's scale. Rspamd is good. It is not trained on a billion mailboxes. Expect more spam in the inbox and, worse, occasional real mail in the spam folder.
• Instant search over 15 years and 200,000 messages. Dovecot with a full-text index gets close on a well-provisioned box. On a 2 GB VPS it does not.
• Recovery. If you lose the mailbox and the backup, nobody has a copy.

If your reason is privacy, note that most of your correspondence still passes through Gmail, because that is where the people you write to have their accounts. Self-hosting removes Google from one side of the conversation.

The failure mode: mail that stops arriving and never tells you#

This is the part that vendor-friendly guides skip, and it is the whole reason this page recommends against the obvious plan.

Port 25 is blocked. Your server needs outbound TCP 25 to talk to other mail servers directly. Nearly every residential ISP blocks it permanently, and several large cloud providers block it on new accounts and require a support request that is regularly refused. Port 587 to a relay does not substitute. Test before you buy anything:

nc -vz gmail-smtp-in.l.google.com 25

PTR records are not yours to set. Reverse DNS lives with whoever owns the IP block, so it is a control panel field at Hetzner, OVH or DigitalOcean, and does not exist for a home connection at all. Gmail's sender guidelines require working forward and reverse DNS for sending IPs, and mailcow's docs require the PTR to match your mail hostname exactly, for IPv4 and IPv6 both. A mismatch is the most common reason a correct server gets rejected by Outlook.

SPF, DKIM and DMARC are table stakes. SPF says which hosts may send for your domain, DKIM signs each message with a key published in DNS, and DMARC says what receivers should do when the two disagree and gives you a reporting address. Publish all three before your first real message. DNS for self-hosters covers the layout.

And the failure is invisible. A receiving server is allowed to accept your message and then quietly file it in spam or drop it. No bounce comes back, and your sent folder is full of mail that looks delivered. People discover this three months later, from a client who says they replied to an email that never reached them. The only defenses are a DMARC rua address you read and a monthly test to accounts you control at Gmail, Outlook and Yahoo, checking the headers rather than the inbox.

The honest middle path#

For most people reading this, the right migration is not to a server in your house.

1. Buy a domain you will keep, and pay for it a decade at a time. This is the entire point. you@yourname.dev is portable; you@gmail.com is Google's.
2. Point it at a paid mail provider. Fastmail, Migadu, Mailbox.org, Proton and Purelymail all cost less than a streaming subscription and none are advertising businesses. Delivery is their problem.
3. Keep the exit open. Use IMAP, not a proprietary client, and take a local copy on a schedule so leaving is an imapsync run rather than a negotiation.

That gets you off Google, gets you an address nobody can revoke, keeps mail arriving, and costs nothing in ongoing attention. When not to self-host makes the general version of this argument. If you skip the rest of this page, you have still won.

When full self-hosting is genuinely right#

It suits you if you have a VPS with controllable reverse DNS, outbound 25 open or a relay you are happy to pay for, you already run other services and back them up properly, and mail being down for a day would be irritating rather than expensive.

Do it with an outbound relay and stop treating that as a compromise. Send through Postmark, SES, Mailgun or your host's submission service on 587; receive, filter, store and search locally. You keep the domain, every mailbox, the archive, the spam policy and a twenty minute exit. You rent the one thing you cannot manufacture, which is reputation.

Getting your mail out of Gmail#

Do both of these. They serve different purposes.

Takeout, for the cold archive. At takeout.google.com, deselect everything, select Mail, and pick all mail or specific labels. You get mbox files (RFC 4155): plain text, messages concatenated, Gmail labels preserved as an X-Gmail-Labels header rather than as folders. Large accounts split into numbered archives and the links are time limited, so download them the day they land. Verify before you celebrate:

grep -c '^From ' All-mail-Including-Spam-and-Trash.mbox

IMAP, for the live migration. Takeout flattens your folders; a server-to-server sync does not. Turn on two-factor authentication, generate an app password, then run imapsync:

imapsync \
  --host1 imap.gmail.com --port1 993 --ssl1 \
  --user1 you@gmail.com --password1 "$GMAIL_APP_PASSWORD" \
  --host2 mail.example.org --port2 993 --ssl2 \
  --user2 you@example.org --password2 "$NEW_PASSWORD" \
  --exclude '^\[Gmail\]' --automap --skipcrossduplicates

Excluding [Gmail] skips All Mail, Important and Starred, which are views over messages you already copied and will otherwise duplicate everything. Google rate limits IMAP, so a 40 GB mailbox is a multi-day sync, not an evening. Run it, run it again, then look at DNS.

Contacts and calendar come out of Takeout too, as vCard and iCalendar. mailcow takes them through SOGo, Stalwart through CalDAV and CardDAV.

Which path for your situation#

mailcow vs Stalwart decides between the two servers in detail.

What it costs and what breaks#

Cost. A VPS with usable reverse DNS is roughly 5 to 15 euros a month for mailcow's documented 6 GiB floor, or 4 to 6 for Stalwart. Add a relay and backup storage and call it 100 to 250 euros a year, against 30 to 60 for a paid provider. You are not saving money. mailcow scores 4 out of 5 on operational load and Stalwart 3, and neither number includes watching DNS, reputation and blocklists forever.

What breaks. A failed certificate renewal takes IMAP down on every phone in the house at once. A host distribution upgrade can install an MTA that steals port 25, which the mailcow docs call out for Debian 12 to 13 specifically. Your backup silently omits mailcow's crypt volume and restores unreadable ciphertext, or you rsync Stalwart's RocksDB store live and get a copy that will not open. Read Backups that actually restore and Backing up a running database before the first message arrives, and put a check on port 993 and your MX in Uptime Kuma.

The point of no return#

Everything above is reversible. Changing the MX record is not, in the sense that mail delivered to the new server after the switch exists nowhere else.

Sequence it like this:

1. Stand the server up on mail.yourdomain.tld with the full DNS set: A, AAAA, MX, SPF, DKIM, DMARC with an rua you read, and a matching PTR. Pick that hostname carefully, because mailcow cannot change it later.
2. Drop the MX TTL to 300 a day before cutover so a mistake costs five minutes.
3. Run imapsync to completion, twice.
4. Switch the MX. Send and receive test mail against Gmail, Outlook and Yahoo, and read the headers for spf=pass, dkim=pass and dmarc=pass.
5. Leave Gmail forwarding for at least 30 days and keep the account alive for a year. Then audit your password manager, Vaultwarden or otherwise, and move every account whose recovery address is still the Gmail one.

What to do next#

Run the port 25 test and check whether your provider lets you set reverse DNS. Fifteen minutes, and it decides this for you. If either fails, buy the domain, pick a paid provider, and call the project finished.

If both pass, read mailcow vs Stalwart to pick the software, then A security baseline for a home server before mail exists on the box. When you move it to different hardware later, Moving a service to a new machine applies with one addition: the DKIM keys and the PTR record move with the service, or nothing you send verifies. The rest of the Communication category covers the other Google services you are still using.