Migrating from one hosting provider to another is a routine operation, but it carries real risk if DNS records are not correctly updated and verified. A missed record or a misconfigured value can result in website downtime, lost emails, or broken subdomains that go unnoticed until a customer reports a problem.
This guide walks through the complete process of verifying DNS changes after a hosting migration. I will cover which records to check, the tools to use, a pre-migration checklist to follow, and the most common pitfalls that catch people off guard.
Pre-Migration DNS Checklist
Before you change a single record, document everything about your current DNS configuration. This inventory becomes your safety net if anything goes wrong during the migration.
Export Your Current DNS Zone
Start by recording every DNS record currently configured for your domain. Most DNS providers have an export option, or you can query for records manually:
# Query all common record types for your domain
dig example.com A +short
dig example.com AAAA +short
dig example.com CNAME +short
dig example.com MX +short
dig example.com TXT +short
dig example.com NS +short
dig example.com SOA +short
# Check common subdomains
dig www.example.com A +short
dig mail.example.com A +short
dig blog.example.com CNAME +short
Record the output somewhere safe. You will reference this list throughout the migration to ensure nothing is missed.
The Hidden Subdomain Problem
The commands above will capture records for your root domain and a few obvious subdomains, but they will not reveal subdomain records you have forgotten about. DNS has no built-in way to list all subdomains for a domain -- you can only query records you already know exist. This is a common source of migration failures: a subdomain like em1234.example.com (used by SendGrid for email authentication) or _domainkey.example.com (used for DKIM signing) silently breaks because it was never carried over to the new DNS configuration.
To get a complete picture, use one or more of these approaches:
- Export your zone file from your DNS provider. This is the most reliable method. Cloudflare, Route 53, GoDaddy, and most managed DNS services offer a zone file export that includes every record, including subdomains you may have set up years ago and forgotten about.
- Check Certificate Transparency logs. Services like crt.sh index every publicly issued SSL certificate for your domain, which reveals subdomains that have had certificates provisioned:
# Discover subdomains via Certificate Transparency logs
curl -s "https://crt.sh/?q=%.example.com&output=json" | jq -r '.[].name_value' | sort -u
- Review your third-party service integrations. Email marketing platforms (SendGrid, Mailchimp), analytics tools, CDN providers, and SaaS products often require CNAME or TXT records on specific subdomains. Check the DNS setup pages for each service you use and verify those records exist in your new configuration.
- Query known email authentication subdomains. These follow predictable naming patterns and are critical for email delivery:
# Email authentication subdomains
dig _dmarc.example.com TXT +short
dig _spf.example.com TXT +short
dig google._domainkey.example.com TXT +short
dig s1._domainkey.example.com TXT +short
dig s2._domainkey.example.com TXT +short
Do not assume that the records you can see from a few dig queries represent your complete zone. If you skip this step and a forgotten subdomain record is left behind on the old DNS provider, the associated service will stop working as soon as the old DNS is decommissioned -- and you may not notice until a customer reports the issue.
Lower TTL Values in Advance
At least 24 to 48 hours before the migration, reduce the TTL on all records you plan to change. Setting the TTL to 300 seconds (5 minutes) ensures that when you switch the records, resolvers around the world will pick up the new values quickly:
; Before (high TTL, good for normal operation)
example.com. 86400 IN A 203.0.113.50
; After lowering TTL (do this 24-48 hours before migration)
example.com. 300 IN A 203.0.113.50
This step is critical. If you skip it, your old high TTL means users could be directed to your old server for up to 24 hours after you make the change.
Verify the New Server Is Ready
Before updating DNS, make sure the new hosting environment is fully configured:
- Your website files and database have been migrated and tested.
- SSL/TLS certificates are installed and working on the new server.
- The web server responds correctly when accessed directly by IP address.
- Email services are configured if hosted on the same server.
You can test the new server by adding a temporary entry to your local hosts file:
# Add to /etc/hosts (macOS/Linux) or C:\Windows\System32\drivers\etc\hosts (Windows)
198.51.100.25 example.com
198.51.100.25 www.example.com
This forces your local machine to connect to the new server IP without changing public DNS. Browse your site thoroughly to catch any issues before going live.
Which DNS Records to Verify After Migration
Different record types serve different purposes. Missing even one can cause specific functionality to break while everything else appears to work fine.
A and AAAA Records (Website IP Addresses)
The A record maps your domain to an IPv4 address, and the AAAA record maps it to an IPv6 address. These are the most fundamental records for your website.
; A record pointing to new server
example.com. 300 IN A 198.51.100.25
; AAAA record for IPv6 (if your new host supports it)
example.com. 300 IN AAAA 2001:db8::1
After updating, verify both the root domain and the www subdomain:
dig example.com A +short
# Expected: 198.51.100.25
dig www.example.com A +short
# Expected: 198.51.100.25 (or a CNAME pointing to example.com)
If your new host provides an IPv6 address, make sure to set the AAAA record as well. An increasing percentage of users connect over IPv6, and a stale AAAA record pointing to the old server will cause connection failures for those users.
CNAME Records (Aliases and Subdomains)
CNAME records create aliases that point one domain name to another. They are commonly used for subdomains like www, blog, or shop:
www.example.com. 300 IN CNAME example.com.
blog.example.com. 300 IN CNAME hosting.provider.com.
shop.example.com. 300 IN CNAME shops.myshopify.com.
Review every CNAME record in your zone. If any of them pointed to a hostname at your old provider, they need to be updated. Pay special attention to:
- Service-specific subdomains (blog platforms, e-commerce, CDN origins)
- Subdomains used for email verification (often required by email marketing services)
- CDN or load balancer endpoints that may have changed
MX Records (Email Routing)
MX records are arguably the most critical to get right during a migration. If MX records are misconfigured or point to a server that is no longer handling email for your domain, incoming messages will bounce or be silently lost.
; Example MX records for Google Workspace
example.com. 300 IN MX 1 aspmx.l.google.com.
example.com. 300 IN MX 5 alt1.aspmx.l.google.com.
example.com. 300 IN MX 5 alt2.aspmx.l.google.com.
example.com. 300 IN MX 10 alt3.aspmx.l.google.com.
example.com. 300 IN MX 10 alt4.aspmx.l.google.com.
If your email is hosted by a third-party provider (Google Workspace, Microsoft 365, Zoho, etc.), your MX records should remain the same after the migration. However, if email was hosted on the same server as your website, you need to either migrate email to the new server or switch to a dedicated email provider.
Verify MX records after the migration:
dig example.com MX +short
# Verify the output matches your expected mail server configuration
NS Records (Nameserver Delegation)
If you are changing DNS providers as part of the migration (for example, moving from your old host's DNS to Cloudflare or Route 53), you will need to update nameserver records at your domain registrar.
; Example: Cloudflare nameservers
example.com. 86400 IN NS anna.ns.cloudflare.com.
example.com. 86400 IN NS tony.ns.cloudflare.com.
NS changes propagate through the TLD registry zone files and can take longer than individual record changes. Verify NS records have updated:
dig example.com NS +short
# Should return your new nameservers
TXT Records (SPF, DKIM, Domain Verification)
TXT records are used for email authentication (SPF, DKIM, DMARC) and domain ownership verification for third-party services. These are easy to overlook during migration but can cause serious problems if missing.
; SPF record
example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"
; DKIM record
google._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
; DMARC record
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; Domain verification for third-party services
example.com. 300 IN TXT "google-site-verification=abc123..."
After migration, verify all TXT records are present:
dig example.com TXT +short
dig _dmarc.example.com TXT +short
Missing SPF or DKIM records will cause your outgoing emails to fail authentication checks and land in spam folders or be rejected entirely.
Step-by-Step Verification With DNSChkr Tools
Once you have updated your DNS records, use DNSChkr's tools to verify that the changes are correctly resolving and propagating.
Check Global Propagation
Use the DNSChkr Propagation Checker to verify your records are being served correctly from DNS servers worldwide:
- Enter your domain name in the propagation checker.
- Select the record type (start with A records).
- Review the results. Each server location will show the value it is currently resolving for your domain.
- Repeat for each record type: AAAA, MX, TXT, NS, and any CNAME subdomains.
Look for consistency across all servers. If some servers return the old IP address while others return the new one, propagation is still in progress.
Inspect Individual Records in Detail
The DNSChkr DNS Inspector provides detailed record inspection for your domain. Use it to:
- View the complete set of records for your domain in one place.
- Check that the returned values match your expected configuration.
- Identify any records that may be missing or incorrectly configured.
- Verify TTL values are set as expected.
This is particularly useful for catching discrepancies in TXT records, which can contain complex values that are easy to misconfigure.
Monitor Over Time
DNS propagation is not instant. After making your changes:
- Check propagation immediately to confirm the authoritative nameserver is returning the correct value.
- Check again after 1 hour to see how many resolvers have updated.
- Check once more after 4 to 6 hours. By this point, the vast majority of resolvers should have the new records (assuming you lowered TTL in advance).
- Do a final check after 24 hours to catch any remaining stragglers.
Common Pitfalls During DNS Migration
Even experienced administrators make mistakes during hosting migrations. Here are the most common issues and how to avoid them.
Forgetting to Migrate Email Records
This is the number one cause of post-migration email failures. If your old host was handling email, you need a plan for email before you decommission the old server. Options include migrating email to the new host, switching to a dedicated email service, or using a service like Google Workspace or Microsoft 365.
Not Testing SSL Certificates on the New Server
If your new server does not have a valid SSL certificate installed and your A record starts pointing to it, visitors will see a browser security warning. Ensure certificates are provisioned and working before switching DNS. If you use Let's Encrypt, you may need to use DNS-based validation to obtain the certificate before pointing the domain to the new server.
Overlooking Subdomain Records
Many sites use subdomains for staging environments, APIs, CDN origins, or third-party integrations. Review your complete DNS zone and make sure every subdomain record is accounted for in the new configuration.
Changing DNS Before the New Server Is Ready
If you update DNS to point to a new server that is not yet fully configured, users will see errors. Always verify the new server is serving your site correctly (using local hosts file testing) before changing public DNS.
Not Restoring TTL After Migration
After the migration is complete and verified, remember to raise your TTL values back to normal (typically 3600 to 86400 seconds). Keeping TTL at 300 seconds indefinitely means every visitor generates a fresh DNS query every 5 minutes, increasing latency and putting unnecessary load on your DNS infrastructure.
Post-Migration Verification Checklist
Use this checklist to confirm everything is working after the switch:
- A record resolves to the new server IP address
- AAAA record resolves correctly (if using IPv6)
-
wwwsubdomain resolves correctly - MX records point to the correct mail servers
- SPF, DKIM, and DMARC TXT records are present and correct
- SSL certificate is valid and serving correctly
- All subdomains resolve to their intended destinations
- Website loads correctly from multiple geographic locations
- Email delivery is working (send a test email to and from the domain)
- Third-party service verification TXT records are present
- TTL values have been restored to normal after propagation is complete
Frequently Asked Questions
Key Takeaways
- Always document your complete DNS zone before starting a migration. An inventory of all records is your safety net if something goes wrong.
- Lower TTL values to 300 seconds at least 24 to 48 hours before the migration to minimize propagation time.
- Verify every record type individually: A, AAAA, CNAME, MX, NS, and TXT records all serve different purposes and must all be correct.
- MX and TXT records for email (SPF, DKIM, DMARC) are the most commonly missed during migration, and the consequences are severe -- bounced or lost emails.
- Use the DNSChkr Propagation Checker to monitor propagation across global DNS servers and confirm your changes are live in all regions.
- Use the DNSChkr DNS Inspector to inspect the full set of records for your domain and catch any discrepancies.
- Test your new server using a local hosts file entry before making public DNS changes.
- Keep the old hosting account active for at least 48 to 72 hours after the DNS cutover.
- Restore TTL values to normal (3600 to 86400 seconds) after migration is verified and complete.
Planning a hosting migration? Start by checking your current DNS records with the DNSChkr DNS Inspector, then monitor your migration in real time with the DNSChkr Propagation Checker.