WordPress email cutover checklist

Use this worksheet to coordinate one WordPress site's business email move between mail providers. Record values and outcomes from the provider accounts and DNS console you control. This page stores no checklist state and does not query DNS, send messages, or verify delivery.

Record the change

Inventory and prepare both sides

• List every address, alias, forwarder, shared mailbox, distribution group, and service sender. Mark which need a destination account and who owns each one.
• Confirm the destination mailboxes and permissions exist; verify the selected provider's migration method, credentials, limits, and expected handling of folders, calendars, contacts, and sent items.
• Save a copy of the current DNS zone and record each mail-related hostname, record type, value, priority, and TTL before editing anything.
• Record the current MX destination(s). Copy the destination provider's exact MX values and priorities from its account instructions; do not infer them from another provider's example.
• Inventory every system that sends as this domain, including WordPress form/commerce mail, transactional services, support tools, and staff mailboxes.
• Review the current SPF policy and all authorized senders. Prepare one provider-approved SPF policy that accounts for every sender; avoid publishing multiple SPF policies for the same name.
• Generate or obtain destination DKIM selector and TXT/CNAME values from the destination provider. Record selector names and the provider's signing-activation status.
• Record the DMARC policy and reporting address. Check that planned SPF/DKIM sender alignment is understood before changing policy; preserve existing policy unless the mail owner approves a change.
• Decide whether and when to lower MX TTL using the DNS provider's guidance. Record the old and planned TTL and allow for caching; a TTL change cannot force all resolvers to update immediately.

Copy and test before changing mail routing

• Run the chosen mailbox migration or copy process and record the provider's completion/errors for each account. A data copy does not switch new inbound delivery.
• Confirm whether a final sync or delta copy is needed near cutover, and who will run it. Agree how users should avoid or reconcile changes made during the transition.
• Configure representative desktop/mobile mail clients with the destination provider's current server, authentication, and security settings. Do not reuse guessed settings.
• Send a test from an external account to a destination mailbox and reply to an external account. Record sender, recipient, time, result, and any bounce or spam-folder observation.
• Test WordPress and each inventoried application sender separately. Confirm its configured SMTP/API service and From address with the owner; do not assume website mail follows mailbox MX routing.
• Confirm the destination provider reports DKIM enabled for the intended domain and review its current authentication guidance for SPF and DMARC. Record observed evidence and time; this checklist does not perform authentication tests.

Cut over and observe

• Confirm the go/no-go owner, maintenance message if needed, rollback trigger, decision deadline, and support route. Keep source mailboxes and access available during the agreed transition.
• Apply only the provider-documented DNS changes that are approved for this domain. Record each change, prior value, new value, editor, and timestamp, including MX and any SPF/DKIM/DMARC updates.
• Check inbound mail from more than one external sender and outbound replies from representative destination mailboxes. Record outcomes and exact times.
• Check WordPress form/commerce and other application messages after cutover. If messages fail, record the app/service and error and use its provider's mail configuration guidance.
• Ask users to sign in to the destination and check recent, older, sent, and required folders; confirm mobile/desktop clients use the intended account.
• Monitor both providers and the DNS provider during the transition. Keep the source service until the owner confirms delivery, data, and application checks are acceptable under the migration plan.

Rollback record

• Confirm the rollback route with both providers and note whether restoring DNS alone is sufficient for this setup.
• Define how to prevent lost or split mail if routing is reversed, including any required resync and how users will be told which mailbox to use.
• Record final sign-off and the time the source mail service can be retired under the provider's retention and account terms.

0 checklist items checked.

Sources checked November 3, 2026

• RFC 5321: Simple Mail Transfer Protocol — SMTP transport and mail routing concepts; it does not define a universal provider migration procedure.
• RFC 7208: Sender Policy Framework (SPF) — SPF policy syntax and evaluation, including the requirement for a single SPF record per domain name.
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — DKIM signing and selector-based DNS key lookup.
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — current DMARC standard, published May 2026, and its relationship to SPF/DKIM identifiers.
• Microsoft Learn: Cutover migration to Exchange Online — provider-specific migration sequence, including pointing MX to the destination after migration. Follow the instructions for the actual source and destination providers instead.

Migration behavior, record values, mailbox features, and DNS timing depend on the selected providers and domain configuration. This worksheet records your own checks; it does not read accounts, query DNS, validate SPF/DKIM/DMARC, test delivery, migrate mail, or provide a universal rollback guarantee. For website files, URLs, and broader infrastructure tasks, use the site migration checklist; for mailbox copy-time arithmetic, see the mailbox migration transfer-time planner.