Check My DNS: How to Verify Your DNS Changes Are Working

You've updated your DNS records and now you're staring at a clock, wondering if the changes have propagated. Or worse, you're about to migrate a production site and you need to know the new nameservers will work before you pull the trigger. Checking DNS isn't about running one command and calling it done. It's about verifying multiple record types, testing from different locations, and confirming your domain resolves correctly before your business is at risk. This guide walks through exactly how seo site migration teams and site owners can test DNS changes, preview configurations, and catch problems before they cost you traffic.

Why Do I Need to Check My DNS Before a Migration?

DNS failures during migrations are responsible for more site downtime than server issues, according to network reliability studies. When you switch nameservers or update DNS records without testing first, you're essentially flipping a switch and hoping everything works. That's not a strategy.

Every DNS record serves a specific purpose. Your A records point your domain to an IP address. MX records route email. TXT records handle domain verification and security certificates. If even one record is misconfigured, you can lose email delivery, break subdomains, or send visitors to a dead server.

At Sharkly, we've seen production sites go dark because a single CNAME pointed to the wrong server. The business lost three hours of uptime and thousands in revenue. Testing DNS before you update registrar records is the only way to catch those errors when they're still fixable.

The Real Cost of DNS Errors

Downtime isn't just inconvenient. Search engines interpret prolonged server errors as site quality issues. If Google crawls your site during a DNS outage and gets repeated failures, your rankings can drop. The impact shows up in days, but recovery takes weeks.

Email disruption hits harder in some ways. A misconfigured MX record means your business stops receiving messages. Customers can't reach you. Order confirmations don't send. You won't know there's a problem until someone mentions they've been trying to contact you for hours.

How to Test DNS Records Before Changing Your Nameservers

The core challenge is simple: you want to test new DNS records without actually switching your domain to the new nameservers. Once you update nameservers at your registrar, the change is live. There's no staging environment for DNS. So you need to simulate what will happen.

Use the Hosts File Method

Your operating system maintains a hosts file that overrides DNS lookups. This file maps domain names to IP addresses locally, which means you can point your domain to a new server on your machine without touching actual DNS records.

On Windows, the hosts file lives at C:\Windows\System32\drivers\etc\hosts. On Mac and Linux, it's at /etc/hosts. Open it with administrator privileges and add a line like this:

192.0.2.1 example.com www.example.com

Replace the IP address with your new server's address and the domain with your actual domain name. Save the file. Now when you visit your domain in a browser, your computer will connect to the new server instead of following the current DNS records.

This method lets you browse the site, test forms, check SSL certificates, and confirm everything works exactly as it will after migration. The limitation is that it only affects your local machine. Other team members need to edit their own hosts files.

Query Nameservers Directly

DNS lookup tools let you query specific nameservers without changing your registrar settings. This is how you test whether your new nameserver has the correct records configured.

The dig command works on Mac and Linux. Here's the syntax to check an A record on a specific nameserver:

dig @ns1.newprovider.com example.com A

Replace ns1.newprovider.com with your new nameserver hostname and example.com with your domain. The response will show what IP address that nameserver returns for your domain.

On Windows, use nslookup instead:

nslookup example.com ns1.newprovider.com

Run this test for every record type you're using. Check A records, AAAA records for IPv6, MX records for email, and TXT records for domain verification. Each record type needs separate verification.

Test Multiple Record Types

An A record test doesn't tell you anything about your MX records. You need to check each type individually. Here's how to query MX records with dig:

dig @ns1.newprovider.com example.com MX

For TXT records, which handle SPF, DKIM, and domain verification:

dig @ns1.newprovider.com example.com TXT

Compare the results to your current DNS records. Every record that exists now should exist on the new nameserver with the same values, unless you're intentionally changing something. Missing records mean broken functionality after migration.

How Can I Preview My Website on a New Hosting Provider?

Many hosting providers and platforms like Netlify offer preview URLs or temporary domains. These let you see your site on the new server without changing DNS at all.

A preview URL typically looks like yoursite.temp.hostingprovider.com or uses a numeric identifier. The provider generates this URL automatically when you set up the hosting account. You can browse the site, test functionality, and verify SSL certificates work.

The trade-off is that preview URLs don't perfectly replicate your production domain. Some applications check the domain name and behave differently on a temporary URL. Hardcoded absolute URLs in your code might still point to the old server. Cookie domains won't match. But for basic functionality testing, preview URLs catch most issues.

Set Up a Staging Subdomain

Another approach is to create a subdomain on your current DNS and point it to the new server. For example, create staging.example.com and set its A record to your new server's IP address.

This method tests the actual server and hosting environment while keeping your main domain unchanged. You can share the staging subdomain with team members, run QA tests, and verify integrations work. Once everything checks out, you update the main domain's records to match the staging configuration.

The downside is that you're still modifying your current DNS. If you're migrating to an entirely new DNS provider and want to test their nameservers before switching, this doesn't help.

How Do I Know When My DNS Changes Have Propagated?

DNS propagation is the time it takes for DNS changes to spread across the internet. When you update a record, the change doesn't appear instantly everywhere. Different DNS servers around the world cache your records for a period determined by the TTL value.

TTL stands for "time to live" and it's measured in seconds. A TTL of 3600 means DNS servers will cache your record for one hour before checking for updates. If you change a record, servers that cached the old version won't see the new value until their cache expires.

Check DNS from Multiple Locations

Your local DNS cache isn't representative of the entire internet. You need to check from multiple geographic locations and different DNS providers to confirm propagation.

Online DNS propagation checkers query your domain from servers worldwide. They show you what different locations see and whether your new records have reached those servers. These tools typically test from 10 to 20 locations across continents.

A complete propagation can take anywhere from a few minutes to 48 hours, depending on your TTL settings and how aggressively different DNS servers cache records. Most changes propagate within a few hours if your TTL is set low.

Lower TTL Before Migration

Here's a step that prevents propagation headaches: reduce your TTL to 300 seconds (five minutes) at least 24 hours before you plan to migrate. This tells DNS servers to cache your records for only five minutes.

When you make the actual change, the maximum propagation time is now five minutes instead of hours. Servers check for updates more frequently. This doesn't speed up the change itself, but it dramatically shortens the window where some users see the old server and others see the new one.

After migration completes and you've confirmed everything works, you can raise the TTL back to a normal value like 3600 or 7200. Lower TTL values increase the query load on nameservers slightly, which is why you don't leave them at 300 permanently.

What DNS Records Should I Verify During a Migration?

Different record types serve different purposes. Missing any of them can break specific functionality even if your website loads.

A and AAAA Records

A records map your domain name to an IPv4 address. This is the fundamental record that makes your domain resolve to a server. Most sites have an A record for the root domain and another for the www subdomain.

AAAA records do the same thing for IPv6 addresses. Not every site needs these yet, but if your current DNS includes them, your new configuration should too.

CNAME Records

CNAME records alias one domain to another. These are common for subdomains. For example, blog.example.com might have a CNAME pointing to a custom domain on a blogging platform.

During migration, verify that every CNAME still points to the correct target. A stale CNAME can send traffic to a decommissioned server or a competitor's site if you reused a subdomain name.

MX Records

MX records route email for your domain. These are often overlooked during migrations because the website still works even if MX records are missing. But your email stops working immediately.

Check that all MX records exist on the new nameserver with the correct priority values. If you use Google Workspace or Microsoft 365 for email, you'll typically have multiple MX records with different priority numbers. All of them need to transfer.

TXT Records

TXT records handle domain verification, SPF email authentication, DKIM keys, and DMARC policies. These are critical for email deliverability and proving domain ownership to services like google search console site migration tools.

Copy every TXT record from your current DNS to the new provider. Even obscure-looking verification codes need to transfer. Losing a verification TXT record can lock you out of a third-party service until you re-verify.

How to Test DNS Locally Without Waiting for Propagation

Propagation delays are frustrating when you need to verify changes immediately. Fortunately, you can test DNS records locally without waiting for the changes to spread globally.

Flush Your Local DNS Cache

Your operating system caches DNS lookups to speed up repeated visits to the same domain. This cache can show you outdated information even after records change.

On Windows, open Command Prompt as administrator and run:

ipconfig /flushdns

On Mac, the command is:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux, the command varies by distribution, but for systems using systemd-resolved:

sudo systemd-resolve --flush-caches

After flushing the cache, your next DNS lookup will query the nameserver directly instead of using cached data.

Use a Different DNS Resolver

Public DNS resolvers like Google Public DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1) often update faster than your ISP's resolver. You can temporarily switch your computer to use one of these resolvers to see changes sooner.

This doesn't affect actual propagation, but it gives you a faster view of what updated records look like. If the public resolver shows your new records but your ISP's resolver doesn't, you know propagation is in progress.

What Should I Check After Updating Nameservers?

Once you've updated nameservers at your domain registrar, the migration is live. Now you need to verify that everything works correctly from the user's perspective.

Test the Website Loads Correctly

Visit your domain in a browser. Check the homepage and several internal pages. Verify images load, forms submit, and interactive elements work. SSL certificate warnings mean the new server doesn't have a valid certificate installed for your domain.

If you see a certificate error, the server might be serving a default certificate instead of one for your domain. Most hosting providers auto-generate Let's Encrypt certificates, but this can take a few minutes after DNS changes. If the error persists for more than 10 minutes, check your hosting provider's SSL configuration.

Verify Email Delivery

Send a test email to an address on your domain. Then send one from your domain to an external address. Both directions need to work. MX record issues typically show up as bounce messages or delayed delivery.

If email fails, check your MX records with a DNS lookup tool. Compare them to your previous provider's settings to confirm they transferred correctly.

Check Search Console and Analytics

Log into Google Search Console and verify that Google can still crawl your site. Check for new errors in the Coverage report. A sudden spike in errors after migration indicates a problem.

Google Analytics should continue tracking visitors without interruption. If your analytics code is embedded correctly, DNS changes don't affect tracking. But it's worth checking that sessions and pageviews still appear in real-time reports.

How Do DNS Checks Fit Into a Complete Migration Strategy?

DNS verification is one component of a larger migration process. At Sharkly, we've built complete migration workflows that include DNS testing as a checkpoint, not the entire plan.

A full migration checklist includes content inventories, redirect mapping, xml sitemap migration process updates, and timing considerations like when is the best time to schedule the switch. DNS checks happen in the testing phase, before you commit to the change.

Build a Pre-Migration Testing Window

The most effective migrations we've seen include a dedicated testing period. Set up your new hosting environment and DNS records, but don't update the nameservers yet. Use the testing methods above to verify everything works.

Give yourself at least 48 hours of testing time. That window lets you catch configuration errors, test under different conditions, and get team approval before the change goes live. Rushing DNS changes leads to mistakes.

Have a Rollback Plan

Despite careful testing, sometimes you need to revert. Document your current nameserver settings before you change them. Screenshot your DNS records or export them if your provider offers that option.

If something goes wrong after you update nameservers, you can immediately switch back to the old nameservers. DNS propagation works both ways. The rollback propagates just like the original change, but at least you've stopped the problem from getting worse.

What DNS Testing Tools Should I Use?

Manual command-line testing works, but dedicated DNS tools make the process faster and catch issues you might miss.

DNS Lookup Tools

Online DNS lookup tools query records for you and present the results in a readable format. They're faster than remembering dig command syntax and work on any operating system with a browser.

These tools typically let you select the record type, specify a nameserver to query, and see the results instantly. Some show historical data so you can compare current records to previous configurations.

DNS Propagation Checkers

Propagation checkers query your domain from multiple global locations and show which servers have the new records. This gives you a real-time view of how far your changes have spread.

Most propagation checkers test from 15 to 30 locations across different countries and continents. They display the results in a table or map, with color coding to show which servers see the old records and which see the new ones.

WHOIS Lookup

WHOIS databases show nameserver information at the registrar level. This tells you which nameservers are authoritative for your domain according to the domain registry.

After you update nameservers, a WHOIS lookup confirms the registry has accepted the change. This is separate from DNS propagation. The registry might show the new nameservers immediately, but individual DNS resolvers won't query those nameservers until their cache expires.

Common DNS Issues That Testing Reveals

Testing before migration catches problems that would otherwise cause downtime. Here are the issues that show up most frequently when Sharkly customers test DNS configurations.

Missing Subdomain Records

It's easy to remember the main domain and www subdomain, but what about mail.example.com or ftp.example.com? Any subdomain with an active record needs to transfer.

Export a complete list of your current DNS records before migration. Compare that list to the new provider's records line by line. Missing subdomains mean broken services.

Incorrect TTL Values

Some DNS providers reset TTL values to a default when you import records. If your old TTL was 300 seconds and the new provider sets it to 86400, you're looking at a much longer propagation time.

Check TTL values after importing records. Set them to match your migration strategy. Lower TTLs before the switch, normal TTLs after.

Wrong Target Addresses

Typos in IP addresses or CNAME targets send traffic to the wrong place. This is surprisingly common when manually entering records.

A single wrong digit in an IP address can point your domain to someone else's server or a non-existent address. Always verify the target values match your intended configuration exactly.

DNS Testing Fits Into Broader SEO Site Hygiene

DNS reliability matters for search engine optimization because unavailable sites can't rank. Google's crawlers encounter the same DNS system your users do. If they can't resolve your domain, they can't crawl your content.

Research published in Google's own patent filings shows that server availability and response time factor into quality signals. Repeated DNS failures tell search engines your site isn't reliably accessible, which impacts rankings over time.

Every recommendation Sharkly makes is backed by published research, Google's own patent filings, and thousands of data points specific to your site. DNS testing isn't glamorous, but it's the foundation that everything else builds on.