WordPress
Do not break email when moving a WordPress domain
Separate web DNS from mail records and test forms, transactional delivery and SPF/DKIM during a WordPress move.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Changing the website A/AAAA or CNAME record does not require replacing MX, SPF, DKIM or DMARC records. Copy the whole zone carefully, change only intended web records, and verify both mailbox delivery and WordPress transactional mail after cutover.
What this means in plain English
Website and email DNS records do different jobs. A or CNAME records normally point web visitors to hosting. MX records route incoming email, while SPF, DKIM and DMARC help other mail systems trust messages.
When changing website hosting or nameservers, copy the complete DNS zone and change only intended web records. Test mailbox delivery and WordPress messages such as form confirmations separately.
Which DNS records should remain unchanged?
| Website | A/AAAA/CNAME records for web host |
|---|---|
| Mail routing | MX records |
| Mail authentication | SPF, DKIM and DMARC TXT records |
A simple example
A business moves its website and replaces nameservers without copying MX records. The new site opens, but staff stop receiving email. A record-by-record migration would have kept mail routing unchanged while moving only the website.
What to do, step by step
1. Export or inventory the current DNS zone.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on website: a/aaaa/cname records for web host. Write the result down so you can compare it later.
2. Identify which provider owns each record.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Change web records narrowly.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Test inbound mailbox and application form delivery.
Finish by checking the result against mail authentication: spf, dkim and dmarc txt records. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
A form success screen proves only that WordPress accepted the form. Check that the message reaches the mailbox and does not land in spam.
Common mistakes and how to avoid them
Replacing nameservers without copying mail records.
This gives a misleading or unsafe result because it leaves out website. A better approach is to export or inventory the current dns zone, then check the result before making the change permanent.
Creating multiple conflicting SPF records.
This gives a misleading or unsafe result because it leaves out mail routing. A better approach is to identify which provider owns each record, then check the result before making the change permanent.
Testing forms only by showing a success message.
This gives a misleading or unsafe result because it leaves out mail authentication. A better approach is to change web records narrowly, then check the result before making the change permanent.
Words explained
- WordPress
- A content management system that lets people edit pages and posts through an administration screen.
Quick checklist
- Export or inventory the current DNS zone.
- Identify which provider owns each record.
- Change web records narrowly.
- Test inbound mailbox and application form delivery.
Common questions
What is the simple answer?
Changing the website A/AAAA or CNAME record does not require replacing MX, SPF, DKIM or DMARC records. Copy the whole zone carefully, change only intended web records, and verify both mailbox delivery and WordPress transactional mail after cutover.
What should I check first?
Start with website: a/aaaa/cname records for web host. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Export or inventory the current DNS zone. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Replacing nameservers without copying mail records. Avoiding that one mistake makes the rest of the comparison much more trustworthy.