DNS seems like magic: type domain.com and you're there. No IP, no numbers. Because millions of servers globally translate "example.com" to "192.0.2.1" in fractions of a second and take you there. DNS records are the language these servers use to speak to each other.
But "enter an A record and forget" is like driving without understanding engine oil. Eventually something breaks. Emails fail if you forgot MX. Site on one IP, CDN on another—traffic routes wrong. TXT records empty, domain gets spammed in attacker's name.
How DNS Resolution Works
When you type example.com, a chain of events queries different DNS servers at different stages. It's not instant or "somewhere online"—specific protocol, specific servers, specific order.
Step 1: Recursive resolver — your ISP (or Cloudflare 1.1.1.1, Google 8.8.8.8) catches the request from your browser and says: "I'll help you find the IP address for example.com".
Step 2: Root nameserver — resolver asks a root server (13 exist worldwide) where to find information about .com domains. The root server answers: "ask this TLD server".
Step 3: TLD nameserver — resolver asks the TLD server (which knows about all .com domains) where to find example.com. The TLD server answers: "ask the authoritative nameserver there".
Step 4: Authoritative nameserver — resolver asks the authoritative server (the one you configured at your registrar). It responds: "The A record for example.com is 192.0.2.1". The resolver returns this answer to the browser, and the browser connects to the IP address.
This entire process takes 50-200 milliseconds, because results cache at each step. If the resolver already asked about example.com 5 minutes ago (within the TTL lifetime), it doesn't repeat the entire process — it simply returns the cached answer.
A Record: Foundation of Web Addressing
An A Record is the most basic type. It maps a domain name to an IPv4 address. When you create a site and your host gives you an IP (e.g., 192.0.2.1), you add an A Record:
example.com A 192.0.2.1It means: "when someone tries to connect to example.com, give them IP 192.0.2.1". Browser gets this IP and connects to port 80 or 443.
When to use: When your site is on a specific server, host, or VPS with fixed IP. Direct pointer to one IP address.
Mistake #1: Wrong IP. You copied the hosting IP incorrectly. It seems simple, but double-check. The browser won't say "you have the wrong IP" — it just won't connect.
Mistake #2: Forgetting www. example.com and www.example.com are different domain names. If you have an A Record for example.com but not for www.example.com, then www.example.com won't work. Add a second A Record or use CNAME (see below).
AAAA Record: IPv6 Addresses
An AAAA Record is the same as an A Record, but for IPv6 addresses (which are long and alphanumeric: 2001:db8::1). As IPv4 addresses become scarce, IPv6 becomes increasingly important. Many regions are already transitioning to IPv6-only.
example.com AAAA 2001:db8::1The browser will try to connect via IPv6 first, and if it fails, fall back to IPv4 (A record). Good practice: add both records if your host supports IPv6.
When to use: If your hosting provides IPv6, definitely add an AAAA Record. This improves compatibility, especially in networks where IPv4 is exhausted. As of 2026, this is no longer just a nice-to-have—it becomes mandatory for new projects.
CNAME Record: Alternative Names
CNAME (Canonical Name) is like a pointer to another domain name. Instead of specifying an IP address, you say "use the records for another domain":
www.example.com CNAME example.com
blog.example.com CNAME myblog.wordpress.comThis is useful for subdomains. Want www.example.com to resolve to the same IP as example.com? Create a CNAME. Want blog.example.com to point to WordPress hosting? CNAME to WordPress.
When to use: For subdomains (www, blog, api, cdn). When your subdomain points to an external service (CDN, website builder, cloud hosting). When you want to manage the IP address centrally and change it in one place.
Critical limitation: CNAME doesn't work at the apex (root). You CANNOT say "example.com CNAME example.com". It would loop. At root, use an A record, then CNAME for www and other subdomains.
Mistake #1: CNAME with other records. If you add CNAME to www.example.com, you can't add TXT or MX to www.example.com at the same time. When DNS sees CNAME, it ignores all other records for that name.
Mistake #2: Missing trailing dot. CNAME target should be "example.com." (with dot), not "example.com". Without the dot, DNS interprets it as "example.com.example.com" — a recursive name that doesn't exist.
MX Records: Mail Routing
MX record (Mail eXchange) tells where email for your domain goes. When someone sends email to example@example.com, the sender's mail server checks example.com's MX records and delivers the mail there.
example.com MX 10 mail1.example.com
example.com MX 20 mail2.example.com
example.com MX 30 mail3.example.comThe numbers (10, 20, 30) are priorities. Lower = higher priority. Sender's server tries mail1 first (priority 10). If mail1 doesn't respond, tries mail2. If mail2 doesn't respond, tries mail3. This redundancy ensures email doesn't get lost if one mail server is temporarily down.
When to use: Always, if you receive mail at domain addresses. Even if you use Google Workspace, Microsoft 365, or cloud email—they provide specific MX records to add.
Mistake #1: Wrong mail server. You copied the MX host incorrectly. Check your mail provider's docs twice. MX must point to an existing server.
Mistake #2: Missing MX record. Without an MX record, mail still gets delivered, but DNS server might try connecting to the domain's A record (old behavior). Unreliable. Add MX records explicitly.
Mistake #3: Priority problem. If all MX records have the same priority, sender's server picks randomly. If one is wrong, half your mail is lost. Ensure priorities are different and in order.
TXT Records: Security and Verification
TXT record stores arbitrary text. It's the most versatile record type, used for many purposes: domain ownership verification, spam prevention, mail encryption, website security.
example.com TXT "v=spf1 include:_spf.google.com ~all"
example.com TXT "google-site-verification=ABC123XYZ"
default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0..."There are three main types of TXT records for security:
SPF (Sender Policy Framework). This TXT record says: "email from example.com can only be sent from these IPs or servers". When a receiving server gets mail from example.com, it checks the SPF record and verifies the IP is authorized. If not, mail is marked spam or rejected.
DKIM (DomainKeys Identified Mail). This is cryptographic email signing. DKIM record contains a public key that receiving servers use to verify the email's signature. If mail came from an authorized server, signature is valid. If someone forged the email, signature won't match.
DMARC (Domain-based Message Authentication, Reporting, and Conformance). This is a policy saying: "if SPF or DKIM fails, do this". Three modes: none (monitor but don't block), quarantine (spam folder), reject (reject completely).
TXT records are also used for domain ownership verification. When you connect a domain to Google Search Console, Cloudflare, Let's Encrypt, or other services, they ask you to add a TXT record with a unique value. This proves you control the domain's DNS.
Mistake #1: Wrong SPF format. SPF must be in quotes and start with "v=spf1". If you forget quotes or write "v=spf2", SPF won't work. Receiving servers will ignore it.
NS Records: Authority Delegation
NS records (NameServer) specify which nameservers are responsible for your domain. These records are at your domain registrar (GoDaddy, Namecheap, Google Domains). When a TLD server looks up NS records for example.com, it learns which nameservers know all records for example.com.
example.com NS ns1.example.com
example.com NS ns2.example.com
example.com NS ns3.example.comYou rarely edit NS records manually. They're set at domain registration and point to your hosting's or DNS provider's nameservers (Cloudflare, Route53, Linode DNS). Switching DNS providers means changing NS records at your registrar.
SOA Record: Zone Authority
SOA record (Start of Authority) describes who's responsible for your domain's DNS zone. It contains:
example.com SOA ns1.example.com postmaster.example.com (
2026032801 ; serial (date+version)
3600 ; refresh (check every 60 minutes)
1800 ; retry (if auth server down, retry in 30 min)
604800 ; expire (if auth server down long, forget zone after 7 days)
86400 ; minimum TTL (min cache time for all records)
)The SOA Record is set automatically, and you rarely need to change it. But its parameters are important for DNSSEC (digital DNS zone signing) and for secondary nameservers (servers that replicate your zone).
SRV Record: Service Discovery
SRV record points to specific service on specific host at specific port. Rarely used but critical for some protocols (SIP, XMPP, Kerberos).
_sip._tcp.example.com SRV 10 60 5060 sip.example.com
_xmpp._tcp.example.com SRV 5 0 5222 xmpp.example.comFormat: _service._protocol.domain SRV priority weight port target
- service —service name (sip, xmpp, ldap)
- protocol —tcp or udp
- priority —lower = higher priority (like MX)
- weight —for load balancing between servers with same priority
- port —port where service listens
- target —host where service runs
CAA Record: Certificate Issuance Control
A CAA (Certification Authority Authorization) record restricts which Certificate Authorities (CAs) can issue certificates for your domain. Without CAA, any CA could potentially issue a fake certificate for your domain (if you forget verification at registration).
example.com CAA 0 issue "letsencrypt.org"
example.com CAA 0 issuewild "letsencrypt.org"
example.com CAA 0 iodef "mailto:security@example.com"This says: "Only Let's Encrypt can issue certificates for example.com. If anyone else tries, send a report to security@example.com". This is powerful protection against domain compromise and malicious certificate issuance.
PTR Record: Reverse DNS
PTR record (Pointer) is reverse lookup: instead of "what's example.com's IP?", it answers "what domain owns IP 192.0.2.1?" Used mainly for email authentication verification and diagnostics.
1.2.0.192.in-addr.arpa PTR mail.example.comTo set up a PTR record, you need control over the IP address (usually from your hosting provider). When a mail server receives an email from IP 192.0.2.1, it looks up the PTR record and sees "this is mail.example.com". If the PTR doesn't match the sender's domain, the email may be marked as spam.
Comparison: A Record vs CNAME Record
| Parameter | A Record | CNAME Record |
|---|---|---|
| Points to | IPv4 address | Domain name |
| On apex (root) | Yes | No |
| On subdomain | Yes | Yes (CNAME usually chosen) |
| DNS queries | 1 query (A Record → IP) | 2+ queries (CNAME → domain → IP) |
| Speed | Slightly faster | Slightly slower (due to extra query) |
| Can coexist with MX/TXT | Yes | No |
| Portability | If IP changes, record must be updated | Target IP can change, record stays the same |
Practical rule: use A Record for root domain (example.com), CNAME for subdomains (www.example.com, api.example.com).
TTL: Managing Caching
TTL (Time To Live) is a number in seconds that tells DNS resolvers how long to cache the answer. TTL 3600 means "remember this answer for 1 hour, then ask again."
Low TTL (300–1800 seconds): Changes propagate quickly (within 5–30 minutes). Needed before domain or IP migration. Downside: more load on authoritative nameservers because resolvers query frequently.
Standard TTL (3600–7200 seconds): 1-2 hours cache. Good middle ground for most sites. Reasonably efficient, and changes are visible relatively quickly.
High TTL (86400 seconds and above): 1+ day caching. Minimal nameserver load, maximum resource efficiency. But if you need to migrate, changes aren't visible immediately. Use this if you're confident the IP won't change for months.
Correct workflow: Planning a migration? Lower the TTL to 300 seconds one day before. After successful migration, wait 24 hours, then return to normal TTL. This guarantees fast change propagation without parallel traffic between old and new IP.
How to Check Your DNS Records
Don't blindly trust everything is correct. Verify DNS records:
Using dig (Linux/Mac):
dig example.com A
dig example.com MX
dig example.com TXT
dig example.com AAAAUsing nslookup (Windows/Linux/Mac):
nslookup example.com
nslookup -type=MX example.comOnline DNS checker: AtomPing DNS Lookup — free tool to check all domain records in one place. Enter your domain and see A, AAAA, MX, TXT, NS, SOA, CAA records all at once.
What to look for in output:
- A Record points to correct host IP
- MX records in correct priority order
- TXT records contain SPF, DKIM, DMARC (if you send emails)
- NS records point to your DNS provider
- No garbage records you didn't add
Common DNS Mistakes and How to Avoid Them
Mistake 1: Wrong IP in A Record. You copied the IP with typos or it's an old hosting IP. Result: site is unreachable. Solution: triple-check the IP before adding the record.
Mistake 2: CNAME on apex domain. You added CNAME to example.com instead of www.example.com. Result: domain completely broken, no records work. Solution: always use A Record at apex, CNAME on subdomains.
Mistake 3: Missing MX records. You added only an A Record, forgot about MX. Result: emails don't arrive. Solution: add MX records according to your mail provider's documentation.
Mistake 4: Incorrect SPF record. You forgot brackets or specified the IP incorrectly. Result: emails are marked as spam. Solution: use an SPF generator (e.g., dmarcian.com) to create the correct record.
Mistake 5: Very high TTL during migration. TTL of 86400 (1 day), and you urgently need to change IP. Result: some traffic goes to the old IP for a week. Solution: plan migration in advance, lower TTL a day before.
Mistake 6: Missing dot at end of CNAME target. You wrote "example.com" instead of "example.com." (with a dot). Result: CNAME resolves to "example.com.example.com", which doesn't exist. Solution: always add a dot at the end of the CNAME target.
Mistake 7: www and non-www point to different IPs. www.example.com on one server, example.com on another. Result: redirects, duplicate content, SEO issues. Solution: use CNAME for www.example.com pointing to example.com and maintain one "canonical" version.
Monitoring DNS in Production
DNS is critical infrastructure. If broken, site unreachable, emails fail, APIs down. Monitor DNS like you monitor your main site.
DNS Lookup check. Periodically query your domain (e.g., every 60 seconds) and verify the resolver returns the correct IP. If the IP changes unexpectedly—this is a sign of compromise or config error.
Quorum DNS checks. Check DNS resolution from different regions and different resolvers. If DNS works from Europe but not from Asia—this is a BGP or local resolver issue. AtomPing monitors DNS resolution from 11 regions, so you see problems before users do.
Complete Checklist for DNS Setup
Before launch:
- Add A Record for example.com
- Add CNAME for www.example.com (or second A Record if different IP)
- Add AAAA Record (if host supports IPv6)
- Add MX records (if you receive emails)
- Add SPF TXT record (if you send emails)
- Add CAA Record (certificate restrictions)
After adding:
- Verify all records via dig/nslookup/online tool
- Ensure NS records point to your DNS provider
- Test connecting to the site from different devices
- Send a test email to an external address (if using custom domain for email)
In production:
- Set up DNS resolution monitoring (use DNS Lookup check)
- Get alerts if DNS stops working
- Check DNS from multiple regions (multi-region monitoring)
Conclusion
DNS is not magic. This is a specific protocol with specific records, each with its own purpose. A Records route traffic, MX records route emails, TXT records store security information.
Understanding record types is critical for domain management, hosting migration, email configuration, spam prevention, and ownership verification. DNS errors are often the first cause of site unavailability, lost emails, and compromised domains.
Don't rely on "it probably works". Verify DNS records via dig or DNS Lookup tool. Monitor DNS resolution from different regions (AtomPing checks DNS from 11 European regions). If DNS is broken—this is problem number 1 in production. Treat it accordingly.
Related Resources
FAQ
What is a DNS record and why do I need them?
A DNS record is a piece of information stored in your domain's DNS zone that tells the internet how to route traffic and services. Without DNS records, people couldn't find your website by typing its domain name — they'd need to remember your IP address. DNS records also direct email to the right servers, verify domain ownership, and secure communications. You need DNS records because they're the foundation of how your domain works on the internet.
What is the difference between A records and CNAME records?
An A record maps a domain name directly to an IPv4 address (e.g., example.com → 192.0.2.1). A CNAME record is an alias that points to another domain name (e.g., www.example.com → example.com). Key difference: A records point to IPs, CNAME records point to domain names. You cannot use a CNAME at your domain apex (root), but you can use A records. CNAME records are useful for pointing subdomains to CDNs or load balancers.
What are MX records and how do they work?
MX (Mail eXchange) records tell email servers where to send mail for your domain. They contain a priority number (lower = higher priority) and a mail server address. When someone sends mail to user@example.com, the sender's server looks up the MX records for example.com and delivers the mail to the highest-priority (lowest number) mail server listed. If that server is down, the sender retries with the next priority MX record. This redundancy ensures email doesn't bounce if one mail server is temporarily offline.
What does a TXT record do and why is it important?
TXT records store text-based information associated with your domain. Common uses: SPF records prevent email spoofing by specifying which servers are authorized to send mail from your domain, DKIM records cryptographically sign outgoing emails, DMARC records define what to do with unsigned emails. TXT records also verify domain ownership (required for Let's Encrypt, Google Search Console, etc.). Without proper TXT records, your emails may be rejected as spam, and your domain security is weaker.
What is the TTL (Time To Live) and why does it matter?
TTL is a number (in seconds) that tells DNS resolvers how long they can cache a DNS record before checking the authoritative nameserver again. Low TTL (e.g., 300 seconds = 5 minutes) means changes propagate quickly but increases load on nameservers. High TTL (e.g., 3600 seconds = 1 hour) reduces nameserver load but delays propagation of changes. During planned migrations, lower the TTL before making changes, then increase it again after migration completes. Default TTL is usually 3600 seconds.
How do I check my DNS records and verify they're correct?
Use the `dig`, `nslookup`, or `host` command-line tools, or use an online DNS checker (AtomPing has a free DNS Lookup tool at atomping.com/tools/dns-lookup). Look for A records pointing to your IP, MX records with correct priorities, TXT records with SPF/DKIM/DMARC, and NS records pointing to your nameservers. Common mistakes: missing MX records (mail bounces), wrong TTL (changes don't propagate), CNAME at apex (domain breaks), forgot a trailing dot in CNAME target (resolution fails).