How to Audit a Domain Before a Website Migration

Why a pre-migration domain audit matters

Moving a website is rarely just a matter of copying files to a new server.

A domain may depend on several separate services, including its registrar, DNS provider, website host, email platform, CDN, SSL certificates, verification records and third-party applications. Changing one part of that infrastructure without understanding the rest can leave the website unavailable, break email delivery, invalidate DNSSEC or remove records that another service still requires.

A pre-migration domain audit gives you a clear baseline before anything changes. It establishes who controls each part of the domain, what is currently configured, which services depend on DNS and what must still work after the migration.

What should a pre-migration domain audit establish?

Before changing hosting, DNS or nameservers, you should be able to answer four questions:

What is changing?
Who currently controls each part of the domain infrastructure?
Which records and services must be preserved?
How will you confirm that the migration worked?

A complete pre-migration audit should establish the following:

Area	What you need to know
Domain registration	Where the domain is registered, its status and whether it is close to expiry
Authoritative DNS	Which nameservers are delegated and where the DNS zone is managed
Website hosting	Where the root domain, `www` and relevant subdomains currently point
Email	Which MX, SPF, DKIM and DMARC configuration is active
SSL	Which hostnames are covered and when the certificates expire
DNSSEC	Whether DNSSEC is enabled and correctly linked to the parent zone
Redirects	How HTTP, HTTPS, root and `www` requests behave
Other services	Which TXT records, subdomains and third-party platforms depend on the domain

The objective is not simply to collect a list of DNS records. It is to understand the relationships between them.

1. Confirm the exact migration scope

“Website migration” can describe several very different projects.

You might be:

moving a website to a new server;
changing the IP address behind an A record;
replacing a CNAME target;
moving the DNS zone to another provider;
changing the domain’s authoritative nameservers;
transferring the registration to another registrar;
changing the domain name itself;
redesigning the website while also changing its URLs.

These changes should not be treated as interchangeable.

For example, moving a website to a new host often requires changing only the relevant A, AAAA or CNAME records. It does not automatically require moving the domain registration or changing nameservers.

Changing nameservers is a much broader change because the destination DNS provider must serve every required record, not only those used by the website.

Before beginning, document exactly which of the following will change:

registrar;
nameservers;
DNS provider;
website host;
CDN or proxy;
domain name;
URL structure;
email provider;
SSL configuration.

Keeping the scope narrow reduces the number of systems that can fail at the same time.

2. Identify the registrar, DNS provider and website host

The registrar, DNS provider and website host may all be different companies.

This distinction is one of the most important things to understand before a migration.

Domain registrar

The registrar manages the domain registration. It is generally where you renew the domain, update registrant details, change nameserver delegation and manage registrar-level DNSSEC information.

DNS provider

The DNS provider operates the authoritative nameservers and hosts the domain’s DNS zone.

The nameservers delegated to the domain usually provide the strongest indication of where public DNS is managed.

Website host

The website host provides the infrastructure serving the website or application.

A, AAAA and CNAME records can help show where website traffic is directed, although the destination may be a CDN, reverse proxy, load balancer or managed platform rather than the underlying server.

Do not assume that the registrar is also the DNS provider, or that the DNS provider is also the website host.

A migration becomes considerably safer once each provider’s role is clearly identified.

Zynith DNS Audit separates detected providers by role, including the registrar, DNS provider, website hosting platform and email service where sufficient public evidence is available.

3. Record the current DNS configuration

Create a complete record of the current DNS configuration before changing anything.

At minimum, review:

A records;
AAAA records;
CNAME records;
MX records;
TXT records;
NS records;
SOA records;
CAA records;
records for known subdomains.

Pay particular attention to records that may not appear directly related to the website.

These can include:

email authentication;
domain ownership verification;
Microsoft 365 or Google Workspace configuration;
payment platforms;
marketing tools;
analytics services;
support portals;
API endpoints;
remote access services;
certificate validation;
application subdomains.

A record that looks unfamiliar should not be deleted simply because its purpose is unclear.

Export the DNS zone where possible

A public DNS audit is useful for documenting visible infrastructure, but it is not a substitute for a complete zone export from the current DNS provider.

Public DNS cannot reliably discover:

unknown subdomains;
every DKIM selector;
internal or split-horizon records;
provider-specific forwarding rules;
inactive records retained for future use;
private DNS configuration.

When administrative access is available, export the full DNS zone and retain it with the migration documentation.

Use the public audit as an independent reference and diagnostic record, not as the only backup.

4. Test the authoritative nameservers directly

Most ordinary DNS lookups are answered by recursive resolvers. Those resolvers may return cached data rather than querying the authoritative nameservers during every request.

Before a migration, test the delegated nameservers directly.

Each authoritative nameserver should:

resolve to a valid public address;
respond to DNS queries;
return an authoritative response for the domain;
serve the expected NS records;
return compatible SOA information;
agree with the other delegated nameservers.

This can reveal issues that a single public DNS lookup may not expose.

Look for lame delegation

A lame delegation occurs when a nameserver is delegated for a domain but does not serve authoritative DNS for it.

This can lead to intermittent resolution failures because some requests may reach working nameservers while others reach the incorrectly configured server.

Compare NS and SOA responses

The delegated nameservers should normally return a consistent nameserver set and compatible SOA data.

Different SOA serials may indicate that zone changes have not reached every server. In some provider architectures, serial behaviour may differ, so the result should be interpreted alongside the provider’s implementation rather than used in isolation.

Testing destination nameservers directly is also valuable before a nameserver change. It allows you to confirm that the new provider is already serving the expected zone before the public delegation is updated. Cloudflare’s current migration guidance similarly recommends verifying records, testing critical services and checking the destination configuration throughout the migration process.

Run the authoritative DNS check
Zynith queries each delegated nameserver directly and records whether it resolves, responds and serves authoritative data for the domain.

5. Check the website, HTTPS and redirect behaviour

Document how the common versions of the website currently behave:

http://example.com
https://example.com
http://www.example.com
https://www.example.com

For each version, record:

whether it responds;
the HTTP status;
whether it redirects;
the redirect chain;
the final URL;
whether HTTPS works;
whether root and www resolve consistently.

The migration should preserve the intended canonical destination.

For example, a website may be configured so that:

HTTP redirects to HTTPS;
www redirects to the root domain;
every request ends at one preferred HTTPS URL.

After the migration, confirm that this behaviour remains intact and that no unnecessary redirect steps have been introduced.

When the domain name is also changing

A move from one domain to another requires a broader SEO migration plan.

Google recommends implementing redirects before using Search Console’s Change of Address tool. It also advises maintaining redirects for at least 180 days, and longer where the old URLs still receive traffic.

A hosting change that retains the same domain and URLs does not require the Change of Address tool.

6. Review the current SSL certificates

Record the current SSL state for each important hostname.

Check:

whether the certificate is valid;
whether it is expired;
the issuing certificate authority;
the validity dates;
the hostnames covered;
Subject Alternative Names;
whether both the root domain and www are included where required.

The existing certificate may not move with the website. Many hosting platforms issue and manage their own certificates.

The purpose of documenting the current certificate is to establish the expected working state. The destination must provide equivalent coverage before traffic is fully moved.

Also consider whether the current DNS configuration contains CAA records. These records can restrict which certificate authorities are permitted to issue certificates for the domain.

If the new platform uses a different certificate authority, an existing CAA policy may need to be reviewed.

7. Review DNSSEC before changing nameservers

DNSSEC requires particular care during a DNS-provider or nameserver migration.

The parent zone stores DS records that connect the domain’s signed DNS zone to the broader DNSSEC chain of trust. The DNS provider publishes the corresponding DNSKEY records and signatures within the child zone.

If the nameservers or signing keys change but the DS record continues to reference the old configuration, validating resolvers may reject the domain’s DNS responses.

ICANN describes DS records as the link between a child zone’s DNSSEC keys and the chain of trust in the parent zone. It also notes that parent-side and child-side changes must be coordinated so a valid chain remains available.

8. Document the email configuration

Website migrations often disrupt email because the project team focuses on website records and overlooks the domain’s mail configuration.

Record all relevant email DNS before the migration, including:

MX records;
SPF records;
DKIM records;
DMARC records;
mail-related CNAME records;
autodiscover records where applicable;
verification TXT records required by the email provider.

MX records

MX records identify the systems responsible for receiving email for the domain.

If they are omitted from the new DNS zone, incoming mail may fail.

SPF

SPF identifies which systems are authorised to send email for the domain.

A missing, duplicated or incorrectly copied SPF record can affect authentication and delivery.

DKIM

DKIM uses cryptographic signatures to verify that message content has not been altered in transit and that it was signed by an authorised domain.

DKIM records often use selector-specific hostnames. Because selectors are chosen by the sender or provider, they cannot be exhaustively discovered through a generic public DNS scan.

Confirm active selectors through the email platform’s administration interface.

DMARC

DMARC defines how receiving systems should handle messages that fail aligned SPF or DKIM checks and where authentication reports should be sent.

Microsoft’s current documentation describes SPF, DKIM and DMARC as complementary email-authentication standards, with DMARC using SPF or DKIM alignment against the visible From domain.

Test both incoming and outgoing mail after the migration. A website loading correctly does not prove that email remains properly configured.

9. Save a baseline report

A dated baseline gives you something objective to compare against after the migration.

Save:

the full DNS-zone export;
the public audit report;
a JSON export where available;
an HTML or PDF copy;
screenshots of provider settings where useful;
the audit date and time;
the expected provider relationships;
the planned destination values.

This is especially useful when several people or providers are involved.

Without a baseline, post-migration troubleshooting often relies on incomplete notes, screenshots from different times or someone’s memory of the previous configuration.

With a baseline, you can identify exactly what was added, removed or changed.

10. Prepare and verify the destination before cutover

Do as much work as possible before changing live traffic.

The destination should already contain the required DNS records and be ready to serve the website.

Before cutover:

recreate all required records;
verify record names, values and priorities;
preserve unrelated TXT and verification records;
prepare both root and www handling;
confirm required subdomains;
configure SSL;
verify email dependencies;
test the destination website independently;
query the destination nameservers directly;
document a rollback process;
choose a lower-risk migration window.

Cloudflare’s migration guidance recommends planning carefully, lowering relevant TTLs in advance, testing thoroughly, communicating with stakeholders and preparing a rollback path.

Lower TTLs before the migration

Lower TTLs for records that will change early enough for their existing cached values to expire.

Changing a TTL immediately before cutover does not shorten the lifetime of answers that recursive resolvers have already cached.

Do not reduce every TTL without considering the purpose of the record. Focus on records involved in the migration and return them to appropriate operational values once the environment is stable.

11. Re-run and compare the audit after migration

Once the migration has been completed, repeat the audit.

Review:

current nameserver delegation;
authoritative nameserver responses;
A, AAAA and CNAME changes;
MX and TXT records;
website availability;
redirects;
SSL certificates;
DNSSEC;
detected providers;
email authentication.

Then compare the new result with the saved baseline.

The comparison should identify:

records added;
records removed;
values changed;
provider changes;
new redirect destinations;
certificate changes;
DNSSEC changes;
email-authentication differences.

Cloudflare’s post-migration guidance recommends testing all DNS-dependent services, including websites and email, before treating the migration as complete. It also recommends re-enabling DNSSEC only after the new environment is resolving correctly and the nameserver transition is stable.

Compare before and after
Run a new Zynith DNS Audit, upload the JSON report saved before migration and review the configuration changes.

Pre-migration domain audit checklist

Use this checklist before changing hosting, DNS or nameservers:

Confirm exactly what the migration will change.
Identify the registrar, DNS provider, website host and email provider.
Export the full DNS zone where possible.
Record the current public DNS configuration.
Document known subdomains and connected services.
Test every delegated authoritative nameserver.
Check for unreachable servers or lame delegation.
Record HTTP, HTTPS, root and www behaviour.
Review redirect chains and the final canonical URL.
Record SSL validity, expiry and hostname coverage.
Check whether DNSSEC is enabled.
Plan how DS records and DNSSEC keys will be handled.
Document MX, SPF, DKIM and DMARC.
Save a dated baseline report.
Lower relevant TTLs sufficiently in advance.
Verify the destination before cutover.
Prepare a rollback procedure.
Re-run the audit after migration.
Test the website, email and other critical services.
Compare the new result with the saved baseline.

Frequently asked questions

Not necessarily.

If the current DNS provider will remain in place, you may only need to update the A, AAAA or CNAME records used by the website.

Nameservers should generally change only when the authoritative DNS service is also moving or when the migration plan specifically requires it.

No.

A public lookup can document discoverable records, but it cannot guarantee that every record or hostname has been found.

Export the complete DNS zone from the current provider whenever administrative access is available.

Yes.

When nameservers change, the new DNS provider becomes responsible for serving the entire public zone. If MX, SPF, DKIM, DMARC or other mail-related records are missing, email may stop working or fail authentication.

It depends on the migration method and the providers involved.

Many conventional migrations use a disable-and-re-enable process, while advanced migrations may maintain validation through coordinated multi-signer DNSSEC.

Follow the documented procedure supplied by the registrar and both DNS providers.

Lower relevant TTLs before the migration and early enough for the existing TTL to expire.

Reducing a TTL immediately before changing a record will not affect responses already cached under the previous value.

Check the authoritative nameservers directly, query public resolvers, test the website over HTTP and HTTPS, verify email, review SSL and DNSSEC, and compare the new DNS configuration against the saved pre-migration baseline.

Audit the domain before you make changes

A successful website migration begins with understanding the infrastructure that already exists.

Before changing hosting, DNS or nameservers, document the current providers, records, authoritative responses, redirects, certificates, DNSSEC and email configuration. Save that baseline, verify the destination and repeat the audit after cutover.

Run a Zynith DNS Audit to document the domain’s current infrastructure, inspect the supporting evidence and save a report for post-migration comparison.