Fix Email After a DNS Migration

The homepage loads. Certificates are green. Customers still say “we emailed you yesterday.” That pattern almost always means the migration updated web DNS (A/AAAA/CNAME) and left mail DNS (MX, SPF, DKIM, DMARC) or reverse DNS behind. This playbook is the order we use when diagnosing that failure with sky-ai.my tools.

1. Confirm the symptom class

Run a Website Health Check on the exact domain customers use (apex vs www usually share MX at the apex). Note priority findings related to mail before changing anything else.

2. Verify MX points at the live mail system

Open MX Validator (or DNS Lookup → MX). You want:

If MX still names the old shared host, restore provider MX first — do not “fix” SPF yet. Mail cannot authenticate its way around a dead exchanger.

3. Align SPF with every real sender

List everything that sends as @yourdomain: mailbox provider, transactional app (Shopify, billing, helpdesk), marketing ESP, and any legacy server. Encode them in a single SPF TXT at the apex (or the exact name your provider requires).

Watch the 10 DNS-lookup limit. Long include: chains produce permerror, which receivers treat as failure. Prefer flattening only when you understand the trade-offs, or drop unused includes.

Check the published record with DNS Lookup (TXT). Compare to what you edited in the DNS panel — registrar UI typos are common.

4. Confirm DKIM and turn on DMARC gradually

Each sender should publish its DKIM CNAMEs/TXT as documented. Send a test to an external inbox and inspect headers for dkim=pass.

Publish DMARC at _dmarc.yourdomain starting with p=none and a rua mailbox you monitor, then move to quarantine/reject once pass rates look healthy. Deep dive: SPF, DKIM & DMARC.

5. Check reverse DNS on the sending IP

If you send from a VPS or dedicated IP (not only Workspace/M365), PTR must exist and should align with the hostname you present in SMTP. Use Reverse IP Lookup on the outbound address. Generic PTR values from the host are a frequent spam-folder cause after IP reassignment.

6. Wait on TTL — then prove convergence

Changing MX in the panel is not the same as the world seeing it. Note the old TTL before you edit. Use DNS Propagation to compare major resolvers. If one network still has old MX, that network will keep bouncing until cache expires — telling the customer to “try again” without checking propagation wastes everyone’s afternoon.

7. Re-run the health check and send real tests

After propagation looks consistent:

  1. Re-run Website Health Check
  2. Send tests from each sender (mailbox UI, app, ESP) to Gmail and at least one other provider
  3. Confirm SPF/DKIM/DMARC pass in message headers

Keep a short written record of the final MX and SPF values. The next migration will try to drop them again.

Prevention checklist for the next move

Related: Post-Migration Checklist, How We Grade Website Health, DNS, Email & SSL Checklist.

Validate MX now