A domain with no DNS set up does nothing. Getting it working is a short sequence, and doing it in the right order avoids the two failures people hit: a site that is unreachable for hours, and mail that quietly stops.
First, decide who answers
The nameservers set at your registrar decide which service holds your records. Everything else depends on that being settled.
Three normal choices: your hosting provider's nameservers, a third-party DNS provider, or your registrar's own.
Using your host's is simplest, because records are created for you when you add a domain. Using a third party keeps DNS independent of whichever host you use this year, which is worth something when you move. How to Move DNS to a Third-Party Provider walks through that route.
Pick one. Records added at a provider that is not authoritative do nothing at all, and that is the most common "I added the record and nothing happened".
The records a normal site needs
Four, and only four to begin with.
A record at the root pointing at your server's address.
A record or CNAME for www, pointing at the same place.
MX records for mail, if you are receiving any.
An SPF record as TXT, authorising whatever sends mail for you.
Anything else (subdomains, verification records, CAA) comes later and is added the same way. Which DNS Record Type Do You Need walks through choosing.
Set both www and the bare domain
Visitors will type both. A domain that works with www and not without it looks broken to half your audience, and you will not notice because you always type one form.
Point both at the server, then choose one as canonical and redirect the other at the web server, not in DNS, which cannot redirect anything. How to Force HTTPS and Redirect HTTP to HTTPS explains doing both redirects in one rule.
Mail is a separate decision
The step that gets skipped on a new domain, and the consequence is invisible.
Without MX records, mail to your domain is either rejected or delivered somewhere you are not looking. Decide where mail should go before the domain is live, not after somebody says they emailed you.
If mail is handled by an external provider while the site is on your host, there is one more setting: the hosting account must be told not to deliver mail for the domain locally, or messages your own website sends to your own domain never leave the server. There is more in How to Use an External Mail Provider with Your Domain.
Add SPF from the start
One TXT record listing what may send mail for the domain. Without it, your mail is treated as unverified from day one, and reputation is easier to build than to repair.
One rule: exactly one SPF record. Two makes both invalid, which is worse than having none, and it is what happens when a second service is added later by someone who did not check. Understanding SPF, DKIM and DMARC Records deals with merging.
TTL: low while you are working
Set a short TTL (300 seconds) while setting things up. A mistake is then corrected in minutes rather than hours.
Raise it to something normal once everything is settled and stable. A permanently low TTL means more lookups for every visitor, for no benefit once the records stop changing. Understanding DNS Propagation deals with the timing.
Certificates come after DNS, not before
Automatic certificate issuance proves you control the domain by fetching something over it. That cannot work until the domain resolves to your server.
So the order is: DNS first, then add the domain in your control panel, then issue the certificate, then set up the HTTPS redirect. Doing the redirect earlier sends every visitor to a browser warning. Managing AutoSSL in WHM goes into why failures only appear in a log.
Verify each record instead of the website
A loading website confirms the A record and nothing else.
dig example.com A +short dig www.example.com A +short dig example.com MX +short dig example.com TXT +short
Run all four. The last two are the ones that fail silently: a website that stops working is reported in minutes, and mail authentication that was never set up is noticed weeks later, as mail drifting into spam. For reading the output, see DNS Troubleshooting Guide.
Write down what you set
A short note: which nameservers, which records, and why any unusual one exists.
Twelve months later, a record nobody can account for is either load-bearing or leftover, and there is no way to tell from the record itself. That uncertainty is what makes people leave broken things in place indefinitely.
Check each record answers before moving on
Setting several records and testing the website at the end makes a single failure look like a general problem.
for t in A AAAA MX TXT CNAME; do printf '%-6s %s\n' "$t" "$(dig example.com "$t" +short | tr '\n' ' ')" done dig www.example.com A +short
Query each type individually as you add it. A record that returns nothing has either not propagated or was not saved, and those are distinguished by asking the authoritative server directly.
Test the name rather than the browser. A browser caches aggressively and will keep showing an old answer long after the record is correct, which sends people looking for problems that do not exist.
Write down what the records are for
A zone accumulates entries and within a year nobody can say which are still needed.
for t in A AAAA MX TXT CNAME NS CAA SRV; do echo "; $t"; dig example.com "$t" +short done > zone-$(date +%F).txt wc -l zone-*.txt
Save the output with a date and a note next to each entry saying what added it and why.
Verification strings are the ones that matter most here, since they are meaningless on their own and removing the wrong one disconnects a service. A record with no explanation is one nobody will ever dare to delete.