How to Replace Gmail: Private Email, Custom Domains and a Safe Migration

To replace Gmail without losing mail or locking yourself out, first put your email on a domain you own, then choose a provider category (end-to-end encrypted, privacy-focused standard IMAP, or self-hosted), publish MX, SPF, DKIM, DMARC and MTA-STS records, copy mail with IMAP sync or Google Takeout, and move every account login to the new address before you close anything.

This post goes one level deeper than our guide on how to replace Google in your life, which covered every Google service at once. Here we stay on email, the service that is hardest to leave because so many other accounts point at it. If you are also moving calendars and files, our self-hosting guide for photos, files and calendar covers the CalDAV and CardDAV servers in more detail, and our explainers on SMTP and where SPF, DKIM and DMARC fit and IMAP vs POP3 explain the protocols underneath.

Key takeaways

• The domain is the portable part. An address on a domain you own can move between providers by changing DNS records. An address on someone else's domain cannot move at all.
• Google's own privacy policy says it collects "email you write and receive" and uses automated systems that analyze content, including to detect spam and malware. It also says it does not show personalized ads based on Gmail content unless you choose to make that data available to other services.
• Provider categories, not brands, decide the trade-off. End-to-end encrypted services protect stored content from the provider but limit IMAP and interoperability. Privacy-focused standard providers keep IMAP, CalDAV and CardDAV but can read stored mail. Self-hosting gives full control and full responsibility.
• Email authentication is five DNS records. MX routes mail in, SPF (RFC 7208) lists your senders, DKIM (RFC 6376) signs messages, DMARC (RFC 9989, which replaced RFC 7489 in May 2026) ties them to your visible From domain, and MTA-STS (RFC 8461) with TLS-RPT (RFC 8460) forces and monitors TLS between servers.
• Encryption never hides everything. OpenPGP and S/MIME protect the body. Sender, recipients, timestamps and, in many designs, the subject line remain visible to the servers that carry the message.
• Migration is mostly an account inventory problem. Copying mail is a few hours of IMAP sync. Moving 100 or more logins, recovery addresses and "Sign in with Google" accounts is the work that takes weeks.
• Self-hosting is realistic for some people, not most. The hard parts are IP reputation, outbound port 25, reverse DNS and keeping the stack patched, not installing the software.
• Keep the old account alive, but locked down, for a forwarding period of several months, with strong second factors, so nobody can take it over and reset your other accounts.

What a webmail provider sees and processes

Start with the provider's own words, not with assumptions. Google's privacy policy says it collects "the content you create, upload, or receive from others when using our services," and the first example it gives is "email you write and receive." The same policy says Google uses "automated systems that analyze your content" to provide tailored search results, personalized ads and other features, and that it analyzes content to help detect abuse such as spam, malware and illegal content.

Two other statements in that policy matter for email specifically. First, Google says it does not show personalized ads based on content from Drive, Gmail or Google Photos "unless you choose to make data from these services available to other Google services that support personalized ads." Second, the policy describes cross-service features: Search, depending on your settings, can draw on data from Gmail, and a flight confirmation email you receive may be used to create a check-in button in Gmail. Gmail also suggests addresses in the To, Cc and Bcc fields based on people you have communicated with.

So the honest summary, from the document itself, is this:

None of this is unusual for a hosted mail service. Any provider that filters spam must read incoming mail at some point, and any provider that offers server-side search must index it. The real question is which of those functions you are willing to have a third party perform, and under which jurisdiction and policy. That question has three broad answers.

The categories of alternatives

We describe categories here and do not rank brands. Inside each category, providers differ on price, storage, jurisdiction, apps and support, and you should read each candidate's own privacy policy and security documentation the same way we read Google's above.

End-to-end encrypted providers

These services encrypt stored mail so that the provider holds only ciphertext and cannot read your mailbox at rest. Between two users of the same service, messages are typically encrypted end to end using OpenPGP or a similar scheme, with keys managed by the apps. Mail to and from the wider internet is different: an incoming message from an ordinary sender arrives in plaintext over SMTP (protected only by transport TLS), and the provider encrypts it with your key on arrival. That means the provider's receiving server did see the plaintext, briefly, before it was encrypted. Outgoing mail to outside recipients is either sent as ordinary mail or offered as a password-protected message the recipient opens in a web page.

Trade-offs to expect: standard IMAP access often needs a local bridge application that decrypts on your machine, server-side full-text search may be limited because the server cannot read bodies, and if you lose both your password and your recovery material, the provider cannot recover your mail by design.

Privacy-focused standard IMAP providers

These run conventional mail infrastructure, usually with paid plans instead of advertising, and publish privacy policies that limit what they do with content. They speak standard IMAP, SMTP submission, CalDAV and CardDAV, so any mail client, phone or sync tool works without extra software. Stored mail is encrypted on disk in the ordinary sense, but the provider holds the keys, so it can read mail when required by law or by its own processes. You can add OpenPGP or S/MIME yourself on top.

Self-hosting

You run the mail transfer agent, the IMAP server, spam filtering, DKIM signing and backups yourself, on a server you control, often using open source stacks such as Postfix with Dovecot and Rspamd, or a bundled distribution that packages them as containers. You get complete control and the provider sees nothing, because you are the provider. You also inherit every operational problem, which we cover in its own section below.

Comparison table

Many people end up mixing categories: a domain they own, a standard or encrypted provider for daily mail, and a small self-hosted CalDAV server for calendars. The domain is what lets you change your mind later.

Why a custom domain matters for portability

An address like you@gmail.com belongs to the provider's namespace. If you leave, the address stays behind, and so does every password reset link and every correspondent who has it saved. An address like you@yourname.example belongs to whoever controls the domain registration. The MX record in DNS decides which provider receives the mail, and changing that record moves your address to a new provider in minutes, with no change for the people who write to you.

That is the single most important decision in this whole project. If you choose a new provider but keep using its own domain, you have only moved the lock-in, not removed it.

A domain also brings new responsibilities:

• Renewal is now a security control. If the domain expires and someone else registers it, they can receive mail for your old addresses and use password reset links on your accounts. Turn on automatic renewal, register for several years at a time, keep the registrar account on a strong second factor and keep its own recovery email off the same domain.
• The registrar account is now the root of trust. Whoever can change your nameservers can redirect your mail. Use a registrar that supports two-factor authentication and, where offered, a registry lock.
• DNS correctness is now your job. The records below are short, but a typo in SPF or DMARC can send your mail to spam folders.

How to set MX, SPF, DKIM, DMARC and MTA-STS

The examples use example.com and placeholder provider hostnames. Your provider's setup page gives the exact values; the structure below is defined by the RFCs and is the same everywhere.

Step 1: MX records route incoming mail

example.com.   3600  IN  MX  10 mx1.mailprovider.example.
example.com.   3600  IN  MX  20 mx2.mailprovider.example.

Lower preference numbers are tried first. Before switching, lower the TTL on your existing records (for example to 300 seconds) a day ahead, so the change propagates quickly and you can roll back quickly.

Step 2: SPF lists the servers allowed to send for your domain

SPF is defined in RFC 7208, which obsoleted RFC 4408 in April 2014. It is a single TXT record at the domain:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.mailprovider.example -all"

include: pulls in the provider's list of sending IPs. -all says everything else fails; ~all (softfail) is a gentler setting while you test. Two limits in RFC 7208 catch people out. Evaluating a record may not trigger more than 10 DNS-querying mechanisms and modifiers in total (include, a, mx, ptr, exists and redirect all count), and implementations should treat more than two "void lookups" (queries that return nothing) as an error. Each extra service you add (a newsletter tool, a billing system) adds includes, so count them. You may publish only one SPF record per domain.

SPF checks the envelope sender (the SMTP MAIL FROM), not the From header people see. That gap is why DKIM and DMARC exist.

Step 3: DKIM signs every message

DKIM, defined in RFC 6376 (September 2011), has the sending server add a cryptographic signature header covering selected headers and the body. Receivers fetch the public key from DNS at selector._domainkey.example.com:

s2026._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB" )

Hosted providers generate the key and show you the record, or ask you to add CNAME records that point at keys they rotate. RFC 6376 requires signers to use RSA keys of at least 1024 bits. RFC 8301 (January 2018) updated DKIM: it keeps 1024 bits as the floor, says signers SHOULD use keys of at least 2048 bits, and forbids signing with rsa-sha1. Use 2048-bit keys, and split the long value into multiple quoted strings if your DNS host requires it. Use a dated selector name so you can publish a new key beside the old one when you rotate.

Step 4: DMARC ties SPF and DKIM to the visible From domain

DMARC is now RFC 9989, published in May 2026, which obsoletes both RFC 7489 and RFC 9091. A message passes DMARC when SPF or DKIM passes and the domain that passed aligns with the domain in the From header. The record lives at _dmarc:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Then tighten it over a few weeks while you read the aggregate reports:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Tags worth knowing under RFC 9989:

The pct tag from RFC 7489 is gone. RFC 9989 explains that operational experience showed it was usually not applied as a true sampling rate, and replaces its useful behavior with t=y, which signals that you are testing your stated policy so receivers can apply a milder action. Our post on what changed in RFC 9989 covers the details. If your old records include pct=, remove it when you next edit them.

A personal domain with only one sending provider can usually reach p=reject within a month. A family or small business domain with several sending services should stay at p=none until the aggregate reports show every legitimate stream passing.

Step 5: MTA-STS makes server-to-server TLS mandatory

SMTP between servers uses opportunistic STARTTLS: if an attacker on the path strips the STARTTLS offer, many senders fall back to plaintext. MTA-STS (RFC 8461, September 2018) lets your domain publish a policy saying "only deliver to these MX hosts, and only over TLS with a valid certificate."

It has two parts. A DNS TXT record signals that a policy exists and carries an id you change whenever the policy changes:

_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20261023000000;"

And a policy file served over HTTPS, with a valid certificate, at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mx1.mailprovider.example
mx: mx2.mailprovider.example
max_age: 604800

mode is one of enforce, testing or none. In enforce mode, sending servers must not deliver to an MX that fails validation; in testing mode they deliver anyway and report the failure. max_age is in seconds, with a maximum of 31557600 (about one year). Start in testing with a one-week max_age, read the reports, then switch to enforce and raise max_age.

The policy file is a tiny static page, but it needs an HTTPS host on the mta-sts subdomain. Many hosted providers serve it for you through a CNAME; if not, any static host with automatic certificates works.

Step 6: TLS-RPT tells you when TLS fails

TLS-RPT (RFC 8460, September 2018) asks sending servers to email or post daily reports of TLS successes and failures when delivering to you:

_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Without it, an MTA-STS mistake in enforce mode means mail silently bounces at the sender and you never hear about it.

Step 7: optional autodiscovery records

RFC 6186 defines SRV records that let mail clients find your IMAP and submission servers automatically. RFC 8314 (January 2018) recommends implicit TLS for both, on port 993 for IMAP and port 465 for submission:

_imaps._tcp.example.com.       3600 IN SRV 0 1 993 imap.mailprovider.example.
_submission._tcp.example.com.  3600 IN SRV 0 1 465 smtp.mailprovider.example.

Verify everything from the command line

# Which servers receive mail for the domain?
dig +short MX example.com

# SPF, DKIM and DMARC records
dig +short TXT example.com | grep spf1
dig +short TXT s2026._domainkey.example.com
dig +short TXT _dmarc.example.com

# MTA-STS signal and policy file, and TLS-RPT
dig +short TXT _mta-sts.example.com
curl -fsS https://mta-sts.example.com/.well-known/mta-sts.txt
dig +short TXT _smtp._tls.example.com

# Does the MX offer STARTTLS with a certificate that matches its name?
openssl s_client -starttls smtp -connect mx1.mailprovider.example:25 \
  -servername mx1.mailprovider.example -verify_return_error </dev/null | head -20

Then send a message from the new account to an address at a large mailbox provider, open the original message source, and check the Authentication-Results header for spf=pass, dkim=pass and dmarc=pass.

The US federal government made the same set of controls mandatory for its agencies. CISA's Binding Operational Directive 18-01, issued on 16 October 2017, gave agencies 90 days to offer STARTTLS on every internet-facing mail server and to publish valid SPF and DMARC records with at least p=none and a reporting address, and one year to reach p=reject for all second-level domains and mail-sending hosts. NIST SP 800-177 Revision 1, Trustworthy Email (February 2019), is the longer federal guide to the same protocols and is a good reference if you want the reasoning behind each one.

What end-to-end encryption covers in email, and what it cannot hide

Transport TLS, which the records above enforce, protects a message while it moves between two servers. Each server along the way still holds the plaintext. End-to-end encryption protects the content from every server, including your own provider's. Email has two standards for it.

OpenPGP

OpenPGP is now specified in RFC 9580 (July 2024), which obsoletes RFC 4880 and modernizes the algorithms, including authenticated encryption and newer elliptic curve keys. Users hold their own key pairs, and trust in other people's keys comes from verifying fingerprints, from key directories or from the "web of trust." Keys can be published for automatic discovery; RFC 7929 defines an experimental method for publishing OpenPGP keys in DNS.

S/MIME

S/MIME version 4.0 is RFC 8551 (April 2019). It uses X.509 certificates issued by certificate authorities, the same model as TLS on the web. It is built into most desktop and mobile mail clients and is common in organizations that already run a certificate infrastructure. For an individual, obtaining and renewing a personal certificate is the main friction.

What neither hides

The subject line gap now has a standard fix. RFC 9788, Header Protection for Cryptographically Protected Email (August 2025), defines how a client places protected copies of header fields such as Subject inside the signed or encrypted part, with a placeholder outside. It only helps when both sides' clients implement it, so for now assume your subject lines are readable by every server on the path.

Metadata is often more revealing than content: who you write to, how often and when. End-to-end encrypted providers reduce what is stored at rest, but they still route mail and must see envelope addresses. If your threat model includes the fact of communication, email is the wrong channel, and a messaging protocol designed to minimize metadata is a better fit.

Two practical consequences:

1. Encrypted mail to outside contacts only works if they also use OpenPGP or S/MIME. Otherwise the encrypted provider falls back to ordinary delivery or a password-protected web message.
2. Losing your private key means losing access to old encrypted mail. Back up keys and their revocation certificates offline, the same way you would back up a password manager vault. Our self-hosted password managers post covers offline backup patterns that apply here too.

How to migrate mail, contacts and calendars

There are two ways to get mail out of Gmail: export a file with Google Takeout, or copy folder by folder over IMAP into the new provider. Most people should do both: Takeout for an archival copy you keep offline, IMAP sync for the copy you will actually use.

Option A: Google Takeout for an archive

Google's Takeout help page describes three steps: select the data to include, customize the archive format, and get the archive. A few details from that page are worth planning around:

• Choose products. Select Mail, Calendar and Contacts (and anything else you are leaving). You can narrow Mail to specific labels.
• File type and size. Archives come as zip or tgz. You choose a maximum archive size, and if your data is larger, Takeout splits it into multiple archives.
• Delivery. Google emails you a download link, or can place the archive in another cloud storage service. Google notes that once an archive reaches a third-party storage service, that service's terms apply.
• Timing. Google says the process "could take from a few minutes to a few days," and most people get the link the same day. If you are enrolled in the Advanced Protection Program, the archive is scheduled two days in the future.
• Recurring exports. You can schedule an archive every two months for one year (not available under Advanced Protection).
• Gaps. Changes made between requesting and creating the archive may be missing, and data in the process of being deleted is not included.

Google's Calendar help says calendar exports are .ics files (a zip of .ics files when you export all calendars at once), and Google's Contacts help says contacts download as CSV or vCard. The Mail export is a standard mailbox archive file that most desktop mail clients can import. It can be imported locally and then copied to the new server over IMAP, but a direct server-to-server IMAP sync is usually faster and preserves folder structure better.

Treat the Takeout archive as sensitive: it is your entire correspondence in one file. Download it to an encrypted disk, verify it opens, and delete it from any intermediate cloud location.

Option B: IMAP sync for the working copy

Google's help page states that, starting January 2025, IMAP access is always turned on for personal Gmail accounts. The same page says Gmail no longer supports third-party apps that require you to share your Google username and password and asks you to look for "Sign in with Google" instead. App passwords still exist for accounts with 2-Step Verification, but Google says they are "not recommended and are unnecessary in most cases." Gmail also allows up to 15 email clients connected at a time per account.

For the copy itself, imapsync is the long-standing open source tool for IMAP-to-IMAP migration, and its documentation has dedicated notes for Gmail, including Gmail limits and XOAUTH2 authentication. A typical run looks like this:

# 1. Dry run: list what would be copied, change nothing
imapsync \
  --host1 imap.gmail.com --ssl1 --user1 you@gmail.com --passfile1 ./gmail.pass \
  --host2 imap.newprovider.example --ssl2 --user2 you@example.com --passfile2 ./new.pass \
  --gmail1 --dry --justfolders

# 2. Create folders, then copy messages
imapsync \
  --host1 imap.gmail.com --ssl1 --user1 you@gmail.com --passfile1 ./gmail.pass \
  --host2 imap.newprovider.example --ssl2 --user2 you@example.com --passfile2 ./new.pass \
  --gmail1

# 3. Re-run after the MX switch to pick up anything that arrived in between
#    (imapsync skips messages already copied)

Gmail-specific points, from the imapsync Gmail FAQ:

• Throughput limits. The FAQ cites Google's published IMAP limits of 2,500 MB per day for downloads and 500 MB per day for uploads, and says Gmail signals a limit with a "Session expired" disconnection or a very slow transfer rate. At that rate a 10 GB mailbox takes about four days to leave Gmail. Reruns are safe, because imapsync skips messages it has already copied.
• --gmail1 is a preset. It fills in the Gmail host, TLS and throttling values that the author found work in practice (300,000 bytes per second, pausing after about 3 GB), so you do not have to tune them by hand.
• Labels become folders. A message with three labels appears in three IMAP folders, and every message also appears in [Gmail]/All Mail. Messages you archived without a label exist only in All Mail, so excluding that folder loses them, while including it duplicates labeled messages. Decide which you prefer before the first full run; a dry run shows the folder list.
• Use OAuth or an app password, never your main password in a file. Delete the password files and revoke the app password when you finish.
• Folder size limits. Gmail's settings include an option to limit IMAP folders to a maximum number of messages. Make sure it is off before you sync, or large folders will be cut short.

Many hosted providers offer a built-in import tool that does the same job from their side. It is convenient, but it requires giving the new provider OAuth access to your Gmail. Revoke that access in your Google Account security settings once the import finishes.

Contacts with CardDAV

Export contacts as vCard from Google Contacts (or use the vCard file in your Takeout archive) and import it into the new provider's address book, or into a self-hosted CardDAV server. CardDAV (RFC 6352) keeps contacts in sync across phone and desktop. Check for duplicates and for contacts that only had a phone number, which some importers skip.

Calendars with CalDAV

Export each calendar as .ics and import it into the new CalDAV server (RFC 4791). Two pitfalls: recurring events with exceptions sometimes import as separate events, and shared calendars or calendar subscriptions do not come across as shares. Recreate shares by hand and send new invitations for recurring meetings you organize. Our self-hosting guide walks through standing up a CalDAV and CardDAV server if you are taking those home too.

Cutover order

What to do about accounts registered with the old address

This is the long tail. Your Gmail address is a username, a recovery address and a password reset channel for dozens or hundreds of services. If you close the Gmail account before moving them, a reset link can go to an address you no longer control.

Build an inventory

Use three sources, then merge them in a spreadsheet:

1. Your password manager. Export or list every login whose username is the Gmail address.
2. Your mailbox. Search for words like "welcome," "verify your email," "confirm your account," "receipt" and "password reset." Each hit is a service that knows the address.
3. Your Google Account's third-party connections. Every app listed there signs in with your Google Account, not just with the address. Those need special handling (below).

Sort the list into tiers: financial and government accounts first, then the domain registrar and password manager, then anything with stored payment details, then everything else.

Change addresses deliberately

For each account, change the email address, confirm the verification message arrives at the new domain, and update the entry in your password manager. Where a service supports it, add a passkey or a second factor at the same time. Keep a "done" column so you can see progress.

"Sign in with Google" accounts

Accounts created with "Sign in with Google" are tied to your Google Account identity, not only to the address. Google's help page on linked apps says that removing a Sign in with Google link stops automatic sign-in to the app but does not delete your data there, so the account on the other side survives, and you need another way to log in to it. For each one, look in its settings for a way to add a password or another sign-in method against your new address, then disconnect Google. Do this before you consider deleting anything.

Run a forwarding period

Keep the Gmail account open for at least six months, ideally a year, with forwarding or fetching set up so new mail reaches you. Every message that still arrives at the old address is a reminder of an account you missed. Add it to the inventory and fix it.

Do not delete the old account in a hurry

An abandoned free mailbox that still receives password resets is an account takeover target. If you keep it, keep it locked down: a strong unique password, passkeys or a hardware security key, and recovery options pointing at your new domain. Some people keep the old account indefinitely with an auto-reply for exactly this reason.

Is self-hosting email realistic?

Running the software is the easy part. Bundled open source distributions, such as the mailcow: dockerized project, package an MTA (Postfix), an IMAP server (Dovecot), a spam filter (Rspamd), webmail and an admin interface as a set of Docker containers managed with Docker Compose, and a first install is an afternoon's work. What makes self-hosting hard is everything around the software.

The hard parts

• Outbound port 25. Many residential internet providers and many cloud hosting providers block outbound connections on port 25 by default to limit spam. Without it, your server cannot deliver mail directly. Some providers lift the block on request for established accounts; otherwise you need a relay.
• IP reputation. Receivers judge mail partly by the sending IP. An address that previously sent spam, or that sits in a range of dynamic residential addresses, will see your mail rejected or filed as spam regardless of how perfect your DNS records are. Check the IP against public blocklists before you build on it.
• Reverse DNS. Your sending IP should have a PTR record that resolves to your mail server's hostname, and that hostname should resolve back to the same IP. Only whoever controls the IP block can set PTR, so this must be possible with your host.
• Volume and history. A server that sends five messages a week has little reputation either way. Large mailbox providers publish sender guidelines; our bulk sender requirements checklist summarizes the thresholds that apply to higher volume senders.
• Maintenance. Mail servers are internet-facing services that parse untrusted input all day. You need security updates applied promptly, certificate renewal, disk space monitoring, queue monitoring, log review and tested backups.
• Availability. If your server is down, sending servers queue and retry (RFC 5321 says the give-up time generally needs to be at least four to five days), so short outages lose nothing. A long outage bounces mail.

Our history of SMTP abuse from open relays to SMTP smuggling explains why receivers became so suspicious of new senders in the first place.

A hybrid that avoids most of the pain

The common middle path is to self-host receiving and storage, and relay outbound mail through a paid SMTP relay service that already has reputation. Your MX points at your server, your IMAP is yours, and your SPF record includes the relay. You keep control of stored mail and lose most of the deliverability problem.

What the minimum self-hosted setup looks like

On a small virtual server with a static IP where port 25 is open and reverse DNS is settable:

# 1. Confirm port 25 outbound works before anything else
nc -vz -w 5 mx1.mailprovider.example 25

# 2. Confirm reverse DNS matches your hostname
dig +short -x 203.0.113.25
dig +short mail.example.com

# 3. Check the IP against a public DNS blocklist (reverse the octets)
dig +short 25.113.0.203.bl.example.org   # substitute the blocklist zone you use

Postfix's TLS documentation describes the settings for both directions. A minimal fragment for main.cf:

# Receiving: offer STARTTLS with your certificate
smtpd_tls_cert_file = /etc/ssl/mail/fullchain.pem
smtpd_tls_key_file  = /etc/ssl/mail/privkey.pem
smtpd_tls_security_level = may

# Sending: use TLS when the other side offers it
smtp_tls_security_level = may
smtp_tls_loglevel = 1

Dovecot's SSL documentation explains the difference between ssl = yes and ssl = required: with required, any attempt to authenticate before TLS is enabled fails, even for non-cleartext mechanisms. For a server that only you and your devices use, require it:

# dovecot.conf (Dovecot 2.4 setting names)
ssl = required
ssl_server_cert_file = /etc/ssl/mail/fullchain.pem
ssl_server_key_file  = /etc/ssl/mail/privkey.pem

Dovecot's documentation also warns that a client can still try cleartext authentication before enabling TLS and expose the password, so configure every client for implicit TLS on port 993 rather than STARTTLS on 143.

DKIM signing is usually done by the spam filter. Rspamd's DKIM signing module documentation shows how to generate a key and map it to a domain and selector:

rspamadm dkim_keygen -s s2026 -d example.com -b 2048 -k /var/lib/rspamd/dkim/example.com.s2026.key

which prints the DNS TXT record to publish. Then publish SPF, DMARC, MTA-STS and TLS-RPT exactly as described earlier, with your own server's hostname as the MX.

Self-hosting decision table

Because the domain is yours, you can start hosted and move to self-hosting later, or the reverse, with nothing more than an MX change and an IMAP sync.

Security trade-offs: recovery, 2FA, passkeys and account takeover

Leaving a large provider changes your account security model in ways that are easy to miss.

Account recovery

Large providers run sophisticated recovery systems that weigh device history, location and other signals before letting someone back into an account. Smaller providers have simpler processes, and end-to-end encrypted providers may have none for your data: forget the password and lose the recovery phrase, and old mail is gone. Write down recovery codes, store them offline in two places, and test recovery before you depend on the account.

Two-factor authentication and passkeys

Turn on the strongest second factor the new provider supports. Google's own passkey help page makes the general point: passkeys cannot be shared, copied, written down or accidentally handed to someone else, which makes them more resistant to phishing, and the biometric used to unlock them stays on the device. Passkeys and hardware security keys resist phishing because the browser binds the credential to the real site; one-time codes from an authenticator app come next; SMS codes are the weakest because phone numbers can be ported. Make sure you register at least two hardware keys or passkeys on different devices, so losing one does not lock you out.

The email account is the master key

Most password resets go to email. Whoever controls your mailbox, or your domain, can reset nearly everything else. That makes three things critical:

1. The mailbox account itself (strong second factor, recovery codes offline).
2. The domain registrar account (strong second factor, auto-renew, registry lock where available).
3. The DNS host, if it is separate from the registrar (same controls).

An attacker who changes your MX record for even an hour can receive your password reset mail. Registrar and DNS change notifications should go to an address that is not on the same domain, so an attacker cannot silence the alert they trigger.

Catch-all and aliases

Owning a domain lets you give each service its own address, such as shop-name@example.com. This makes leaks traceable and phishing easier to spot, because a message to the wrong alias is obviously fake. Be careful with catch-all mailboxes (accepting mail for any address at the domain): they attract spam to random addresses. Many people use explicit aliases or a subdomain dedicated to aliases instead.

Common mistakes

• Moving to a new provider's domain instead of your own. You only swap one lock-in for another.
• Switching MX before the new mailbox is ready. Mail arrives at an account you cannot log in to yet. Create, test and sync first.
• Publishing two SPF records. Receivers treat that as an error. Merge them into one.
• Exceeding SPF's 10-lookup limit by adding includes for every service. Count your mechanisms and flatten or remove unused services.
• Jumping straight to p=reject before reading aggregate reports, and blocking your own newsletter or billing mail.
• Leaving pct= in DMARC records. RFC 9989 removed it; use t=y while testing.
• Turning on MTA-STS enforce without TLS-RPT. Failures are then invisible to you.
• Letting the MTA-STS policy host's certificate expire. Senders that cached an enforce policy may refuse to deliver.
• Deleting the Gmail account too early, before the account inventory is finished and "Sign in with Google" logins are moved.
• Forgetting the domain renewal, or putting the registrar's recovery email on the same domain.
• Leaving migration credentials behind: app passwords, OAuth grants to import tools, password files on disk.
• Self-hosting on a residential IP and wondering why every message goes to spam.

FAQ

Can I keep my Gmail address and still stop using Gmail?

Not fully. The address stays tied to the Google Account. You can forward all mail from it to your new address and set an auto-reply, which lets you stop reading Gmail, but the account must stay open for forwarding to work.

How long does migrating from Gmail take?

Copying mail usually takes a few hours to a couple of days, depending on mailbox size and Gmail's IMAP bandwidth limits. The account inventory takes longer: plan on several weeks of changing addresses, then a forwarding period of six months to a year.

Is an end-to-end encrypted email provider fully private?

No. It protects stored message content from the provider, but sender, recipients, timestamps and often subject lines remain visible, and incoming mail from ordinary senders arrives in plaintext before the provider encrypts it.

Do I need a custom domain to leave Gmail?

You do not need one, but it is strongly recommended. Without it, your new address is tied to the new provider in the same way your old one was tied to Google, and moving again means repeating the whole migration.

What DNS records do I need for email on my own domain?

MX for incoming mail, an SPF TXT record, a DKIM TXT or CNAME record per selector, a DMARC TXT record at _dmarc, and optionally MTA-STS (_mta-sts TXT plus a policy file) and TLS-RPT (_smtp._tls TXT).

What changed in DMARC with RFC 9989?

RFC 9989, published in May 2026, replaced RFC 7489. It removed the pct tag, added a t test-mode tag, imported the np tag for non-existent subdomains and the psd flag for public suffix domains, and changed how the organizational domain is determined.

Can I self-host email on a home internet connection?

Usually not for sending. Many residential connections block outbound port 25 and use IP ranges that receivers distrust. You can receive mail at home and relay outbound mail through a paid relay, or rent a small server with a static IP instead.

How do I move Google Calendar and Contacts?

Export calendars as .ics files and contacts as vCard, from the apps or through Google Takeout, then import them into the new provider or a self-hosted CalDAV and CardDAV server. Recreate shared calendars and recurring meeting invitations by hand.

What happens to accounts that use "Sign in with Google"?

They depend on your Google Account, not just the address. Add a password or another login method on each service, switch the email to your new address, then disconnect Google, before you consider deleting the Google Account.

Should I delete my Gmail account when I am done?

Only after the forwarding period shows no more important mail arriving. Many people keep it locked down with a strong second factor and an auto-reply instead, so nobody else can take it over and use it to reset accounts that were missed.

Where Safeguard fits

Safeguard is not an email provider, a DMARC reporting tool or a mail filter, and it does not scan your mailbox. The fit here is indirect and narrow. If you self-host, your mail server is a stack of open source software, usually delivered as container images: an MTA, an IMAP server, a spam filter, a webmail client and their libraries. Those components carry vulnerabilities like any other software, and the Safeguard CLI can produce an SBOM and match it against vulnerability databases with safeguard scan --image <name>, so you can see which components in the images you run need updating.

Fix it without waiting for upstream

A self-hosted mail stack is a set of open source components you pull, rebuild and redeploy, and every rebuild pulls dependencies again. The same supply chain hygiene that applies to any service you run applies to the containers that hold your mail, even though the email protocols themselves are outside what Safeguard does.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: it installs, opens the interactive terminal, reads a vulnerability finding and its advisory, and asks before each command while it edits a dependency and runs the tests. On a self-hosted mail stack, the same flow applies to the webmail or admin interface you build from source, where a vulnerable library is a common finding.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code, and then scans from the terminal. For a home server running your mail containers, this is how you would scan the images where they actually run.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session that sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. If your mail server lives in a closet at home, this is a way to approve an update from your phone without opening a remote shell.

Click through it at your own pace, or open it full screen.

Get the apps at safeguard.sh/download and the CLI documentation at docs.safeguard.sh/docs/cli.

Quick check

Sources

• RFC 5321: Simple Mail Transfer Protocol
• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460: SMTP TLS Reporting
• RFC 8314: Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
• RFC 6186: Use of SRV Records for Locating Email Submission/Access Services
• RFC 9580: OpenPGP
• RFC 8551: S/MIME Version 4.0 Message Specification
• RFC 9788: Header Protection for Cryptographically Protected Email
• RFC 7929: DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
• RFC 6352: CardDAV
• RFC 4791: Calendaring Extensions to WebDAV (CalDAV)
• Google Privacy Policy
• Google Account Help: How to download your Google data
• Gmail Help: Add Gmail to another email client
• Google Calendar Help: Export events from your Google Calendar
• Google Contacts Help: Export, back up, or restore contacts
• Google Account Help: Sign in with a passkey instead of a password
• Google Account Help: Manage links between your Google Account and apps from other developers
• imapsync documentation
• imapsync FAQ: Gmail
• NIST SP 800-177 Rev. 1: Trustworthy Email
• CISA Binding Operational Directive 18-01: Enhance Email and Web Security
• Postfix TLS support (TLS_README)
• Dovecot documentation: SSL configuration
• Rspamd documentation: DKIM signing module
• mailcow: dockerized documentation

Last reviewed: 23 October 2026. Provider settings and Google's help pages change often; check the linked documentation before you start a migration.