Most DNS problems are one of four things: the domain points at the wrong nameservers, a record is missing or wrong, a change has not propagated yet, or nothing is wrong at all and you are looking at a cached answer. Telling them apart takes two commands.
Ask the internet, not your browser
Your browser caches, your operating system caches, and your network's resolver caches. A site loading fine for you proves nothing about what anyone else sees, and a site failing for you may be working perfectly.
Start here, always:
dig example.com dig NS example.com
The first shows what address the domain resolves to. The second shows which nameservers are authoritative, and that second one is the question people skip while spending an hour editing records on a server that is not being consulted.
To see what a public resolver has, rather than your own:
dig @8.8.8.8 example.com dig @1.1.1.1 example.com
If those two disagree with each other, you are mid-propagation and there is nothing to fix.
The domain does not resolve at all
Check the nameservers first:
dig NS example.com
If they are not yours, the domain is being served from somewhere else and every record you edit here is ignored. Change them at the registrar. Changing nameservers goes into it.
If the nameservers are correct but the domain still returns nothing, check the domain has not expired. An expired domain is removed from the system entirely and no amount of DNS work will bring it back until it is renewed. Check the expiry with a WHOIS lookup.
Then check the zone exists on the server, and that it contains an A record for the domain itself; a zone can exist with records for www and nothing for the bare name.
www works but the bare domain does not, or the reverse
These are separate records. Having one does not give you the other.
dig example.com dig www.example.com
Whichever returns nothing is the record to add. Both should resolve, and one should redirect to the other at the web server level so you have a single canonical address.
This also affects certificates: one covering only the bare domain shows a warning to everyone typing www.
The site loads for some people and not others
Propagation, and it is not a fault. Different resolvers still hold the old answer, and they release it when their cached copy expires, which is governed by the TTL that was in place before you made the change.
dig @8.8.8.8 example.com dig @1.1.1.1 example.com
Disagreement between those confirms it. Wait rather than changing anything: editing again during propagation only extends the confusion.
Understanding DNS propagation walks through how long it takes and how to shorten it next time.
Email stopped but the website is fine
These use different records, so one can break without the other.
dig MX example.com
If the MX records are missing or point at the wrong server, that is your answer. They are frequently lost when a zone is recreated, or overwritten when someone changes hosting.
If MX records look right and mail still fails, the problem is not DNS: check the mailbox quota and the account quota first, since a full account rejects mail. The email troubleshooting guide explains the order.
A change I made is not taking effect
Three possibilities, in order.
You edited a zone on a server the domain does not use. Check the nameservers.
There are two records for the same name. An old A record left beside a new one produces unpredictable results. Look at the whole zone instead of the record you just added.
It is propagating. Compare two public resolvers.
The domain resolves but shows the wrong site
Not a DNS problem. The domain reaches the server correctly and the server does not know which site to serve, so it answers with whatever is at that address by default.
Check that the account actually holds that domain and that its document root is correct. Editing DNS further will not change this.
Everything looks right and it still fails
Flush your own caches before concluding anything, because at this point you are the most likely source of the wrong answer.
# macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Windows ipconfig /flushdns # Linux (systemd) sudo systemd-resolve --flush-caches
Then try from a different network entirely; a phone on mobile data is the quickest test. If it works there and not on your own connection, the problem is local and not something to fix on the server.
What to gather before opening a ticket
The output of dig NS example.com and dig example.com, what you expected instead, when it last worked, and what changed around then.
Those four turn a long exchange into a short one, and the first is the one that most often reveals the answer before anyone else has to look.
When a correct record still returns the old value, nothing is broken and nothing needs changing again, Understanding TTL and When to Lower It explains what is happening.
Almost every uncertain answer here becomes definite once you ask a named server directly. For the commands, see How to Use dig and nslookup to Check DNS.
A record that is wrong and that nobody changed is a different problem, and the server reports nothing. How to Monitor DNS and Detect Unauthorised Changes goes into detecting it.