Email Migration Checklist: MX, SPF, DKIM, and DNS Records

During website migration, email services are the most commonly overlooked component. The fact that “the website is accessible” often leads to a false sense of completion, while email issues typically surface days later (e.g., undelivered messages or outgoing emails flagged as spam).

The following items must be included in your pre-migration checklist.

First, Identify Where Your Email Service Resides

# Check MX records to identify the email service provider
dig +short example.com MX

# Check all email-related records
dig +short example.com TXT
dig +short default._domainkey.example.com TXT

The first scenario is the easiest: if email is not hosted on your servers, migrating the website does not affect email delivery, provided you do not accidentally delete DNS records.

Records That Must Be Verified

MX Records

# View current MX records
dig example.com MX +short
dig example.com MX | grep -A2 'ANSWER SECTION'

# Priority: Lower numbers indicate higher priority
# Example: 10 mail.example.com.

Key Considerations During Migration

• The hostname pointed to by MX must resolve correctly (it cannot be a CNAME; MX should point to A/AAAA records).
• If MX points to a hostname on the old server that is being decommissioned, you must update MX or retain that host.
• MX TTL should be reduced in advance; otherwise, there will be delays in receiving mail after the switch.

# Confirm the MX target resolves correctly
dig +short mail.example.com A
# If it returns empty or points to an old IP, action is required

SPF

# View SPF records
dig +short example.com TXT | grep -i spf

Common SPF record format:
v=spf1 include:email-provider include:spf.example.com ~all

Meaning:
- include: Authorizes specific servers to send mail on behalf of this domain
- ~all or -all: Policy for handling servers not listed

The Most Commonly Overlooked Item

If your website sends its own emails (registration confirmations, notifications), the new server’s IP must be included in the SPF record. Failing to update SPF after changing servers will result in many outgoing emails being flagged as spam.

# Confirm if the new server's IP is covered by SPF
dig +short example.com TXT | grep -i spf
# Compare with the new server's public IP to see if it is covered by any include directives

# Check current public outbound IP
curl -s ifconfig.me

DKIM

# DKIM uses TXT records; selectors vary
dig +short default._domainkey.example.com TXT
dig +short selector1._domainkey.example.com TXT

# If you don't know the selector name, check the configuration provided by your email service provider

The DKIM selector name is determined by the sender. You must retrieve it from the original configuration during migration; do not guess.

Key Points

• DKIM records are independent of the server and tied to the sending domain—as long as domain resolution remains intact, they usually do not need changes.
• However, if you run a self-hosted email server, the keys reside on the server. You must migrate the keys along with the service.
• After migration, send test emails to verify that signatures pass validation.

# Verification method: Send an email to an external mailbox and check the raw email headers for
# DKIM-Signature and Authentication-Results

Verification Checklist

# Verify each item post-migration
dig +short example.com MX                              # Receiving server
dig +short example.com TXT | grep -i spf               # Sending authorization
dig +short default._domainkey.example.com TXT           # DKIM
dig +short _dmarc.example.com TXT                      # DMARC

Verification Key Points:
Send a test email to an external mailbox and check the "Raw Message/Original Email" for:
  Authentication-Results: ... spf=pass ... dkim=pass ... dmarc=pass
All three must show "pass" for the configuration to be considered correct.

Decision Tree

Handling Email During Migration
├─ First, confirm where the email service resides
│  ├─ Third-party Enterprise Email → Just keep DNS unchanged (don't delete records)
│  └─ On Old Server → Need to migrate the service itself
├─ Must Verify
│  ├─ MX (Missing this means no incoming mail)
│  ├─ SPF (If site sends mail, new IP must be included) ← Most easily missed
│  ├─ DKIM (Self-hosted servers must migrate keys)
│  └─ DMARC
├─ Before Switch
│  └─ Reduce MX TTL in advance
└─ Post-Migration Verification
   ├─ Test one send and one receive
   └─ Check raw email headers to ensure spf/dkim/dmarc are all pass

Scenario Walkthrough: Emails Bounced After Migration

Symptom: After migrating email services to a new provider,
a large proportion of sent emails are bounced back, with recipient feedback indicating failed identity verification.

1. Examine the specific reason given in the bounce message →
   Bounce messages usually specify which validation failed, so no guessing is needed.
2. Verify the three identity-related records →
   The list of servers allowed to send on behalf of the domain, the public key record used for signing,
   and the policy record defining how to handle validation failures are the three most commonly missed.
3. Confirm all records required by the new provider are active →
   New DNS records take time to propagate; use query tools to confirm rather than relying on “saved” status.
4. Confirm Reverse DNS (PTR) is configured →
   Some recipients verify consistency between the sending address and reverse DNS; this is often overlooked.
5. Run a comprehensive score using diagnostic tools →
   External testing services provide an overall assessment that closely mirrors recipient-side judgment.
6. Warm up the sending volume for the new domain → Sudden high-volume sending is treated as anomalous behavior.
   Start with small volumes and increase gradually.

# Verify the three records one by one (new providers usually provide the content to add)
dig domain.com TXT +short
dig selector._domainkey.domain.com TXT +short
dig _dmarc.domain.com TXT +short

# Reverse DNS: Confirm reverse record for the sending IP
dig -x sending_IP +short

# Connectivity and Ports (some networks block outbound sending ports)
nc -zv mail_server_address 465 -w 3
nc -zv mail_server_address 587 -w 3

Root Cause: During migration, only accounts and data were moved,
without synchronizing the DNS records related to sending identity, causing recipients to be unable to verify the source.

Two Key Takeaways:

• The key to email migration lies not in accounts, but in the three DNS records on the domain.
  Without them, recipients will directly deem the source untrustworthy.
• Start with low sending volumes when using a new environment.
  Sudden bulk outbound mail is likely to be flagged as anomalous behavior by receivers.

8 Common Pitfalls

1. Accidentally deleting MX records during migration: Results in inability to receive mail.
2. Failing to update SPF after changing servers: Outgoing emails go to spam.
3. Pointing MX to a CNAME: Non-compliant with standards.
4. Not reducing MX TTL in advance: Delays in receiving mail after switching.
5. Failing to migrate DKIM keys for self-hosted servers: Signature verification fails.
6. Assuming everything is fine without verification: Email failures are silent; proactive testing is required.
7. Focusing only on sending, not receiving: Both directions must be tested.
8. Forgetting that the website itself sends mail: Notification emails are also affected.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar IT operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (providers include our store and competitors, provided here solely for reference based on genuine feedback, not fictional tickets):

1****n Rating: 5.0 Jan 04, 2018 18:04

45***76 Apr 14, 2021 5.0 Delivered on time. Excellent.

10***02 Jul 31, 2024 5.0 Secure & Reliable | Comprehensive Features | Affordable Price Timely processing, migration successful. 10***31 Jun 22, 2022 5.0 Affordable Price | Skilled Technical Support | Perfect After-sales Service Good job, helped me migrate my years-old site to a new server.