Computers route traffic using IP addresses. People remember names. DNS is the system that translates one into the other, and almost every website outage that is not the server's fault happens somewhere inside it.
What happens when someone visits your site
A visitor types your domain. Their resolver — usually run by their internet provider — asks the root servers which nameservers are responsible for the top-level domain, then asks those which nameservers are responsible for your domain, then asks yours what the actual answer is.
That answer is a DNS record. The resolver caches it for a period set by the record's TTL, which is why changes are not visible everywhere at once.
The records you will actually use
A record. Points a hostname to an IPv4 address. This is the one that connects your domain to your server. example.com → 192.0.2.10.
AAAA record. The same thing for IPv6. Worth setting alongside the A record; some networks prefer IPv6 and there is no downside to answering both.
CNAME record. Points one hostname at another hostname rather than at an address. Useful when the destination's address may change and somebody else manages it — a CDN endpoint, a status page, an external service. The important restriction: a CNAME cannot coexist with other records on the same name, which is why it generally cannot be used on the bare domain.
MX record. Names the mail servers that receive email for your domain, with a priority number where lower wins. Email will not arrive without it, and it is entirely independent of where your website is hosted.
TXT record. Free-form text attached to a name. In practice it carries SPF policies, DKIM keys, DMARC policies and the verification strings services ask you to add to prove you own the domain.
NS record. Declares which nameservers are authoritative for the zone. This is the record that decides which DNS provider is actually in charge.
PTR record. Maps an IP address back to a hostname — reverse DNS. It lives with whoever controls the IP address rather than in your zone, and mail servers check it when deciding whether to trust outgoing mail from your server.
The three email records, in plain terms
SPF lists which servers may send mail using your domain. DKIM adds a cryptographic signature so a receiving server can verify a message really came from you and was not altered. DMARC tells receiving servers what to do when a message fails those checks, and can send you reports about mail claiming to be from your domain.
All three are published as DNS records. Getting them wrong is the usual reason legitimate email lands in spam.
TTL, and why changes seem not to work
Every record carries a TTL — the number of seconds a resolver may cache the answer before asking again. A record with a 24-hour TTL can keep serving the old value to some visitors for a full day after you change it.
This is what people mean by DNS propagation. Nothing is actually propagating; caches are simply expiring at different times. The practical technique is to lower the TTL to a few minutes at least one full old-TTL period before a planned migration, make the change, confirm it, then raise the TTL back to reduce query volume.
When something is wrong
Check what the authoritative nameserver is actually serving rather than what your computer thinks: dig @your-nameserver example.com A. If that answer is correct but users see something else, you are looking at caching, and the fix is patience or a lower TTL next time.
If the authoritative answer itself is wrong, check the NS records. A surprising share of DNS problems are configuration changes made carefully in a control panel that is no longer the one in charge of the zone.