Email Domain Migration Checklist: Move Without Breaking Deliverability

Overview

An email domain migration is any change to the domain or subdomain used to send, authenticate, track, or receive replies for email. It might be a brand rename, a move from a shared provider domain to your own subdomain, a split between transactional and marketing mail, a switch to a new ESP, or a new custom tracking domain. The visible change can look small, but mailbox providers evaluate it as a reputation and authentication change.

The safe way to migrate is to treat the new domain like production infrastructure before it carries production volume. That means inventorying every mailstream, preparing SPF, DKIM, and DMARC alignment, testing bounce and unsubscribe paths, warming volume gradually, and monitoring complaints, bounces, replies, clicks, and provider feedback during the move.

Inventory every mailstream before touching DNS

Most migration failures start with an incomplete map. A team updates the newsletter sender but forgets password resets, billing notices, sales sequences, support replies, or a webhook processor that still expects the old provider message id. Before changing DNS, list every system that sends or receives email and decide whether it should move, stay, or be split onto a different subdomain.

Separate transactional, lifecycle, marketing, cold outreach, support, and internal notification mail. Each stream has different tolerance for disruption. Transactional mail needs reliability and low latency. Marketing mail needs consent, unsubscribe, and cadence controls. Outreach needs extra reputation isolation. A migration is a good moment to stop mixing all of them under one reputation surface.

• Build a sender inventory before editing DNS records
• Decide which streams belong on root domain, subdomain, or separate domain
• Record all From addresses, reply-to addresses, tracking domains, webhooks, and unsubscribe URLs
• Keep the old domain alive until bounces, replies, and delayed events have drained

Authenticate the new domain before cutover

Do not send first and fix authentication later. Publish and validate SPF, DKIM, and DMARC for the new sender before production volume moves. DMARC alignment matters: at least one authenticated identifier should align with the visible From domain. If you are also changing a tracking domain, set it up and test redirects, HTTPS, click attribution, and scanner behavior before a live campaign depends on it.

Use a low-risk internal test matrix: direct mailbox delivery, Gmail and Yahoo test recipients, forwarded messages, unsubscribe links, bounce handling, replies, and any custom webhook events. Google and Yahoo sender guidance both emphasize authenticated, wanted mail and easy unsubscribe; those requirements do not pause just because a migration is in progress.

• Authentication should be green before the new domain carries real volume
• Check alignment, not only whether a DNS record exists
• Test reply and unsubscribe behavior as carefully as delivery
• Keep provider dashboards and raw headers available during QA

1. Publish DKIM records for the new provider or sending service.
2. Confirm SPF includes the service that will send for the new domain or subdomain.
3. Publish a DMARC policy that reports results and aligns with your rollout plan.
4. Verify custom tracking, bounce, return-path, and reply domains if your provider uses them.
5. Send internal and seed tests that cover direct delivery, forwarding, clicks, unsubscribes, replies, bounces, and webhook ingestion.
6. Document rollback steps before the first customer-facing send.

Cut over with a volume ramp, not a hard switch

A new sending domain or subdomain rarely has the same reputation as the old one. Even if the same company, list, provider, and content are behind it, mailbox providers still need to observe how recipients react. Start with engaged recipients and low-risk messages, then increase volume only while bounces, complaints, unsubscribes, and engagement stay healthy.

Avoid migrating during a major launch, re-engagement campaign, Black Friday sale, or cold outreach push. Those are already high-signal moments. If something goes wrong, you will not know whether the cause was the new domain, the offer, the audience, the cadence, or the provider migration.

• Start with people most likely to want the mail
• Do not combine migration with list imports or aggressive reactivation
• Pause ramp increases when complaint, bounce, or unsubscribe patterns move sharply
• Keep campaign content familiar until the domain has a baseline

Move suppression, consent, and reply context with the domain

Domain migration is not only a sending-path task. The operational memory around the old domain must move too: unsubscribes, hard bounces, spam complaints, manual suppressions, preference-center choices, consent source, reply threads, and support notes. If the new domain forgets that someone opted out under the old domain, the migration creates avoidable complaints and compliance risk.

Review every link that expresses recipient choice: List-Unsubscribe headers, one-click unsubscribe endpoints, footer URLs, preference-center pages, and reply-based opt-out handling. The FTC CAN-SPAM guidance requires a clear way to opt out and prompt honoring of opt-out requests; a migration should not turn that into a broken link or stale export.

• Suppressions are safety data, not just marketing preferences
• Broken unsubscribe links convert mild opt-outs into complaints
• Reply context should move with active conversations
• Delayed provider events can arrive after the main cutover

1. Export or replicate global suppressions before enabling the new sender.
2. Carry campaign-level unsubscribe and preference scopes forward where applicable.
3. Verify one-click unsubscribe, footer unsubscribe, and reply-to opt-out handling on the new domain.
4. Route replies into the correct inbox or owner before customer-facing sends begin.
5. Keep old-domain webhooks, redirect handlers, and reply aliases active through the tail period.
6. Record the migration date so future analytics can separate domain-change effects from content changes.

Monitor the migration like an incident window

For the first few weeks, treat the migration as a live change window. Watch authentication pass rates, DMARC aggregate reports, provider deferrals, hard and soft bounces, spam complaints, unsubscribes, clicks, replies, and support tickets. Open rates can be noisy because of privacy proxies, so do not use opens alone to decide whether the new domain is healthy.

Mailbase fits here when the challenge is connecting sending changes to workflow response. Scheduled sends, analytics, suppression controls, webhook visibility, and a shared reply inbox let operators see whether the migration is causing technical failures, negative replies, or audience fatigue. The same principle applies in any stack: the migration owner needs a dashboard and the authority to pause sends.

• Name a migration owner who can pause sends quickly
• Keep old and new domain metrics side by side during the ramp
• Use DMARC reports and full headers for authentication debugging
• Write rollback criteria before the migration starts

Common Mistakes

• Skipping SPF, DKIM, and DMARC, or assuming they're a one-time setup.
• Sending real volume from a brand-new, un-warmed domain.
• Reusing a stale list without re-verifying, so bounces spike.
• Ignoring complaint rate until a single bad campaign sinks the domain.

Sources & Further Reading

Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.

Related guides

More on email domain migration checklist and the surrounding deliverability workflow:

FAQ

Related reading