It's not working. Now what?

Step 1: find out who actually runs your DNS

This is the single most common source of wasted time. People edit records at their registrar while the nameservers point somewhere else entirely — so the edits are real, saved, and completely ignored.

Your DNS is run by whoever your nameservers point at. Look them up:

Or from a terminal: dig NS yourdomain.com +short (macOS/Linux) or nslookup -type=ns yourdomain.com (Windows).

Match the nameserver names against our provider list — *.domaincontrol.com is GoDaddy, *.ns.cloudflare.com is Cloudflare, *.registrar-servers.com is Namecheap, and so on. That's the panel you need to be editing in.

Step 2: has enough time passed?

A change is not live until the old record's TTL has expired in every cache that holds it. If the previous record had a 4-hour TTL, allow 4 hours. Lowering the TTL now does not speed up the change you already made — it only helps the next one.

The "24–48 hours for propagation" line you'll see in support articles is a legacy of much higher TTLs. In practice most changes settle within the TTL, occasionally a bit longer where an ISP resolver ignores it.

Common causes, roughly in order

Editing the wrong panel. See step 1.
A leftover parking or forwarding record. Most registrars pre-fill a parking A record and a www CNAME. Domain forwarding in particular silently overrides your A record.
The full domain typed into the Name field, producing www.example.com.example.com.
A duplicate record. Two A records on @ means visitors get sent to both, at random.
Your own browser or OS cache. Test in a private window, on mobile data, or flush with ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache (macOS).
A CNAME on the root domain. Not legal. Use an A record, or an ALIAS/ANAME if the provider offers one.
Unapplied changes. Plesk queues edits behind an "Update" button; some panels need a second confirmation.
A CAA record blocking your certificate authority, if the DNS resolves fine but SSL won't issue.

Checking what the world sees

Your own machine is the least reliable place to test from. Query a public resolver directly so you bypass your ISP and your router:

dig @1.1.1.1 yourdomain.com A +short
dig @8.8.8.8 yourdomain.com MX +short
dig NS yourdomain.com +short

On Windows without dig, nslookup yourdomain.com 1.1.1.1 does the same job.

Moving a live site without downtime

A day ahead, lower the TTL on the records you're going to change to 300 seconds.
Get the new server working and tested on a temporary hostname or by editing your hosts file.
Recreate every record at the new DNS provider before switching nameservers — including MX, SPF, DKIM and DMARC, which are easy to forget and take mail down when missed.
Make the change. Keep the old server running for at least 48 hours; stragglers will still hit it.
Put the TTL back up once you're happy.