Most DNS problems are not a wrong value in a record. They are the wrong type of record for what someone was trying to do, and the result usually looks like it works until something specific breaks.
This is a decision guide: what you are trying to do, and which record does it.
Point a domain at a server
An A record for IPv4, an AAAA record for IPv6.
Both, if the server has both addresses. A missing AAAA on a server with IPv6 is not a fault; a stale AAAA pointing at an address the server no longer has causes intermittent failure for visitors whose network prefers IPv6, which is much harder to diagnose. See understanding A and AAAA records.
Point a name at another name
A CNAME, which says "this name is an alias for that one" and follows wherever it points.
Right when a service gives you a hostname rather than an address, because they can change the address behind it without you doing anything.
Two rules. A CNAME cannot coexist with other records on the same name, so a name with a CNAME cannot also have an MX or a TXT record. And it cannot be used at the root of the domain in standard DNS, which is why example.com needs an A record while www.example.com can be a CNAME. Understanding CNAME records sets out the exceptions some providers offer.
Receive mail
An MX record, naming the mail server and a priority.
Lower priority is preferred. Multiple MX records give failover, not load sharing: the higher number receives nothing while the lower one answers.
The MX must name a hostname, never an IP address. That hostname needs its own A record, and pointing an MX at a name that is itself a CNAME is invalid, even though many setups appear to tolerate it. For that, see understanding MX records.
Prove something about the domain
A TXT record, which holds arbitrary text and is what almost every verification and policy mechanism uses.
SPF, DKIM and DMARC are all TXT records. So is the verification string a service asks you to add to prove you control the domain.
You can have several TXT records on a name, but only one SPF record. Two SPF records is a configuration error that makes both invalid, and it is the single most common mail DNS fault. Understanding TXT records explains the syntax.
Delegate a subdomain elsewhere
An NS record on the subdomain, naming the nameservers that will answer for it.
Use this when a service runs a whole subdomain and needs to manage its records. Once delegated, records you add for that subdomain in your own zone are ignored. The delegation takes precedence, and that is a genuinely confusing failure if you did not know it happened.
Point at a service on a specific port
An SRV record, which is the only type carrying a port.
Used by mail client autodiscovery, chat and voice protocols, and some game servers. The name is three underscored parts and the target must be a hostname with an A record: never an IP. Understanding SRV records sets out the format.
Restrict who can issue certificates
A CAA record, naming the certificate authorities permitted to issue for your domain.
Cheap, and it narrows a real exposure from "any authority in the world" to the ones you named. Name every authority you actually use, including the one your server uses automatically. A missed one fails at renewal months later. For that, see understanding CAA records.
The choices people get wrong
A CNAME where an A record belongs. At the root of the domain, or on a name that also needs MX or TXT records. The symptom is mail stopping when someone adds a CNAME to a name that was receiving it.
An MX pointing at an IP address. Looks reasonable, is invalid, and fails inconsistently depending on the sending server.
Two SPF records because a second service was added later. Both become invalid; the entries must be merged into one record.
A record type for redirection. DNS points at servers; it does not redirect URLs. Sending visitors from one address to another is a web server job, redirecting a domain or page goes into it, and domain forwarding deals with the registrar-level version.
TTL is a decision too
TTL says how long resolvers may cache the answer. It is not part of the record's meaning and it decides how quickly a change takes effect.
Lower it a day or two before a planned change. The old value has to expire before the new one applies, so lowering it at the moment of the change accomplishes nothing.
Then raise it once things are settled, because a permanently low TTL means more lookups for every visitor. Understanding DNS propagation sets out the timing.
After any change, check what is published
dig example.com MX +short dig example.com TXT +short
Query the record type you changed and confirm what is actually being served, rather than trusting the interface you typed it into.
The two most valuable checks after any DNS work are the MX records and the TXT records, because those fail quietly. A website that stops working is reported in minutes, and mail authentication that stops working is noticed weeks later. The DNS troubleshooting guide goes into querying properly.
If the mechanics underneath are unfamiliar, Introduction to DNS and How It Works explains how a lookup actually works.
One case has no straightforward answer: a service asking for a CNAME at the bare domain. For what to do instead, see Understanding Apex Domains and CNAME Limits.