DNS Records: The Invisible Infrastructure Behind Every Website Visit
The web browser is, in a sense, completely clueless about where to go when you type a website address. It does not know where google.com lives. What it needs is an IP address, something like 216.58.216.164, which is the actual location of the server hosting that website. The browser has the name but not the number.
This is the problem DNS solves. A Domain Name Server maps human-readable URLs to IP addresses, acting as the directory the browser consults before it can load anything.
But DNS is not just one thing. A domain has several different jobs to do: serve a website, receive email, prove ownership, handle subdomains. Each of those jobs is handled by a different type of record stored on the DNS server. These are called DNS Records, and they are the instructions the server follows when it gets a query about your domain.
Here is what each one does.
NS Records: Who is in charge?
Before the DNS server can answer any questions about your domain, the internet needs to know which DNS server to ask. That is what NS (Name Server) Records handle.
Think of it like calling a company's toll-free number. Before you get to anyone useful, an automated menu figures out which department to send you to. NS records are that routing layer. They tell the internet: "For anything related to this domain, go ask these name servers."
example.com → NS records point to → ns1.nameserver.com
→ ns2.nameserver.com
You typically get NS records from your domain registrar or DNS provider (Cloudflare, Namecheap, GoDaddy, etc.) and you rarely need to touch them manually.
A Records: Where is the Website?
Once the right DNS server is located, the most common question it gets is: "What IP address does this domain map to?" That answer lives in an A Record.
An A record creates a direct link between a domain name and an IPv4 address. IPv4 is the format you have seen your whole life: four numbers separated by dots.
example.com → A record → 171.184.216.34
www.example.com → A record → 171.184.216.34
blog.example.com → A record → 198.51.100.1
A domain can have multiple A records pointing to different IP addresses. When that happens, traffic gets distributed across several servers, which is called load balancing. If one server goes down, the others can still respond.
AAAA Records: The Same Thing, But for IPv6
IPv4 addresses only have about 4.3 billion possible combinations. The internet ran out of them. IPv6 was created to fix that, using a much longer address format that makes running out practically impossible.
AAAA records work exactly like A records, but they map a domain to an IPv6 address instead.
example.com → A record → 171.184.216.34
example.com → AAAA record → 2001:db8::8a2e:370:7334
Most websites today have both. Modern devices prefer IPv6 when it is available and fall back to IPv4 when it is not, so having both records means your site stays reachable regardless of the visitor's setup.
CNAME Records: One Name, Multiple Aliases
Say your website is example.com and you want www.example.com, blog.example.com, and shop.example.com all pointing to the same place. You could set up a separate A record for each, but then if your server IP ever changes, you have to update every single one.
CNAME (Canonical Name) Records solve this by letting subdomains point to another domain instead of directly to an IP. You update the main domain's A record once, and everything that CNAMEs to it follows automatically.
www.example.com → CNAME → example.com
blog.example.com → CNAME → example.com
shop.example.com → CNAME → example.com
Shah Rukh Khan, SRK, and King Khan are all the same person. CNAME is just DNS doing the same thing.
One rule worth knowing: you cannot use a CNAME on your root domain (example.com itself). Use an A record there. CNAME is for subdomains.
MX Records: Where Does Email Go?
When someone sends a message to user@example.com, the email server sending it needs to know which server to deliver it to. That information lives in MX (Mail Exchange) Records.
MX records tell email services which server handles incoming mail for your domain. They also carry a priority number: lower numbers get tried first. If the primary mail server is unreachable, email falls back to the one with the next lowest priority.
example.com → MX 10 mail1.example.com
example.com → MX 20 mail2.example.com
Note: The number (10, 20) is the priority, lower numbers are tried first.
If you use Google Workspace, Microsoft 365, or any hosted email service, they give you a specific set of MX records to add. Without them, email sent to your domain has nowhere to go.
TXT Records: Verification and Email Security
TXT Records were originally just meant to hold human-readable notes. Today they do a lot more than that, mostly around proving you own your domain and protecting your email from being spoofed.
Domain Ownership Verification
When you sign up for Google Workspace or a similar service, they ask you to add a TXT record to prove you control the domain. Only the actual domain owner can add records to a DNS zone, so adding their verification string is proof enough.
example.com → TXT → "google-site-verification=abc123def456"
Email Security
Three TXT-based standards work together to protect your domain's email:
SPF (Sender Policy Framework) tells receiving mail servers which servers are authorized to send email on behalf of your domain. If an email claims to be from @example.com but came from a server not listed in your SPF record, it can be flagged or rejected.
example.com → TXT → "v=spf1 include:_spf.google.com ~all"
This record says: only Google's mail servers are allowed to send from @example.com.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing emails, so the receiving server can verify the message was not tampered with in transit and actually came from you.
default._domainkey.example.com → TXT → "v=DKIM1; k=rsa; p=MIGfM..."
DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do when an email fails SPF or DKIM checks. You can instruct them to reject the email, send it to spam, or just report it back to you.
_dmarc.example.com → TXT → "v=DMARC1; p=quarantine; rua=mailto:reports@example.com"
This one says: if authentication fails, put the email in spam and send a report to the address listed.
These three work as a team. SPF says who can send. DKIM proves the email was not altered. DMARC decides what happens when either of those checks fail.
Complete DNS Flow
Quick Reference
| Record | What it does | When you use it |
|---|---|---|
| NS | Points to the name servers managing your DNS | Set by your registrar, rarely changed |
| A | Maps domain to IPv4 address | Main website, subdomains |
| AAAA | Maps domain to IPv6 address | Modern IPv6 support |
| CNAME | Points one domain name to another | Subdomains, CDN aliases |
| MX | Routes email to the right mail server | Any domain that receives email |
| TXT | Stores text data | Verification, SPF, DKIM, DMARC |
DNS records are not as intimidating as they look once you understand what each one is responsible for. NS records know which server to ask. A and AAAA records know where the website lives. CNAME makes aliases easier to manage. MX handles email delivery. TXT handles everything from proving ownership to keeping your email from being used for spam.
None of these records works in isolation. Together they form the full picture of how a domain operates: who manages it, where it lives, who can email through it, and whether it can be trusted.
The next time you deploy a project and need to configure DNS, you will know exactly which record to reach for and why.
