September 09, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
You point a domain at a server, wire up email, and prove ownership to Google or a payment gateway. Every step depends on DNS records explained clearly: A, AAAA, CNAME, MX, and TXT are the five types you touch most often on real projects. I've configured these on domain registration and hosting setups in Nepal, on Laravel apps behind Apache, and on legal-tech portals that must stay reachable after migration. This guide walks through what each record does, when to use it, and the mistakes that still break production sites in 2026.
Quick answer: DNS records explained simply: A maps a hostname to IPv4, AAAA to IPv6, CNAME aliases one name to another, MX routes email to mail servers, and TXT stores verification strings and policies like SPF and DKIM.
How does DNS resolution work before you edit any records?
DNS is a distributed phone book for the internet. Your browser does not connect to your server by domain name alone. It asks a resolver to translate that name into an IP address or other data.
The lookup chain usually runs like this. Your device asks a recursive resolver—often your ISP or 1.1.1.1. That resolver walks the hierarchy from the root, through the TLD (.com, .np), to your domain's authoritative nameservers. Those nameservers return the record you configured.
Each answer carries a TTL in seconds. TTL controls how long resolvers cache the result. Low TTL helps during migrations. High TTL reduces load and speeds up repeat visits. A common mistake is editing records without checking TTL first. You wait an hour when the old value was cached for 24 hours.
Authoritative DNS lives at your registrar, hosting panel, or a provider like Cloudflare. The Cloudflare Learning Center DNS overview remains a solid reference for resolver behaviour and caching. On client projects I treat DNS as infrastructure, not a one-time setup task. It belongs in runbooks next to SSL renewal and backup checks.
What is an A record and when should you use it?
An A record maps a hostname to an IPv4 address. It is the default way to point example.com or www.example.com at your web server.
Typical A record layout
Most panels expose the same fields. Name is the host label. Value is the IPv4 address. TTL is cache duration in seconds.
Name: @
Type: A
Value: 203.0.113.10
TTL: 3600
Name: www
Type: A
Value: 203.0.113.10
TTL: 3600The at-sign (@) represents the apex domain—the bare name without a subdomain prefix. Some panels use a blank name instead. Both mean the same thing.
For a Laravel app on Ubuntu with Apache and PHP-FPM, the A record aims traffic at the server that terminates TLS and serves public/index.php. I've seen sites stay down after a server move because only www was updated and the apex still pointed at the old IP. Always check both apex and www with dig before you call migration done.
dig +short example.com A
dig +short www.example.com APair DNS changes with your deployment workflow. Several sister sites I maintain use Deployer 7 and GitLab CI on shared EC2. The symlink swap is instant. DNS propagation is not. Plan the IP change during low traffic and drop TTL to 300 seconds a day ahead if your provider allows it.
What is the difference between A, AAAA, and CNAME records?
These three record types answer "where does this hostname go?" but they behave differently. Choosing wrong causes subtle outages or violates DNS rules.
A record — IPv4 target
Use A when you have a stable IPv4 address and need the apex or any host to resolve directly. Load balancers, VPS instances, and shared hosting IPs all use A records. You can hold multiple A records on one name for round-robin, though health-checked routing usually lives at the CDN or load balancer layer instead.
AAAA record — IPv6 target
AAAA is the IPv6 equivalent of A. Dual-stack hosts often publish both. If you add AAAA, ensure your server actually listens on IPv6. A broken AAAA record can cause long timeouts on networks that prefer v6. Test with:
dig +short example.com AAAA
curl -6 -I https://example.comCNAME record — alias to another name
CNAME says "this hostname is really that other hostname." Resolvers follow the chain until they hit A or AAAA. A classic pattern:
Name: www
Type: CNAME
Value: example.com
TTL: 3600Now you maintain one A record on the apex and www follows automatically. Do not put CNAME on the apex (@). RFC 1912 disallows CNAME coexisting with other record types at the same name, and apex zones need NS and SOA records. Many DNS providers offer ALIAS or ANAME pseudo-records for apex-to-CDN mapping. That solves the CNAME-at-root problem without violating the spec.
| Record | Points to | Apex OK? | Common use |
|---|---|---|---|
| A | IPv4 address | Yes | Website, API, bare domain |
| AAAA | IPv6 address | Yes | Dual-stack hosting |
| CNAME | Another hostname | No | www alias, SaaS subdomains |
| MX | Mail server host | Yes | Inbound email routing |
| TXT | Text string | Yes | SPF, DKIM, domain verify |
SaaS tools often ask for CNAME on subdomains. Stripe, Shopify, and helpdesk widgets use this pattern. Point support.example.com at their hostname and they handle TLS on their edge. For deeper routing across providers, see our notes on cross-cloud DNS and traffic routing.
How do MX and TXT records control email and domain verification?
MX records tell the world which servers accept mail for your domain. TXT records hold arbitrary text. That sounds vague until you use them for SPF, DKIM, DMARC, and one-click domain verification.
MX records — mail exchanger priority
Each MX row has a priority number and a hostname. Lower numbers are tried first. Mail servers look up A or AAAA for that hostname separately.
Name: @
Type: MX
Priority: 10
Value: mail.example.com
TTL: 3600
Name: @
Type: MX
Priority: 20
Value: mailbackup.example.com
TTL: 3600Google Workspace, Zoho, and Microsoft 365 publish exact MX values in their setup docs. Copy them exactly. A typo in the mail host means silent mail loss. After changes, verify with:
dig +short example.com MX
dig +short mail.example.com AOn a legal-tech portal I built, client intake forms send mail through the app. The app only works if MX points at a reachable SMTP path and SPF authorises the sending IP. Email is half DNS configuration and half application config.
TXT records — verification and mail policy
TXT strings are free-form but follow conventions. Domain verification for Search Console or a payment gateway often looks like:
Name: @
Type: TXT
Value: "google-site-verification=abc123xyz"
TTL: 3600SPF lists which hosts may send mail for your domain:
Name: @
Type: TXT
Value: "v=spf1 include:_spf.google.com ~all"
TTL: 3600DKIM publishes a public key on a selector subdomain:
Name: google._domainkey
Type: TXT
Value: "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
TTL: 3600Only one SPF TXT record should exist per domain. Merge includes into a single string. Multiple SPF records break validation. DMARC sits in another TXT at _dmarc.example.com and tells receivers how to handle SPF or DKIM failures.
The RFC 1035 DNS specification defines core record types. For operational mail policy, refer to your provider's current documentation alongside those standards.
What are the most common DNS record mistakes in production?
Most DNS outages are configuration errors, not resolver bugs. These patterns show up repeatedly on migrations, launches, and handoffs from non-technical staff.
- CNAME at apex. Use A or a provider ALIAS instead. Apex CNAME breaks mail and breaks spec.
- Conflicting www strategies. Pick A on both apex and www, or apex A plus www CNAME. Do not mix stale IPs.
- Forgotten TTL. Lower TTL before changes. Raise it after stability returns.
- MX host without A record. MX must point to a resolvable name. Verify the mail host resolves.
- Duplicate SPF TXT rows. Merge into one. Test with an external SPF lookup tool.
- Trailing dots. Some panels want
mail.example.com.with a trailing dot. Others add it automatically. Know your UI.
When you proxy through a CDN, A records often point at anycast IPs owned by the CDN. Origin IP must not leak in DNS if you rely on their WAF. Our guide on Cloudflare DNS cache bypass for API endpoints covers exceptions for webhooks and health checks that need direct origin access.
DNS also intersects technical SEO. Wrong A records send crawlers to a parked page. Missing verification TXT blocks Search Console ownership. Conflicting www and apex URLs create duplicate indexing unless redirects and canonicals are correct. Treat DNS as part of your crawlability stack alongside robots.txt.
For server-side checks after DNS updates, I use command-line tools daily. You can sanity-test record strings with the regex tester when parsing automation output. JSON API responses from DNS providers fit through the JSON formatter during scripting work.
Website moves between hosts need coordinated A, MX, and TXT updates. Our website migration service includes DNS cutover planning because application code is only half the job. The same applies when relaunching a portfolio site like Notary Nepal or Court Marriage In Nepal onto new infrastructure.
Linux admins often debug DNS at the OS resolver layer. Stubborn caching on the server itself can hide fresh records during testing. Flush local cache or query authoritative NS directly:
dig @ns1.registrar.com example.com A +traceThat bypasses intermediate caches and shows the live zone file answer. Pair this with Linux system administration when PHP-FPM, Apache, and DNS must align on the same box.
Key Takeaways
- A and AAAA point hostnames at IPv4 and IPv6; use both only when dual-stack is real and tested.
- CNAME aliases subdomains to another name; never use CNAME on the zone apex.
- MX records need valid priorities and resolvable mail hostnames with matching A or AAAA.
- TXT carries SPF, DKIM, DMARC, and verification tokens—keep one SPF record per domain.
- Lower TTL before migrations; verify with
digfrom multiple resolvers after every change. - DNS, TLS, email, and SEO fail together—document records before you need an emergency rollback.
People Also Ask
Can I use a CNAME for my root domain?
No. Standard DNS forbids CNAME at the zone apex because NS and SOA records must live there. Use A or AAAA on the apex, or use ALIAS or ANAME if your DNS host supports flattening to an IP at query time.
How long do DNS changes take to propagate?
Propagation depends on the previous TTL, not a fixed global delay. If old records cached for 86400 seconds, some resolvers may serve stale data up to 24 hours. After lowering TTL and updating records, most clients pick up changes within minutes to a few hours.
What is the difference between MX priority 10 and 20?
Lower numbers rank higher. Senders try priority 10 first. Priority 20 is a backup if the primary mail exchanger is unreachable. Equal priorities load-balance between peers.
Do I need TXT records if I only run a website?
You still need TXT if you verify the domain with Google, issue certain certificates, or send mail from the domain. Even brochure sites often send contact-form email. SPF and DKIM TXT records protect deliverability.
Ship DNS changes with confidence
DNS records explained: A, AAAA, CNAME, MX, and TXT are the control plane for how the world reaches your site and mail. Get them right once, document them in a runbook, and every deploy after that is less stressful. If you are moving a Laravel app, WordPress shop, or legal portal and want DNS cutover handled alongside hosting and SSL, contact us for a migration review or browse web development services and the wider services overview. Solid DNS is boring infrastructure—and boring is exactly what production needs.
Frequently Asked Questions
A maps a hostname to IPv4, AAAA to IPv6, CNAME aliases one name to another, MX routes email to mail servers, and TXT stores verification strings and policies like SPF and DKIM.
DNS is a distributed phone book. Your browser asks a recursive resolver, which walks from root through the TLD to your domain's authoritative nameservers. Those return the record you configured, along with a TTL that controls caching duration. Low TTL helps during migrations; high TTL reduces load and speeds repeat lookups. A common mistake is editing records without checking TTL first, then waiting an hour when the old value was cached for 24 hours.
An A record maps a hostname to an IPv4 address. Use it to point example.com or www.example.com at your web server. The @ symbol represents the apex domain. On a Laravel app behind Apache and PHP-FPM, the A record aims traffic at the server terminating TLS. I've seen sites stay down after a server move because only www was updated and the apex still pointed at the old IP. Always check both apex and www with dig before calling migration done.
All three answer where a hostname goes, but they behave differently. A points directly at an IPv4 address for the apex or any subdomain. AAAA is the IPv6 equivalent; only publish it if your server actually listens on IPv6, or broken AAAA can cause long timeouts on networks that prefer v6. CNAME aliases one hostname to another, and resolvers follow the chain until they hit A or AAAA. CNAME works well on www but not on the zone apex.
No. Standard DNS forbids CNAME at the zone apex because NS and SOA records must live there. Use A, AAAA, or a provider ALIAS or ANAME record instead.
Propagation depends on the previous TTL, not a fixed global delay. Stale cache can last up to 24 hours if TTL was 86400; most updates appear within minutes to a few hours.
Lower numbers rank higher. Senders try priority 10 first. Priority 20 is a backup if the primary mail exchanger is unreachable. Equal priorities load-balance between peers.
MX records tell the world which servers accept mail for your domain. Each row has a priority number and a hostname; lower numbers are tried first. Mail servers look up A or AAAA for that hostname separately. Google Workspace, Zoho, and Microsoft 365 publish exact MX values you must copy exactly—a typo means silent mail loss. On a legal-tech portal, client intake forms only deliver if MX points at a reachable SMTP path and SPF authorises the sending IP.
TXT records hold arbitrary text used for domain verification, SPF mail policy, DKIM public keys, and DMARC rules. Search Console or payment gateway verification often uses strings like google-site-verification tokens. SPF lists which hosts may send mail for your domain. DKIM publishes a public key on a selector subdomain such as google._domainkey. DMARC sits at _dmarc.example.com and tells receivers how to handle SPF or DKIM failures.
You still need TXT if you verify the domain with Google, issue certain certificates, or send mail from the domain. Even brochure sites often send contact-form email, and SPF and DKIM TXT records protect deliverability. Missing verification TXT blocks Search Console ownership, which affects technical SEO monitoring. Treat DNS as part of your crawlability stack alongside robots.txt and canonical URLs.
CNAME at apex breaks spec and mail—use A or ALIAS instead. Conflicting www strategies leave one hostname on a stale IP. Forgotten TTL causes long waits during cutover. MX hosts without matching A records fail silently. Duplicate SPF TXT rows break validation; merge into one record. Trailing dot handling varies by panel, so know your UI. When proxying through a CDN, origin IP must not leak in DNS if you rely on their WAF.
TTL controls how long resolvers cache DNS answers. Before an IP change, drop TTL to 300 seconds if your provider allows it, ideally a day ahead. On sites using Deployer 7 and GitLab CI, the symlink swap is instant but DNS propagation is not. Plan the cutover during low traffic, verify with dig from multiple resolvers after every change, then raise TTL once stability returns to reduce load on authoritative nameservers.
No. Only one SPF TXT record should exist per domain. Multiple SPF records break validation. Merge all include statements into a single string such as v=spf1 include:_spf.google.com ~all. This is one of the most common handoff errors I've seen when non-technical staff add mail services without checking existing TXT rows. Test with an external SPF lookup tool after any change.
MX rows store a mail server hostname, not an IP address. Sending servers resolve that name through separate A or AAAA lookups. If mail.example.com has no A record, inbound mail fails even when the MX entry looks correct. After any MX change, verify both dig +short example.com MX and dig +short mail.example.com A. This pairing catches typos and orphaned mail hosts before silent mail loss hits production.
Use dig from your workstation: dig +short example.com A for the apex, plus www and AAAA if used. Check MX, then resolve the mail host separately. To bypass ISP or local cache during testing, query authoritative nameservers directly with dig @ns1.registrar.com example.com A +trace. Stubborn OS-level caching on Linux servers can hide fresh records, so flush local cache or test from multiple resolvers before you call a migration or launch complete.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
