# Email Migration Checklist and Cutover Control Board

> Plan an email-provider migration as a controlled change to identity, recipient state, event contracts, production traffic, and operational ownership—not merely a template export.

- **Canonical page:** [https://emailbump.com/tools/email-migration-checklist](https://emailbump.com/tools/email-migration-checklist)
- **Interactive tool:** [Open the email migration checklist](https://emailbump.com/tools/email-migration-checklist)
- **Category:** email infrastructure, deliverability operations, and change management
- **Updated:** July 2026
- **Control set:** 38 phased controls with applicability, dependencies, owners, due dates, evidence, actions, and cutover gates
- **Privacy:** Program inputs, control states, owners, evidence notes, and exports remain in the browser
- **Network boundary:** The board does not connect to either provider, change DNS, import contacts, schedule campaigns, or send messages
- **Decision boundary:** The output is an operational evidence record, not a guarantee of deliverability, regulatory compliance, data integrity, reputation transfer, or incident-free cutover

## What an email migration changes

An email service provider migration is often described as moving templates, contacts, and API calls. That description is dangerously incomplete.

A production email system also includes:

- visible From identities and reply paths;
- envelope sender domains and bounce routing;
- DKIM signing domains and selectors;
- SPF authorization;
- DMARC policy, alignment, and reports;
- tracking domains and redirect behavior;
- sending IPs, reverse DNS, HELO identity, TLS, and reputation;
- consent provenance and subscription scope;
- unsubscribes, complaints, permanent failures, and manual suppressions;
- audience fields, lists, segments, and eligibility logic;
- templates, assets, localization, personalization, and plain-text alternatives;
- event payloads, signatures, retries, ordering, and deduplication;
- transactional idempotency and latency;
- campaign schedules, automation state, and in-flight queues;
- metric definitions and historical continuity;
- credentials, roles, recovery, audit logs, and incident ownership;
- late events, residual traffic, data retention, contracts, and retirement.

The control board treats migration as a change to that entire system. A task is ready only when it is applicable, marked verified, assigned to an owner, supplied with evidence, and no applicable dependency remains open.

## Evidence state, not migration score

The tool does not produce a percentage that pretends to predict success.

Its primary state is one of:

### Explicitly blocked

At least one applicable control is marked blocked. A block should identify the condition, owner, decision needed, and consequence. Examples include missing target DKIM signing, an unsubscribe event that does not propagate, or transactional retry behavior that creates duplicates.

### Not cutover-ready

No task is explicitly blocked, but one or more blocker controls lack verified evidence. “In progress” and “not started” are not readiness states. A control marked verified without an owner or proof also remains open.

### Blocker controls evidenced

Every applicable blocker has verified evidence and its dependencies are ready. This is necessary for cutover consideration, not sufficient proof that a real migration will be safe. The go/no-go owner must still review live context, accepted risks, staff availability, provider state, and the complete evidence pack.

Phase completion percentages measure verified control completion. They are not deliverability, compliance, or quality scores.

## Applicability model

The board changes its control set from the migration scope.

### Traffic scope

Marketing-only scope includes subscription, unsubscribe, and campaign-oriented controls but excludes transactional-only idempotency.

Transactional-only scope includes latency, retries, idempotency, and failover controls but excludes subscription-specific one-click unsubscribe.

Mixed scope includes both.

### Dedicated IP or new pool

When selected, the plan includes IP assignment, forward and reverse DNS, HELO identity, TLS evidence, pool separation, capacity, and reputation ramp planning. Shared infrastructure still needs routing and provider validation, but the customer may not control the IP foundation.

### Contact and field migration

When selected, the plan includes field types, nulls, defaults, consent semantics, lists, segments, rejected rows, and reconciliation. Suppression protection remains applicable even if the target receives contacts from another system because every send route must honor recipient state.

### Event and webhook migration

When selected, the plan includes event schema, signatures, identifiers, ordering, retries, duplicate delivery, dead letters, outage recovery, and replay.

### Identity change

When selected, the plan includes branded return paths, click and open hosts, certificates, redirects, reply handling, and alignment. Authentication controls remain applicable even when the visible identity stays stable because the underlying route and signer change.

Not applicable means intentionally outside this migration scope. It does not mean the underlying capability is unimportant.

## Phase 1: inventory

Inventory exists to make the real system visible before target design.

### Sending streams

List every production and non-production sender:

- application or service;
- message class;
- business purpose;
- provider account;
- domain and From address;
- typical, peak, and emergency volume;
- recipient regions and major mailbox providers;
- IP pool;
- frequency and latency expectation;
- owner;
- retirement status.

Reconcile the list against code, provider accounts, DNS, invoices, vendor contracts, secrets, firewall rules, job schedules, and webhook consumers. A forgotten low-volume application can continue sending through the old provider for months or become unauthorized when DNS changes.

### Identity map

Capture delivered raw headers from every production route. Record:

- RFC 5322 From domain;
- envelope MAIL FROM or return-path domain;
- DKIM d= domain and selector;
- SPF evaluation domain;
- DMARC result and aligned identifier;
- Message-ID domain;
- HELO or EHLO identity;
- sending IP and reverse DNS;
- tracking and redirect hosts;
- List-Unsubscribe headers;
- reply path;
- provider-added headers and transformations.

Do not infer current state only from configuration screens. The received message is evidence of what the route actually produced.

### Volume and quality baseline

Create at least four representative weeks of volume and quality evidence when possible. Break it down by stream, sender identity, mailbox provider, region, and day.

Include:

- attempted, accepted, delivered, deferred, and bounced counts;
- hard, soft, and unclassified bounce definitions;
- complaint rate with denominator;
- unsubscribe rate and scope;
- API errors and queue age;
- transactional latency;
- unique click and conversion definitions;
- revenue or business outcomes where relevant;
- known incidents, promotions, holidays, and seasonality.

A before/after comparison is useful only when definitions and populations are comparable.

### Recipient state

Identify the authoritative source for:

- consent and its provenance;
- subscription scope;
- opt-in and confirmation timestamps;
- unsubscribe timestamp and mechanism;
- complaints;
- permanent delivery failures;
- temporary failure policy;
- manual and legal blocks;
- deletion requests;
- regional restrictions;
- list and segment membership.

Conflicting state needs an explicit precedence rule. Default toward not sending when permission or suppression is ambiguous.

### Templates and automations

Classify every template, partial, asset, localization, campaign schedule, journey, trigger, delay, exit rule, goal, and downstream action as active, dormant, test, or retire.

Migration is a useful time to remove dead scope. Rebuilding unused assets increases risk and hides which flows actually need acceptance tests.

### Integrations and secrets

Inventory REST APIs, SMTP, SDKs, plugins, serverless jobs, batch exports, inbound email, webhooks, analytics pipelines, data warehouses, support tools, and alerting.

For each, record authentication, secret owner, rotation, network restriction, retry behavior, timeout, idempotency, data classification, signature verification, consumer, and failure owner.

## Phase 2: foundation

Foundation prepares the target and a safe coexistence period.

### Account and access

Establish organization ownership, production and non-production separation, SSO or MFA, least-privilege roles, service accounts, API-key scope, audit retention, recovery, billing ownership, support contacts, and emergency access.

Shared human credentials create weak attribution and difficult revocation. Migration access should not become permanent administrator access without review.

### Future identity strategy

Approve which visible and technical identities stay stable and which change.

Stable visible From identity can preserve recipient recognition. Separate transactional and promotional streams when their purpose, consent, volume, latency, or reputation risk differs. Use subdomains deliberately; do not create a new domain merely to escape existing reputation.

Document:

- visible From addresses;
- reply handling;
- DKIM signing domains and selectors;
- return paths;
- tracking hosts;
- IP pools;
- Message-ID behavior;
- alignment;
- old/new coexistence;
- final retirement.

### DNS change plan

Every DNS change needs:

- authoritative owner;
- current value;
- target value;
- reason;
- TTL and when it will be lowered;
- prerequisites;
- validation query;
- propagation observation;
- rollback value;
- removal date;
- approver.

Do not replace an SPF record with a second record. A domain must have a coherent policy, and coexistence usually means updating one policy to authorize both active routes.

### SPF coexistence

Trace the actual envelope sender used by each route. Some providers use a custom return path; others use a provider domain that does not require inclusion in the visible domain's SPF record.

Model recursive include and redirect behavior. Keep evaluation within RFC 7208 limits, remove stale mechanisms, and avoid flattening that cannot be maintained when provider ranges change.

Authorize old and new active routes during overlap, then remove obsolete authorization after residual traffic reaches zero.

### DKIM signing

Use distinct target selectors. Publish keys or provider aliases, enable signing, and send through every route. Verify a valid signature and DMARC alignment in received headers.

Retain old selectors during the retry, delayed-delivery, forwarding, archive, and residual-traffic window. Premature deletion can make delayed messages unverifiable.

### DMARC

DMARC evaluates the visible author domain against aligned authenticated identifiers. SPF or DKIM pass alone is not necessarily DMARC pass.

Preserve:

- valid policy discovery;
- target-route alignment;
- aggregate report receipt;
- external reporting authorization where required;
- organizational-domain understanding;
- current enforcement intent.

RFC 9989, published in 2026, obsoletes RFC 7489 and RFC 9091. Do not weaken enforcement merely because the target route was not configured correctly. Use reports and test headers to repair legitimate alignment.

### Branded routing and tracking

Validate custom return paths, tracking domains, CNAMEs, HTTPS certificates, redirects, query preservation, branded links, reply mailboxes, and alignment.

Tracking changes can break links, alter analytics, trigger security controls, or expose unfamiliar recipient-facing hosts. Test final delivered URLs and redirect chains.

### Dedicated infrastructure

For dedicated IPs or new pools, confirm:

- assigned addresses;
- forward and reverse DNS;
- matching HELO identity;
- TLS;
- ownership and escalation;
- pool separation;
- rate and concurrency limits;
- expected daily frequency;
- ramp guardrails;
- transactional capacity.

A DNS pass does not establish reputation. Reputation develops from real traffic, history, volume stability, recipient engagement, complaints, and receiver-specific observations.

### Unsubscribe

Marketing and subscription messages need a clear body unsubscribe experience. Bulk subscription traffic to major mailbox providers may also need one-click unsubscribe.

RFC 8058 requires an HTTPS URI in List-Unsubscribe, the List-Unsubscribe-Post field, and a valid DKIM signature covering those fields. Test a receiver-style POST, token scope, no unwanted redirect, suppression timing, queue cancellation, and the next attempted send.

The unsubscribe landing page and RFC 8058 POST serve different interactions. A preferences page alone does not implement one-click.

### Contacts and suppressions

Suppression state moves before sendable contacts. Preserve reason, scope, timestamp, source, and provenance. Reconcile source and target counts and test blocked sends.

Map contact fields with explicit types and rules for:

- null versus empty;
- dates and time zones;
- booleans;
- numbers;
- arrays;
- case normalization;
- duplicate keys;
- defaults;
- invalid values;
- rejected rows;
- consent version;
- source timestamps.

Do not silently coerce ambiguous dates or consent. Keep source exports immutable and produce a transformation ledger.

### Event contract

Normalize provider-specific events behind an internal contract. Define:

- stable event ID;
- message and recipient correlation;
- event type and subtype;
- provider timestamp and received timestamp;
- signature verification;
- retry and timeout;
- ordering expectations;
- deduplication key;
- terminal-state precedence;
- dead-letter handling;
- retention;
- privacy and redaction.

Providers can retry, duplicate, delay, and reorder events. Consumers must be idempotent.

## Phase 3: parallel validation

Parallel validation proves target behavior before meaningful production volume.

### Seed matrix

Send to representative webmail, desktop, mobile, regional, and corporate recipients. Inspect normal and dark mode, images blocked, text alternatives, forwarded messages, encoding, links, accessibility, and final raw source.

Provider previews are useful but do not show the entire delivery path.

### Authentication and headers

Inspect Received, Authentication-Results, SPF, DKIM-Signature, DMARC, return path, Message-ID, List headers, and tracking transformations for every target route.

Verify:

- target provider and IP path;
- intended envelope domain;
- valid signature;
- alignment;
- TLS evidence;
- no unexpected source-provider route;
- no malformed From field;
- expected unsubscribe coverage;
- expected link and reply identity.

### Template acceptance

Test active templates and automations for:

- subject and preheader;
- encoding;
- HTML and text alternatives;
- responsive layout;
- dark mode;
- accessibility;
- localization;
- fallback variables;
- escaping;
- date, number, and currency formatting;
- conditional content;
- assets;
- links and tracking;
- footer and address;
- unsubscribe;
- message size;
- provider-added content.

Record acceptance per asset. A sample of one template cannot establish that a catalog migrated correctly.

### Suppression end to end

Create unsubscribe, complaint, permanent failure, and manual block test states. Observe the complete event path into the authoritative store. Attempt sends through every application, queue, batch import, campaign, automation, and vendor route.

A suppression row visible in the target UI is not enough if another producer bypasses it.

### Webhook replay and outage

Test:

- valid and invalid signatures;
- endpoint timeout;
- non-2xx responses;
- provider retry;
- duplicate event;
- out-of-order event;
- delayed terminal event;
- malformed payload;
- schema version change;
- poison message;
- dead-letter replay;
- alert and recovery.

Preserve golden payloads and make replay safe.

### Transactional idempotency

Provider migration increases duplicate risk because applications retry after timeouts and teams may temporarily configure failover.

Use stable idempotency keys or a durable internal send record. Distinguish:

- request accepted;
- provider accepted;
- message delivered;
- request response lost;
- provider timeout;
- application retry;
- intentional failover.

Never dual-send critical transaction messages without a design that prevents duplicates and silent loss.

### Analytics continuity

Map source and target definitions for accepted, delivered, open, click, conversion, unsubscribe, complaint, bounce, and revenue.

Differences can come from bot filtering, unique-event logic, privacy proxies, attribution windows, event time zones, redirect domains, or delayed ingestion. Document expected discontinuities before cutover.

## Phase 4: ramp and cutover

### Low-risk production cohort

Start with a small, permissioned, representative cohort. Keep audience, content, identity, and measurement stable so route behavior is observable.

Record:

- cohort query;
- expected and actual count;
- target route;
- planned and actual time;
- received headers;
- delivery and engagement metrics;
- event completeness;
- guardrails;
- decision and approver.

### Receiver-aware ramp

Increase by stream and major mailbox provider. Global averages can hide a severe problem at one receiver.

Monitor:

- temporary and permanent failure codes;
- deferral rate and duration;
- accepted versus delivered;
- complaint rate;
- unsubscribe rate;
- authentication;
- queue age;
- API errors;
- transactional latency;
- click and conversion;
- support contacts.

Google's sender guidance recommends increasing volume gradually and monitoring recipient feedback. A schedule should adapt to observed behavior; it is not a promise to reach full volume on a predetermined date.

### Change freeze and go/no-go

Freeze unrelated changes to identity, DNS, templates, audiences, integrations, and release infrastructure. Otherwise, migration attribution becomes difficult and rollback may not restore the previous state.

The final evidence pack should include:

- scope and owners;
- inventory;
- current and target identity;
- DNS changes;
- authentication headers;
- suppression tests;
- integration tests;
- template acceptance;
- ramp ledger;
- metric baseline;
- open risks;
- rollback rehearsal;
- staffing and communication;
- signed decision.

### Rollback rehearsal

A rollback plan needs:

- decision authority;
- objective trigger thresholds;
- exact routing and DNS changes;
- queue pause and release behavior;
- duplicate prevention;
- suppression authority;
- event reconciliation;
- communication;
- estimated recovery time;
- verification after rollback.

Exercise it. A document that has never been timed or executed may omit permissions, stale configuration, missing data, or irreversible steps.

### Cutover execution

Use one migration commander and explicit stop/go checkpoints.

Immediately before change:

1. Confirm target and source provider status.
2. Refresh recipient eligibility and suppression.
3. Inspect in-flight and scheduled source work.
4. Confirm staff and escalation contacts.
5. Confirm rollback remains viable.
6. Record baseline dashboards.

During change:

1. Pause unsafe producers or queues.
2. Apply approved routing changes.
3. Send controlled verification traffic.
4. Inspect received headers and events.
5. Resume traffic in stages.
6. Timestamp every decision and deviation.

After change:

1. Watch receiver-level behavior.
2. Reconcile counts.
3. Confirm transactional latency.
4. Confirm unsubscribe and complaints.
5. Confirm queues and retries.
6. Communicate state.

## Phase 5: stabilize and retire

### Boundary reconciliation

Messages and events cross the cutover boundary at different times. Reconcile:

- queued but not submitted;
- submitted but not accepted;
- accepted but not delivered;
- deferred and retried;
- bounced later;
- complained later;
- unsubscribed;
- clicked and converted later;
- duplicate requests;
- duplicate events;
- missing events.

Keep old event intake available through the defined late-event window.

### Stabilization

Compare the new system with the pre-migration baseline. Explain population and definition differences. Do not close the source while material unexplained degradation remains.

Track cost as well as delivery. A provider move can change event storage, data warehouse volume, link handling, support workload, and engineering ownership.

### Prove zero residual traffic

Query:

- source provider logs;
- API and SMTP usage;
- application configuration;
- scheduled campaigns;
- automations;
- retries;
- background jobs;
- DNS;
- vendors;
- inbound events.

Define an observation period appropriate to retry and scheduling behavior. “We think it is unused” is not retirement evidence.

### Remove authorization and access

Once residual traffic and rollback need are zero:

- remove old SPF mechanisms;
- remove old DKIM selectors after verification windows;
- remove obsolete tracking and return-path DNS;
- revoke API and SMTP secrets;
- disable webhooks;
- remove roles and service accounts;
- close firewall access;
- test the target route again.

Leaving old authorization expands the impersonation and compromise surface.

### Archive and contract closure

Before access or retention expires, export required:

- consent and suppression;
- raw campaign and delivery logs;
- templates and assets;
- automation definitions;
- event exports;
- invoices;
- audit records;
- provider support cases;
- DNS and identity evidence.

Record integrity, retention, owner, deletion requirement, and legal hold. Then adjust or close the contract and verify billing.

### Post-migration review

Publish outcomes, incidents, assumptions, metric discontinuities, costs, accepted debt, and follow-up work. Update diagrams, runbooks, data contracts, access reviews, alert ownership, and the new steady-state baseline.

## Due dates and dependencies

Each control has a default offset from cutover. Inventory begins roughly ten weeks before, foundation roughly seven weeks before, parallel validation roughly one month before, ramp in the final weeks, and retirement after stabilization.

These are planning defaults, not universal minimums. A high-volume dedicated-IP migration, complex journey rebuild, regulated environment, or weak data foundation may require months. A narrow API transport change can be shorter.

The as-of date makes overdue calculation explicit. The board does not use the viewer's hidden clock.

Dependencies prevent a downstream check from appearing ready when its prerequisite lacks owned proof. For example:

- DMARC observability depends on target SPF and DKIM work;
- target header validation depends on authentication foundation;
- production ramp depends on header, suppression, and limit validation;
- cutover depends on freeze and rollback;
- credential retirement depends on zero residual source traffic.

## Evidence quality

Strong proof is reproducible and tied to the exact route.

Examples:

- raw delivered header with timestamp and seed recipient;
- recursive DNS trace;
- source and target reconciliation export;
- signed mapping specification;
- webhook replay result;
- provider limit confirmation;
- ticket containing command output and approver;
- screenshot plus machine-readable payload;
- observed zero-traffic query over a defined window;
- timed rollback rehearsal.

Weak proof includes:

- “configured”;
- “looks good”;
- an undocumented screenshot;
- a provider dashboard without route identity;
- a check performed before the latest change;
- a passing source message used as evidence for the target.

Evidence notes may contain internal domains, owners, architecture, and incident details. Review exports before sharing.

## Export formats

The brief summarizes scope, cutover and as-of dates, evidence state, cutover gates, and prioritized next actions.

CSV contains every control, including applicability, phase, priority, status, readiness, owner, due date, overdue flag, missing evidence, proof, required evidence, action, and unmet dependencies.

JSON contains program scope, model boundary, summary, gates, phases, controls, sources, related tools, and evidence state. It is suitable for versioned change records or internal dashboards.

## Frequently asked questions

### How long does an email-provider migration take?

Scope, identity changes, dedicated infrastructure, contacts, event consumers, templates, automations, volume, risk, and acceptance requirements determine the timeline. The evidence should determine the date, not the reverse.

### Should the SPF record be replaced at cutover?

Usually not. Maintain one coherent policy that authorizes active old and new envelope routes during coexistence. Remove obsolete authorization only after residual traffic is zero.

### Can the old and new provider send simultaneously?

Yes, when identity, volume, suppression, measurement, and idempotency are designed for it. Uncontrolled coexistence can double-send, spike volume, fragment metrics, and bypass suppression.

### Must the visible From domain change?

No. Keeping a familiar From identity can preserve recognition. The technical route can change underneath it when authentication and alignment are configured correctly.

### What data should migrate first?

Protect authoritative suppression and consent before the target can send to imported contacts.

### Does sender reputation transfer?

Reputation is observed by receivers across domains, IPs, authentication, traffic, history, and recipient response. A new provider or IP route does not inherit every property of the old path. Stable identity and a controlled ramp can preserve useful continuity, but no provider can guarantee a reputation transfer.

### Should DMARC enforcement be lowered during migration?

Not as a substitute for correct configuration. Preserve reporting, find every legitimate route, and align target authentication. Any temporary policy change requires explicit risk ownership and restoration criteria.

### When can old DKIM selectors be removed?

After old sending has stopped and the relevant delayed-delivery, retry, forwarding, archive, and verification window has passed.

### What should trigger rollback?

Predeclared thresholds for authentication failure, deferrals, complaints, bounce codes, event loss, queue age, duplicate transactions, latency, or business harm. Define authority and response before cutover.

### When can the source provider be closed?

After in-flight queues, retries, schedules, application routes, vendors, and late events are proven quiet; the stabilization period is accepted; required data is archived; and rollback no longer needs the source.

### Does the tool change production systems?

No. It is a local planning and evidence board. Every external action requires execution in owned systems under the organization's change process.

## Primary standards and provider references

- [Gmail email sender guidelines](https://support.google.com/mail/answer/81126?hl=en)
- [Gmail sender guidelines FAQ](https://support.google.com/a/answer/14229414?hl=en)
- [Yahoo Sender Hub best practices](https://senders.yahooinc.com/best-practices/)
- [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 6376: DomainKeys Identified Mail](https://www.rfc-editor.org/rfc/rfc6376.html)
- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html)
- [RFC 5322: Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322.html)

## Related Email Bump tools and guidance

- [Email deliverability readiness audit](https://emailbump.com/tools/email-deliverability-readiness-audit.md)
- [Email warmup calculator and ramp planner](https://emailbump.com/tools/email-warmup-calculator.md)
- [DNS propagation checker](https://emailbump.com/tools/dns-propagation-checker.md)
- [SPF record checker](https://emailbump.com/tools/spf-record-checker.md)
- [DKIM record checker](https://emailbump.com/tools/dkim-record-checker.md)
- [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder.md)
- [Email header analyzer](https://emailbump.com/tools/email-header-analyzer.md)
- [List-Unsubscribe header generator](https://emailbump.com/tools/list-unsubscribe-header-generator.md)
- [Email accessibility checker](https://emailbump.com/tools/email-accessibility-checker.md)
- [Email blacklist checker](https://emailbump.com/tools/email-blacklist-checker.md)
- [Sending-domain documentation](https://emailbump.com/docs/domains.md)
- [Transactional API documentation](https://emailbump.com/docs/transactional-api.md)
- [Deliverability documentation](https://emailbump.com/docs/deliverability.md)
- [Contacts and segments documentation](https://emailbump.com/docs/contacts.md)