Written for the moment somebody sends you an email asking you to "update the A record" and you would rather not admit you have no idea what that means.
DNS is the address book of the internet. Your domain is the name; DNS records are the entries that say where each service for that name actually lives. One record sends web visitors to your website. A different one sends email to your mail provider. They are independent, which is why a website can be down while email works perfectly, and the reverse.
Almost everything confusing about domains comes from that separation, and from the fact that three different companies are usually involved: the one you rent the name from, the one running your website, and the one handling your mail.
Get this straight and most of the rest follows.
When a change does not take effect, the cause is very often that somebody edited records at the registrar while the nameservers point somewhere else entirely. The edits were real and are simply being ignored.
Nine terms cover almost every request you will ever receive.
Entirely invisible. The changes save successfully, they simply have no effect, because a different company is answering the questions. Always establish where DNS is actually served from before changing anything.
Adding a new sending service and creating a fresh SPF record alongside the existing one feels correct and is not: the standard permits exactly one, and two make it invalid. The result is mail quietly failing authentication, which usually shows up as messages landing in spam rather than as an error anyone sees.
Multiple senders belong in a single record, combined. If you are adding a newsletter tool or a booking system that sends on your behalf, that is the moment to check.
DNS is one of the few areas where a small mistake takes everything down at once, which is why plenty of owners would rather hand it over. Both options are fine.
Because the answer you changed is cached all over the internet. Every record carries a TTL, a number of seconds that says how long anyone may remember the answer before asking again. Until that expires, machines keep using the old value quite correctly.
This is why you lower the TTL before a planned move, not after. Drop it a day ahead and the actual switch propagates in minutes instead of hours.
The registrar is who you rent the domain name from. The host is the machine your website actually runs on. They are frequently different companies, and the confusion between them is behind a large share of the panic we get called into.
The connection is DNS: records at the domain point visitors and mail to whichever host holds each service. You can change hosts without touching the registrar, and change registrars without moving the site.
The business. Not an employee, not a web designer, not an agency, however convenient it seemed at the time.
The domain is the one asset everything else hangs off. If somebody else owns it, they can take your website and your email away, and your only recourse is a legal argument. This is not usually malice, it is usually just how it got set up, but the risk is identical either way. See technical cleanup if you suspect this describes you.
Not in detail. What is genuinely worth knowing is which company holds your domain, who can log in there, and that mail depends on records you can break by accident.
The rest you can look up when it matters, which is exactly what this page is for.
DNS, SSL, caching and protection, configured properly.
Untangle the accounts, domains and logins nobody has a full list of.
Authentication, reputation, and the fixes that actually move the needle.
The settings worth getting right when you set up or inherit a tenant.
Move mailboxes to a new provider without losing mail or downtime.
What to verify before and after a site goes live.
Reasonable. DNS is one of the few areas where a small mistake takes your email down for everyone at once. Tell us what needs changing.