Migrating Email to a New Domain

## Why Domain Email Migrations Are Risky Changing the domain you use for email is one of the riskier operational changes a business can make. Done carelessly, you can lose incoming messages during the cutover, break existing email threads, confuse contacts, and damage your sender reputation — all simultaneously. Done carefully, with a staged transition plan, the migration can be nearly seamless. This guide provides the complete playbook. ## Common Reasons for Email Domain Migration - **Rebranding**: Company name or brand change requires new domain - **Acquiring a better domain**: Moving from `mybiz.net` to `mybiz.com` after the .com became available - **Mergers and acquisitions**: Consolidating email under a unified domain - **Separating business units**: Spinning out a brand into its own domain - **Upgrading from free to professional domain**: Moving from `@gmail.com` to `@yourbusiness.com` Each scenario has slightly different considerations, but the technical mechanics are the same. ## Phase 1: Pre-Migration Planning (2–4 Weeks Before) ### Audit Your Current Email Configuration Before touching anything, document: - Current MX records and TTL values - SPF record content - DKIM selectors in use - DMARC policy - All aliases and distribution lists - Auto-responders and email rules - Third-party services that send email on your domain's behalf (CRMs, marketing tools, billing systems) ### Register and Set Up the New Domain If you haven't already, register the new domain. See Domain Registration Checklist for the full domain registration process. **Important**: Set up the new domain's Email Hosting completely before announcing or using the new address publicly. This means: - Configure MX records on the new domain - Set up mailboxes on the new domain - Add SPF Record, DKIM, and DMARC records - Send test emails to verify authentication passes ### Start Warming the New Domain New domains have no email sending reputation. Before you migrate, start sending email from the new domain to warm it up: - Forward confirmation emails, notifications, or low-stakes communications from the new domain - Aim for 50–100 emails per day in the first week - Monitor Google Postmaster Tools for the new domain See Email Deliverability: How Domain Reputation Matters for the full warming protocol. ### Set Up Forwarding from New to Old (During Transition) While warming the new domain, configure Email Forwarding from the new domain's addresses to your current addresses. This way, if anyone starts using your new address before you've fully migrated, their email still reaches you. ## Phase 2: Lower TTL (1 Week Before Migration) The TTL (Time To Live) on your current MX records determines how quickly DNS changes propagate. If your current TTL is 86400 (24 hours), you need to lower it a full day before the cutover. Best practice: 1. **One week before**: Lower TTL (Time To Live) to 3600 (1 hour) 2. **24–48 hours before**: Lower further to 300 (5 minutes) 3. **At cutover time**: Make MX record changes — they propagate within minutes This staged approach ensures that by the time you actually make the change, cached records expire quickly and the transition is near-instant. ## Phase 3: Communication (1–2 Weeks Before) ### Notify Contacts Don't surprise people with a domain change. Announce it: **Email blast** to all contacts: "Our email address is changing. As of [date], please update your records. You can still reach us at [email protected] until [date + 3 months]." **Email signature update**: Add a notice: "From [date], our new email will be [email protected]" **Website update**: Update contact pages, footer email addresses, support email links ### Update Third-Party Services Systematically update every service that: - Sends email FROM your domain (update SMTP credentials, domain settings) - Has your old email address registered (update account email address) - Sends notifications TO your old email address Create a spreadsheet and work through it methodically: - CRM system (HubSpot, Salesforce, etc.) - Email marketing platform (Mailchimp, ConvertKit, etc.) - Billing and payment systems - Support ticket system - Domain registrars (email for domain renewal notices) - Cloud providers and infrastructure tools - Social media accounts - Google My Business / Apple Maps listings ## Phase 4: The Cutover ### Email Archive Export (Before Cutover) Export all email from your old mailboxes before changing infrastructure. Most providers support: - Google Workspace: Google Takeout - Microsoft 365: eDiscovery or Outlook PST export - cPanel/IMAP: Download via Thunderbird to local storage Store archives in a safe location. Even if your old Email Hosting remains accessible after cutover, having an archive prevents any data loss. ### Change MX Records on Old Domain With TTL already lowered to 300, update the old domain's MX records to either: **Option A: Forward everything to the new domain's mail server** Configure your old email provider to forward all incoming email to the corresponding new domain address. Or use an Email Forwarding service for the old domain. **Option B: Keep old mailboxes alive but stop active use** Leave the old MX records in place. Continue receiving at the old domain but stop sending from it. Set an auto-responder: "This address has moved to [email protected]. Please update your records." Option B is lower risk — email continues to arrive at old addresses while contacts update their records. ### Configure Old Domain Email Forwarding For at least 6 months after migration, forward email at the old domain to the corresponding new domain address: ``` Old domain MX: → forwarding service Forwarding rule: *@olddomain.com → [email protected] ``` Cloudflare Email Routing or ImprovMX work well for this. Keep the old domain registered and the forwarding active for as long as important contacts might still use the old address. For high-stakes business migrations, some organizations maintain forwarding indefinitely. ### Update Authentication on Old Domain After cutover, update the old domain's SPF Record to prevent anyone from spoofing your old address: ``` Old domain SPF: v=spf1 -all ``` And update DMARC to reject: ``` Old domain DMARC: v=DMARC1; p=reject; rua=mailto:[email protected] ``` This prevents phishers from using your old domain address for fraud while you're maintaining the domain for forwarding. ## Phase 5: Post-Migration Verification ### Check Email Flow in Both Directions - **Inbound to new domain**: Send test emails from external addresses to [email protected] - **Outbound from new domain**: Send test emails and check headers for authentication pass/fail - **Forwarding from old domain**: Send to [email protected] and confirm it arrives at [email protected] - **Authentication headers**: Open a received message and verify `spf=pass`, `dkim=pass`, `dmarc=pass` ### Monitor Deliverability Watch carefully for the first 2–4 weeks: - **Google Postmaster Tools** for the new domain: Check spam rates and domain reputation - **Bounce rates**: Any increase suggests authentication issues or list quality problems - **Spam complaints**: Monitor via feedback loops ### Update Email Signatures and Templates Every template, automated email, and signature that references the old address needs updating. Check: - Email marketing templates - Auto-responders and sequences - Order confirmation emails - Invoice templates - Support canned responses ## Reputation Considerations Email reputation doesn't transfer automatically between domains. Your new domain starts with zero reputation, regardless of how excellent your old domain's standing was. **What helps**: - Pre-warming the new domain (as described in Phase 1) - Keeping sending volume similar to your old pattern rather than spiking - Sending first to your most engaged contacts - Ensuring all authentication records are configured correctly from day one **What hurts**: - Sending large volumes immediately from the new domain - High bounce rates (suggests old list data not cleaned before migration) - Recipients not recognizing the new address and marking as spam ## Migration Timeline Summary | Timeframe | Actions | |---|---| | 4 weeks before | Set up new domain email, start warming | | 2 weeks before | Notify contacts, update third-party services | | 1 week before | Lower TTL (Time To Live) to 3600 | | 48 hours before | Lower TTL to 300 | | Migration day | Export archives, change MX, activate forwarding | | Post-migration | Monitor deliverability, update remaining references | | 6+ months | Maintain forwarding on old domain | ## Next Steps - **Email Deliverability: How Domain Reputation Matters** — Warming and reputation building for new domain - **SPF, DKIM, DMARC: Email Authentication Trilogy** — Authentication setup on both old and new domain - **MX Records Deep Dive: Email Routing Explained** — Understanding MX record changes during migration - **Custom Email with Your Domain: Complete Setup Guide** — Setting up the new domain from scratch