How DNS Works: A Practical Guide to Domains, Hosting, and Email

DNS (Domain Name System) is one of the most important pieces of your online infrastructure, and also one of the most misunderstood. If your domain name is your address, DNS is the system that tells the internet where that address should lead: your website, your email, and other services your organization relies on.

You don't need to be a network engineer to understand DNS. But knowing the basics helps you prevent downtime, avoid email problems, and maintain control when you change hosting providers or rebuild a site.

What DNS does in one sentence

DNS translates a human-friendly domain name (like 10t.co) into the technical routing information computers need to connect to services.

That includes:

  • your website hosting server
  • your email provider
  • verification records for third-party tools
  • subdomains for portals or apps

Without DNS, your domain can't reliably point to anything.

The DNS "lookup" process

What happens when someone visits your site?

When someone types your domain into a browser:

  1. The browser asks DNS: "Where should I go for this domain?"
  2. DNS returns an IP address or a routing rule.
  3. The browser connects to that destination to load the website.

The same principle applies for email. Mail servers look up DNS records to decide where to deliver messages for your domain

DNS is a routing layer used by many systems, not just browsers.

DNS records: the ones you'll encounter most often

A record (Address record)

Points a domain or subdomain directly to an IPv4 address.

Common uses:

  • example.com → your server IP
  • app.example.com → another server IP

AAAA record

Same as an A record, but for IPv6 addresses.

CNAME record (Canonical name)

Points a name to another name.

Common use:

  • www.example.com → example.com
  • or www.example.com → a hosting provider endpoint

A CNAME is useful when the destination might change, because it follows another DNS name rather than a fixed IP.

MX record (Mail exchange)

Tells the internet where to deliver email for your domain.

If MX records are wrong:

  • email stops arriving
  • email may bounce
  • deliverability can become inconsistent

TXT record

A text record used for many purposes, especially verification and email authentication.

Common uses:

  • verifying domain ownership for services
  • SPF, DKIM, and DMARC (email trust and deliverability)
  • security/verification tokens for integrations

NS record (Name server)

Defines which DNS provider is authoritative for your domain.

If you change name servers, you are effectively telling the domain to use a different DNS "control panel" for all records.

The simplest way to think about DNS records

  • A / AAAA: "This name goes to this IP"
  • CNAME: "This name is an alias of that name"
  • MX: "Email goes here"
  • TXT: "Verification and policy info lives here"
  • NS: "This is the DNS provider in charge"

That mental model is enough for most practical decisions.

DNS and email: why correct records matter

Most organizations care about email reliability as much as website uptime.

Beyond MX records, modern email uses DNS for authentication:

  • SPF (TXT record): lists which servers are allowed to send mail for your domain
  • DKIM (TXT record): cryptographic proof that mail wasn't altered and was authorized
  • DMARC (TXT record): policy and reporting for handling unauthenticated mail

Even if you don't configure these yourself, it's important to understand that DNS is the mechanism behind professional email deliverability.

TTL and propagation: why changes take time

TTL (Time To Live)

TTL is the amount of time a DNS answer is considered "fresh" and can be reused from cache. If a record has a TTL of 1 hour, a resolver that looks it up may keep using the cached answer for up to an hour before it asks again.

Propagation

"Propagation" is not a single switch that flips across the internet. It's the combined effect of many independent caching systems refreshing DNS at different times, based on TTL and local cache behavior.

What is actually happening behind the scenes

When someone visits your domain, their device typically doesn't talk to the authoritative DNS servers directly. It asks a DNS resolver (often operated by an ISP, a corporate network, a router, or a public resolver). That resolver is designed to cache results to reduce load and speed up browsing.

A simplified flow looks like this:

  1. User's device asks a resolver
    "What is the IP address for 10t.co?"
  2. If the resolver has a cached answer and the TTL has not expired
    It returns the cached result immediately. No "fresh lookup" is performed.
  3. If the resolver does not have an answer, or the TTL has expired
    It performs a full lookup, asking the authoritative DNS servers for the current record value.
  4. Resolver caches the new answer for the TTL period
    From that point forward, you (or anyone else) using that resolver may continue receiving that cached answer until that TTL expires again.

This is why DNS changes feel like they "roll out." Different resolvers around the world refresh at different times depending on when they last cached the record and what TTL was set. Some users will see the new destination quickly, while others may still reach the old destination until their resolver's cached record expires.

Practical takeaway

If you know a DNS change is coming (like a hosting migration), it's common to lower the TTL ahead of time (for example, from 1 hour to 5 minutes) so cached results expire faster during the transition. After the cutover is stable, the TTL can be raised again.

DNS routes. It doesn't redirect.

DNS tells the internet where a service lives.

It does not perform URL redirects or change what someone sees. Redirects happen after the connection is made, typically at the web server or application level.

Common DNS mistakes (and how to avoid them)

Changing name servers without understanding the impact

If you switch name servers, you must recreate your DNS records at the new provider. If you don't:

  • your website may go down
  • email may stop
  • verification records may break

Mixing records across multiple DNS providers

For clarity and stability, keep authoritative DNS in one place.

Leaving old records behind

Old records can create confusion and sometimes security risk. Periodically review:

  • outdated A records
  • old CNAMEs
  • stale verification TXT records

Incorrect redirects vs DNS changes

DNS does not "redirect" a visitor to a different URL. DNS only routes the connection.

When you'll need DNS changes in real life

DNS changes commonly happen when you:

  • change hosting providers
  • switch email providers
  • add a subdomain (portal, app, shop, etc.)
  • verify your domain for a new service
  • configure email authentication (SPF/DKIM/DMARC)
  • rebuild a site and move to a new server

Knowing the basics makes these transitions smoother and less risky.

If you're unsure where your DNS is managed, whether your records are correct, or how your domain ties into hosting and email, 10T Web Design can help you map it cleanly and stabilize it.

The goal is simple: keep your website and email reliable, and keep your organization in control of its infrastructure.

Request a Quote View Our Work