Introduction

A nameserver change can complete successfully while your team keeps editing DNS records at the old provider. The zone still looks familiar, the control panel still accepts changes, and the records may even look correct there, but none of those edits affect live traffic once another provider becomes authoritative.

Treat this as an authority problem instead of a propagation problem. Start by proving which nameservers are actually authoritative for the domain now, because editing the wrong DNS zone can waste hours while the live zone remains unchanged.

Symptoms

  • DNS updates at the old provider never take effect on the live domain
  • Team members see the record changed in one panel, but public lookups still show something else
  • The issue started after moving nameservers to a new DNS host, registrar, or CDN
  • Different admins are making changes in different dashboards for the same domain
  • MX, TXT, or A record updates appear stuck even though the old provider zone was edited correctly
  • Troubleshooting keeps focusing on TTL and cache, but the real record never changes publicly

Common Causes

  • The domain now uses different authoritative nameservers than the team expects
  • The old DNS provider still hosts a stale zone that looks active but is no longer live
  • Registrar nameserver changes completed, but internal documentation still points admins to the previous DNS panel
  • One provider manages the live zone while another still contains newer-looking but inactive edits
  • The migration validated nameserver delegation once, then teams kept using the old workflow afterward
  • Staff assumed identical records existed in both places, so they updated the wrong zone during later changes

Step-by-Step Fix

  1. Query the domain’s current authoritative nameservers from the registrar or public DNS and write down exactly which provider is live, because you need to stop guessing before changing more records.
  2. Compare the authoritative provider with the dashboard where recent edits were made, because the problem is often that the team changed a zone that is no longer serving the public internet.
  3. Pull the live record directly from the authoritative nameservers and compare it with the value shown in the old provider’s zone, because that difference proves whether the wrong zone is being edited.
  4. Move the needed DNS changes into the active authoritative zone and retest the exact record type involved, because copying only part of the old configuration can leave the real issue untouched.
  5. Review whether subdomains, mail records, verification records, and redirects were also updated in the wrong place, because once a team is editing the wrong zone, more than one record is usually affected.
  6. Lock down or clearly label the inactive zone at the old provider if you still keep it for reference, because a stale but writable DNS panel keeps causing repeat mistakes.
  7. Confirm the registrar delegation still points where you expect and has not partially reverted during another transfer or account change, because authoritative drift can reintroduce the same confusion.
  8. Re-test from public resolvers only after the live authoritative zone is corrected, because cache checks are meaningful only when the right source of truth has been updated.
  9. Document the active DNS provider, authoritative nameservers, and approved edit path for the domain, because nameserver migrations often fail operationally after the cutover rather than during it.