DNS Migration QA Checklist for Agencies Moving Client Domains

A DNS migration QA checklist helps agencies confirm that websites, email, SSL, verification records, CAA, and public metadata still work after changing hosting, DNS providers, registrars, or nameservers. The point is not to make DNS migration complicated. The point is to avoid losing important records while everyone is focused on launch day.

Most DNS migration failures are not exotic. They are missed MX records, stale nameservers, forgotten TXT records, old CAA policy, broken www, missing verification records, or confusion about which provider is authoritative. A checklist gives the agency a repeatable process.

Use the single-domain health check for focused post-migration checks and the 10-domain agency audit when several client domains need review. Use Inbox Pulse for email-authentication records, 47-Day Pre-Flight for CAA and ACME readiness, and Client Website Trust Check for public trust signals. For public-check methodology and limitations, see how CertPilot checks domains.

Quick answer: DNS migration QA checklist

A DNS migration QA checklist should cover:

• access and ownership
• nameservers
• A and AAAA records
• CNAME records
• MX records
• TXT records
• CAA records
• SSL and ACME expectations
• website redirects
• public trust signals
• rollback plan
• client handover notes

Do not treat the website loading as the only success signal. Email, verification, and SSL workflows may be affected even when the homepage works.

When agencies need a DNS migration checklist

Use a checklist when:

• moving website hosting
• changing DNS providers
• changing nameservers
• transferring registrars
• onboarding Cloudflare or another CDN
• moving email providers
• launching ecommerce
• moving client care plans from another vendor
• cleaning up old DNS records
• preparing for SSL renewal changes

The checklist is especially important when the agency does not control every system involved.

Before migration: inventory and access

Before changing anything, capture the current state.

Document:

• registrar
• current nameservers
• DNS provider
• admin access owner
• full DNS zone export or screenshots
• website host
• CDN status
• email provider
• active senders
• certificate provider
• CAA policy
• verification records
• rollback nameservers and values

Use DNS record inventory for agencies as the operating model.

During migration: TTLs, records, and provider changes

During migration, make deliberate changes. Do not rebuild DNS from memory.

Key steps:

• lower TTLs in advance where appropriate
• create records in the new zone before switching nameservers
• copy A, AAAA, CNAME, MX, TXT, NS, and CAA records intentionally
• keep record purpose labels
• avoid adding duplicate SPF records
• preserve DKIM selector hostnames
• preserve verification records unless confirmed stale
• compare old and new zones before cutover

After migration: website records

Check:

• root domain resolution
• www behavior
• important subdomains
• redirects
• CDN proxy state if used
• HTTPS certificate validity
• canonical production hostname
• old host no longer receiving unintended traffic

Use Client Website Trust Check when the migration affects public HTTPS, headers, CAA, or well-known files.

After migration: email records

Check:

• MX records
• SPF
• DKIM selectors
• DMARC policy
• MTA-STS marker and policy host
• TLS-RPT
• BIMI if used
• provider verification records

Use Inbox Pulse for a public configuration audit. For deeper email-authentication context, see DMARC, SPF, and DKIM for agency operations.

After migration: CAA and SSL readiness

CAA records can affect certificate issuance. If a domain moves DNS providers and CAA is missed, renewal or issuance may behave differently later.

Check:

• whether CAA exists
• which CAs are allowed
• whether wildcard issuance is expected
• whether the current certificate provider is allowed
• whether ACME validation depends on HTTP-01 or DNS-01

For deeper SSL readiness, use CAA records and 47-day SSL for agencies and CAA record client SSL renewals.

After migration: public trust signals and metadata

If the DNS migration coincides with hosting or CDN changes, also check:

• HTTPS redirect behavior
• TLS certificate status
• HSTS and other header hygiene
• robots.txt
• sitemap.xml
• security.txt if used
• public redirects

Use the client website trust signals guide for public trust-signal context.

Client handover notes

The client handover should explain:

• what changed
• who owns DNS now
• where DNS is edited
• what records were verified
• what remains unknown
• what should not be changed without approval
• who handles emergencies
• when the next review happens

Avoid handing over only a DNS export. The useful artifact is the decision record.

Rollback planning

Rollback planning should happen before cutover. Keep:

• old nameservers
• old record values
• old provider access details
• previous MX and TXT records
• expected TTLs
• contact list
• rollback approval owner

Rollback is not always instant because DNS caching exists. Still, having the old state documented reduces confusion.

Migration QA table

| Migration phase | What to check | Tool/check | Failure to avoid | |---|---|---|---| | Before migration | DNS inventory, access, old values | Provider export and public DNS check | Rebuilding DNS from memory | | During migration | Zone parity and nameserver target | Old vs new zone comparison | Missing MX/TXT/CAA records | | After website cutover | A, AAAA, CNAME, HTTPS, redirects | Health check and browser review | Homepage works but subdomains fail | | After email review | MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT | Inbox Pulse and mail platform review | Email auth silently changes | | After SSL review | Certificate, CAA, ACME path | Pre-Flight and certificate check | Renewal surprise after launch | | Handover | Owner, provider, rollback, unresolved items | Client note | Nobody knows who controls DNS |

Step-by-step DNS migration QA checklist

1. Confirm registrar and current nameservers.
2. Export old DNS zone.
3. Identify website, email, TXT, and CAA records.
4. Label unknown records.
5. Build new DNS zone.
6. Compare old and new records.
7. Confirm email provider records.
8. Confirm certificate-authority expectations.
9. Confirm verification records.
10. Switch nameservers or records during the agreed window.
11. Recheck root, www, and important subdomains.
12. Recheck MX and TXT records.
13. Recheck CAA and SSL status.
14. Review propagation context before escalating alerts.
15. Send handover notes to the client and internal team.

How CertPilot supports post-migration review

CertPilot checks public DNS, SSL, and domain data. It can help agencies review the public state after migration, notice unexpected changes, and create client-facing proof around what was checked.

CertPilot does not manage DNS hosting, change records, move nameservers, or replace provider QA. Use it as visibility and reporting support.

Related Resources

• DNS record inventory for agencies
• Nameserver change monitoring for agencies
• DNS propagation false positives for agencies
• TXT record monitoring for agencies
• Client website trust signals guide

Frequently Asked Questions

What is a DNS migration QA checklist?

A DNS migration QA checklist is a repeatable process for confirming that important records and services still work after moving DNS, hosting, registrars, nameservers, or providers. It covers website records, email records, CAA, verification records, redirects, SSL, public trust signals, and handover documentation.

What breaks most often during DNS migrations?

The common failures are missing MX records, duplicate or missing SPF records, lost DKIM selectors, missing DMARC, stale CAA records, wrong www behavior, forgotten verification TXT records, and unclear nameserver ownership. These are usually process misses rather than complex DNS problems.

Should agencies lower TTL before a DNS migration?

Often yes, but it depends on the migration and provider behavior. Lowering TTL in advance can reduce caching windows for some changes, but it does not force every resolver to update instantly. Agencies should plan TTL changes early and document expected propagation behavior.

How should agencies check email after DNS migration?

Review MX, SPF, DKIM selectors, DMARC, MTA-STS, TLS-RPT, and relevant verification records. Use Inbox Pulse for a public configuration check, then confirm important senders in the relevant mail or marketing platforms when access is available. Do not assume the website working means email is correct.

Why check CAA during DNS migration?

CAA can affect which certificate authorities may issue certificates for the domain. If CAA is missed or copied incorrectly during a DNS migration, SSL issuance or renewal can fail later. Agencies should compare CAA records with the certificate provider and ACME workflow.

Can CertPilot perform the DNS migration?

No. CertPilot checks public DNS, SSL, and domain signals. It does not move DNS zones, change nameservers, edit records, or manage DNS providers. Agencies should use CertPilot for visibility and reporting while the actual migration remains with the responsible operator.