Every time someone types your domain name into a browser, before any page loads, a lookup happens. It does not check your server. It does not check your hosting account. It queries a global system of directories, distributed across thousands of servers worldwide, to get the answer: where does this domain actually live? That system is the Domain Name System. Most people who depend on it every day have only ever touched it once, usually when they first set up their website, and never thought about it again. Until something breaks.
Why DNS Exists at All
The internet routes traffic by IP address. Every server has one: a numerical address like 104.21.23.89. But humans remember names, not numbers. DNS is the translation layer between the two.
Think of it as the internet's phone book. But instead of one central directory, it is a distributed network of millions of servers, each authoritative for a slice of the namespace. When a browser needs to reach felixmaru.com, it asks a chain of these servers in sequence until one gives a definitive answer. The whole process takes milliseconds. You never see it happen.
The catch: your domain does not have one record. It has a set of them, each responsible for a different type of traffic. Get any one wrong and something stops working. Get two wrong and you might spend a full afternoon wondering why everything broke at once.
The A Record: Where Your Website Lives
The A record maps a domain name to an IPv4 address. It is the core routing record. When someone types your domain into a browser, the A record tells the internet which server to send them to.
Most domains have an A record for the bare domain (example.com) and a separate one for www (www.example.com). They can point to the same IP address or to different ones. If your A record points to an old server after a migration, every browser request goes to the wrong place. The new site is live, but nobody can find it.
There is also an AAAA record, the same concept for IPv6 addresses. Most setups handle both, but the A record is the one you will check first when something seems wrong.
The MX Record: Where Email Goes to Land
The MX record is the Mail Exchange record. It tells the internet which server accepts inbound email for your domain. Without a correct MX record, email sent to you has nowhere to land. It does not bounce immediately. It just gets queued, retried, and eventually returned to the sender with a delivery failure notice, sometimes hours later.
This is the record that causes the most dramatic silences after a domain migration. Everything looks fine in the dashboard. The website loads. But inbound email stops arriving because the MX record still points at the old mail server, or the new one was never added.
MX records also carry a priority number. If you have multiple mail servers (a primary and a backup), the one with the lowest priority number gets tried first. Most hosted email setups (Google Workspace, Microsoft 365) give you their exact MX record values to copy in. Copy them precisely and keep nothing left over from the previous provider.
TXT, CNAME, and NS: The Supporting Cast
Beyond A and MX, three more record types do critical work that most people do not realize exists until something fails.
TXT records are freeform text fields that serve a surprising number of purposes. The most important for most businesses: your SPF record (which specifies which mail servers are authorized to send on your behalf) lives here as a TXT record, alongside your DKIM public key and your DMARC policy. If a hosting provider overwrites your TXT records during setup, your outbound email authentication fails silently. Cold outreach, transactional email, support replies, all of it lands in spam or gets rejected. The DNS record page shows the new TXT entry. You have to look at the actual record value to see that the old SPF entry is gone.
CNAME records are aliases. Instead of pointing a subdomain directly to an IP address, a CNAME points it to another domain name, and the DNS system resolves that name in turn. This is how mail.example.com can point to your email provider's infrastructure without you needing to know their IP address. It is also how most CDN and load-balancer setups work. The one rule: you cannot use a CNAME on the bare domain (example.com itself), only on subdomains.
NS records are the Name Server records. They tell the internet which DNS provider is authoritative for your domain. Every other record you set only matters if the NS records point to the right place. This is the record that gets people in trouble when they switch hosting providers: they update everything inside the new DNS dashboard, but if the domain registrar still lists the old name servers in the NS records, every lookup goes to the server they just left. Nothing works, and nothing in the new dashboard is to blame.
TTL: Why Changes Take Time to Spread
Every DNS record carries a TTL, a Time To Live, measured in seconds. It tells every caching resolver on the internet how long to hold the answer before checking again. A TTL of 86400 means 24 hours. A TTL of 300 means 5 minutes.
When you change a record, the old answer lives in caches around the world until their TTL expires. Someone in Nairobi might get the new answer immediately while someone in Amsterdam is still hitting the old server for another 20 hours. This is DNS propagation.
The fix, if you know a change is coming, is to reduce your TTL well in advance. Drop it to 300 seconds a day or two before a planned migration. Caches expire fast, the old values drain out, and when you flip the actual record, the new answer spreads in minutes rather than a day. Restore the higher TTL once the migration is confirmed stable.
Propagation is not a bug in DNS. It is a feature that prevents every name lookup from having to hit a central server in real time. The trade-off is that changes are not instant.
The Most Common Breaks I Have Seen
Most DNS problems are one of four things.
A stale MX record after a migration. The website loads fine on the new host. But inbound email silently stops arriving because nobody updated the MX record to point at the new mail server. Often noticed hours later when someone says "I sent you an email this morning and never heard back."
An overwritten TXT record. A new hosting provider adds a domain verification entry during setup and, in doing so, replaces the existing SPF record. Outbound email starts failing authentication. Deliverability drops quietly over days before anyone connects it to the DNS change last week.
NS records pointing at the old provider. Everything in the new dashboard is set up correctly, but the registrar still lists the old name servers. Every lookup goes to the provider you thought you left. The fix is at the registrar, not the DNS dashboard.
Three Tools to Check Your Records Right Now
You do not need terminal access to audit your DNS. These tools cover most situations:
- MXToolbox: free lookup for MX, A, TXT, and more. It flags common problems and confirms your records match what you expect.
- whatsmydns.net: shows the answer from dozens of resolvers simultaneously, across different regions. Useful during a migration to confirm propagation is spreading.
- dig (Mac, Linux) and nslookup (Windows): command-line tools that query DNS directly.
dig @8.8.8.8 yourdomain.com MXasks Google's resolver for your MX records, bypassing any local cache.
One habit I keep: before touching any DNS record, I copy the full current zone to a note. Not a screenshot. A plain text list of every record and its value. It takes two minutes and has saved me more than once when a change did not go as planned and I needed to know exactly what was there before.
DNS is invisible when it works. It only surfaces when something goes wrong, usually at the worst moment: a domain migration on the day of a product launch, an MX error during a sales push, an NS pointing nowhere on a holiday weekend. Understanding what each record type does and why TTL matters is not advanced knowledge. It is the kind of thing that turns a mystery outage into a five-minute fix.
Have a DNS question about your own setup? Reach out and we can look at it together.
Comments