How to Find and Fix a Broken DNS Record

Your website will not load, your email has stopped arriving, or a verification check keeps failing, and someone tells you it is probably DNS. That is not much help on its own. DNS is a set of separate records, and usually only one of them is wrong, missing, or pointing at the wrong place. This post helps you find that one record, in order, and fix it without breaking the records that still work.

Start by naming the exact symptom

Do not edit records at random. Write down what is actually broken, because each symptom points to a different record.

If the bare domain will not load but www does, or the other way round, look at the A, AAAA and CNAME records for those two names. If the site loads but email bounces, look at MX and the TXT records that support it. If a service says verification failed, the missing piece is usually a specific TXT record it asked you to add. If nothing on the domain works at all, check NS first, because NS records decide which provider answers for the whole domain.

Note when it broke. A failure right after a move or nameserver change is usually a record not copied across, or copied with a typo. Our post on checking your DNS records before changing nameservers shows the pre-move list that prevents exactly this. With no recent change, suspect an expired domain or a removed record.

Look up what DNS returns right now

Before you open your DNS editor, look at the live answer from the outside. Run your domain through our DNS Records Lookup, which fetches A, AAAA, CNAME, MX, TXT, NS, SOA and CAA records. Check the exact name that is failing, not just the bare domain. Each name, such as mail.example.com or blog.example.com, has its own records.

Read the result in three passes. First, is there any answer at all for the type you need? No A record means browsers have no address to connect to. Second, does the value match what your host or email provider says it should be? A record can exist and still be wrong, such as an old server address left behind after a move. Third, check the TTL. That is how long other systems may keep the old answer after you fix it.

Save the old values first. That note is your rollback plan.

Check you are editing the right zone

A common reason a correct looking edit does nothing is that you edited DNS in the wrong place. Your registrar, DNS host and web host can be three different companies, and only one is in charge. The NS records in your lookup show who that is. Records added in another provider panel will be ignored if the nameservers point elsewhere.

Compare the nameservers at your registrar with the ones your DNS provider expects. If they do not match, fix delegation first. No record fix will hold while the domain points at the wrong zone.

Work through the records that break most often

For website records, confirm the bare domain has an A record, or a provider supported alias, pointing to the correct address, and that www has its own A record or a CNAME to a name that does. Remove a stale AAAA record if your host does not serve the site over IPv6. A broken AAAA can cause failed loads for visitors whose connections prefer IPv6, even though IPv4 is fine.

For CNAME records, remember two rules. A CNAME cannot sit alongside other records for the same name, so a name with a CNAME should not also have A, MX or TXT records. A CNAME should not be used on the bare domain in a normal zone, because the bare domain must also hold NS and SOA records. If you need the bare domain to follow another hostname, use the alias or flattening option your DNS provider offers.

For email, check that each MX record points to a hostname that resolves to an A or AAAA record. An MX record should not point to a CNAME. Check priorities too. A lower number means higher priority, and a leftover MX record for an old provider can still receive some mail and make the problem look random. Confirm the mail servers and whether they resolve with our MX Record Checker.

For TXT records, copy the value exactly as the service gave it to you. Extra spaces or missing characters cause a quiet fail. A domain should have only one SPF record. If two exist, merge them into one rather than keep both.

Rule out caching before you edit again

You fixed the record, but the site still fails on your screen. That does not always mean the fix was wrong. Resolvers cache the old answer until its TTL expires, and your browser, router and provider each add their own cache.

Use our DNS Propagation Checker to see what resolvers in different places return now. Our guide to DNS propagation explains why the change takes time to reach every resolver. If most show the new value and only your connection shows the old one, the record is fixed and your cache is the remaining problem. Wait, or test on a phone using mobile data. If every resolver still shows the old or empty answer long after the old TTL should have passed, go back to the zone check. You may have edited the wrong provider or saved a record for www when the bare domain was broken.

Avoid repeated changes while you wait. Each edit starts another round of mixed answers.

Fix one record, verify, then stop

Make the smallest change that addresses the symptom you named. Change one record, save it, then run the lookup again and confirm the new value is what the internet returns. Test the original failing action itself, not just the lookup. Load the page, send a test email, or rerun the verification.

If it still fails, do not stack a second guess. Compare the live answer with the required value, character by character, and check the record name. Most stubborn cases are a full domain typed into a subdomain field, a value in the wrong field, or a record for the wrong name.

What to do first

Start with the lookup, not the editor. Run the failing name through the DNS Records Lookup, write down the current A, CNAME, MX, TXT and NS answers, and match the symptom to the one record that does not fit. Fix that record in the provider named by your NS records, verify it with a fresh lookup and a propagation check, and only then test the site or inbox again. That order turns a vague DNS problem into a single, checkable fix.