Self‑Hosted Email Migration Playbook: Leave Gmail Without Losing Deliverability

Step 3 — DKIM: sign outbound mail

Use OpenDKIM. Generate a selector-key and publish the public DKIM TXT record. Example:

mkdir -p /etc/opendkim/keys/example.com
cd /etc/opendkim/keys/example.com
opendkim-genkey -s default -d example.com
chown opendkim:opendkim default.private
# default.txt contains the DNS entry

DNS record (example truncated for readability):

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

OpenDKIM config snippets to wire into Postfix:

/etc/opendkim.conf
Domain                  example.com
KeyFile                 /etc/opendkim/keys/example.com/default.private
Selector                default
Socket                  inet:8891@localhost
Canonicalization        relaxed/simple
Mode                    sv
PidFile                 /var/run/opendkim/opendkim.pid
UserID                  opendkim

Step 4 — SPF and DMARC: DNS policies

SPF is a first line of defense. Keep it tight and include sending services. Example SPF record for a single MTA:

example.com. IN TXT "v=spf1 ip4:203.0.113.45 -all"

If you still send via Google Workspace, marketing platforms, or other SaaS, include their mechanisms instead of listing raw IPs. Use ~all (soft fail) during testing, then switch to -all after validation.

DMARC

Start with monitor mode and collect reports:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; fo=1"

After successful warm‑up and stable auth signals, escalate policy to quarantine or reject.

Step 5 — MTA‑STS and TLS‑RPT (2026 expectation)

Receivers and senders now expect active TLS policies. Publish an MTA‑STS and TLS‑RPT policy and TLS‑RPT endpoint to surface TLS configuration issues.

# MTA-STS policy (hosted at https://mta-sts.example.com/.well-known/mta-sts.txt)
v=STSv1
mode: enforce
max_age: 604800
mx: mail.example.com

DNS for MTA‑STS policy discovery:

_mta-sts.example.com. IN TXT "v=STSv1; id=20260118"
_tlsrpt.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Step 6 — Mailbox migration strategy

Keep Gmail accounts active until the new service has demonstrated reliable inbox delivery. Use imapsync to mirror mailboxes. Example imapsync command:

imapsync --host1 imap.gmail.com --user1 user@gmail.com --password1 'app_password' \
         --host2 mail.example.com --user2 user@example.com --password2 'newpass' \
         --ssl1 --ssl2 --allowsizemismatch --syncinternaldates

Tips:

• Create a parallel address alias or forwarder during a staged migration.
• Keep Gmail forwarders active for 30–90 days to catch misconfigured senders.
• Inform users about SMTP credentials and update client settings (IMAP/SMTP, ports 993/587, TLS required).

Step 7 — Warm up sending reputation

Cold IPs and domains require gradual increase. A simple plan:

1. Days 1–7: Send low volume (10–50 emails/day) to engaged users only.
2. Days 8–30: Gradually increase by 10–20% daily while monitoring bounces and spam reports.
3. After 30 days: Reach intended volume if complaint rates <0.1% and bounce rates low.

Keep sending from consistent envelopes and From addresses. Avoid changing DKIM selectors, HELO, or rDNS during warm‑up.

Step 8 — Monitoring, telemetry and feedback loops

Set up these services immediately:

• Gmail Postmaster Tools — verifies domain and shows spam rates, IP reputation, and authentication results.
• Microsoft SNDS and Smart Network Data — for Outlook/Hotmail performance metrics.
• DMARC aggregate reports (RUA) — parse with tools like opendmarc or commercial parsers.
• Monitor logs and bounce patterns with a central log aggregator (Elastic, Grafana Loki) and alert on spikes.

Subscribe to abuse feedback loops where possible and create automated suppression lists for addresses that complain or bounce repeatedly.

Advanced hardening and policies

• Enforce submission auth: block port 25 for unauthenticated submission; use 587/465 with TLS and SASL.
• Rate limiting and greylisting: protect against abuse but be careful — greylisting can delay mail and upset users. Consider per‑tenant rate limits.
• Anti‑malware/antispam: implement SpamAssassin/Rspamd + ClamAV or commercial AV and tune whitelist/blacklist rules.
• Backups: daily mailbox backups, export policies, and automated restore tests.

Testing deliverability (practical commands and tools)

Before cutover, run these checks:

• SPF record check: dig TXT example.com and verify v=spf1 entry.
• DKIM test: send to a mail‑tester address or check headers from external mailboxes.
• DMARC reporting: validate _dmarc TXT with online validators or local tools.
• SMTP TLS test: use openssl s_client -starttls smtp -crlf -connect mail.example.com:587 to verify certificate chain and SNI.
• Mail server outreach: mail‑tester.com, MXToolbox, and checktls.com for in‑depth analysis.

Common pitfalls and how to avoid them

• Publishing DKIM with wrong prefixes or quoting errors — use the TXT output file from keygen directly.
• Setting SPF to include too many mechanisms or using +all — tighten scope and prefer ip4/ip6 listings or explicit includes.
• Not monitoring DMARC RUA — you will miss early failures from bulk forwarders or misconfigured services.
• Using recycled/shared IPs that have poor histories — reputation rebuild takes months.
• Mismatched TLS certificate names, PTR, and EHLO — make them identical to avoid receiver heuristics lowering your score.

Deliverability is not a one‑time task. It’s continuous operations: configuration, monitoring, and gradual adjustment based on receiver feedback.

Case study: 200 users migrated in 60 days (summary)

From a recent migration performed in late 2025, we moved 200 users from Gmail to a self‑hosted Postfix/Dovecot cluster on two VPS nodes with a failover MX. Key takeaways from that run:

• Starting in monitor mode for DMARC caught a misconfigured third‑party newsletter provider that was sending unauthenticated mail.
• Careful DNS record rollout and a 6‑week warm‑up period avoided inbox placement issues with Gmail and Outlook.
• Postmaster Tools diagnostics were critical — they diagnosed a high rate of authentication failures due to an expired DKIM selector during a key rotation.

Actionable takeaways (do these next)

• Immediately: verify rDNS and TLS cert CN match your mail hostname.
• Within 24 hours: publish SPF (soft mode) and a monitoring DMARC (p=none) to start receiving reports.
• Within 72 hours: generate DKIM keys, publish the public key, and enable OpenDKIM signing on Postfix.
• Before cutover: run imapsync dry runs and validate mailbox integrity with user sampling.
• Post‑cutover week 1: watch Gmail Postmaster and SNDS hourly; apply suppression and adjust warm‑up rates as required.

Future predictions (2026+): what to expect

In 2026, expect receivers to raise the bar further: stronger emphasis on telemetry consumption (TLS‑RPT, DMARC aggregated telemetry), more automated quarantines for unauthenticated senders, and increased importance of long‑term sending history. Investing in observability, automated rotating DKIM keys, and dedicated reputation IPs will become standard practice.

Final checklist before flip

1. rDNS, EHLO, cert CN match
2. SPF, DKIM (signed), DMARC (monitoring)
3. MTA‑STS and TLS‑RPT configured
4. Imapsync completed and verified for a subset of users
5. Warm‑up plan in place with suppression lists and feedback loop consumers
6. Monitoring dashboards and alerts for bounces, reject rates and auth failures

Call to action

If you’re preparing a migration, start with the checklist above and test one domain and a small set of users first. Need a review of your Postfix/Dovecot configuration, DKIM key setup, or warm‑up plan? Contact our engineers for a practical, hands‑on audit tailored to your environment — protect your domain reputation before you switch mail flows.

Related Reading

• Cloud Native Observability: Architectures for Hybrid Cloud and Edge in 2026
• Beyond Restore: Building Trustworthy Cloud Recovery UX for End Users in 2026
• Security Deep Dive: Zero Trust, Homomorphic Encryption, and Access Governance for Cloud Storage (2026 Toolkit)
• Outage-Ready: A Small Business Playbook for Cloud and Social Platform Failures
• A Practical Guide to Evaluating Creative Roadmaps: Lessons from the New Filoni‑Era Star Wars Slate
• Packing Tech for Long Trips: Essentials for Remote Workers and Commuters
• Designing Micro-Gyms for Urban Buildings: A 2026 Playbook for Landlords and Operators
• Road Trip Comfort Kit: Hot‑Water Bottles, Rechargeable Warmers and In‑Car Cozy Hacks
• Enterprise AI Readiness Checklist for Trading Firms: Lessons from Salesforce Research