The Ultimate Guide to DNS Records: A, CNAME, MX, and TXT

If you’ve ever launched a website, set up business email, or connected a SaaS tool to your domain, you’ve dealt with DNS—whether you knew it or not. DNS is the behind-the-scenes directory that tells the internet where to send visitors and messages. Get it right, and things feel instant and reliable. Get it wrong, and you’ll spend your afternoon chasing mysterious errors and missing emails.

This guide breaks down the four DNS record types you’ll actually use most—A, CNAME, MX, and TXT—what they do, when to use them, and the 2024–2026 trends that are changing how teams manage DNS. We’ll keep it practical, with examples and the kinds of gotchas people only learn the hard way.

Two fast comparisons to set the stage:
– DNS is the internet’s maps app: it translates place names (domains) into exact coordinates (IP addresses).
– MX records act like a mailroom routing sheet: they tell other mail servers which door to knock on first, and what to try next.

Why DNS still matters (even more) in 2026

– Email deliverability is stricter than ever. Google and Yahoo now require proper authentication (SPF, DKIM, and DMARC) for bulk and many business senders, or your messages can be throttled or rejected. That’s all DNS.
– Websites rarely live at one static IP. CDNs, load balancers, and serverless platforms rely on CNAMEs, ALIAS/ANAME flattening, and smart health checks via your DNS provider.
– Security expectations have grown. DNSSEC, registry locks, and monitoring for dangling CNAMEs (to prevent subdomain takeover) are increasingly standard in audits and enterprise procurement.

Let’s start with a quick refresher, then dive into each record type.

How DNS works (super short)

– You own a domain through a registrar (e.g., Namecheap, Google Domains’ successor, Cloudflare). But where you edit records is your authoritative DNS provider (could be your registrar, Cloudflare, Route 53, NS1, Akamai, etc.).
– A user’s device asks a recursive resolver (often their ISP, a corporate resolver, or a public resolver like Google 8.8.8.8 or Cloudflare 1.1.1.1) for your domain. That resolver caches results based on TTLs (time-to-live).
– Authoritative name servers answer with the records you configured. Caches speed things up but also mean changes take time to propagate.

Common myth: changing a TTL to 60 seconds doesn’t “pull back” what’s already cached elsewhere. Lower TTLs help future queries, not past ones.

A records: your domain to an IP address

An A record maps a hostname to an IPv4 address (e.g., 203.0.113.10). Its IPv6 counterpart is AAAA (e.g., 2001:db8::1). Modern stacks often publish both.

When to use
– Point a hostname directly at a server, load balancer, or service with a stable public IP.
– Use multiple A records for simple round-robin distribution or failover when paired with health checks from advanced DNS providers.

Examples
– www.example.com A 203.0.113.10
– www.example.com AAAA 2001:db8::10
– api.example.com A 198.51.100.88
– example.com A 203.0.113.20 (apex/root domain)

Best practices
– Prefer A/AAAA for the apex (example.com). You can’t put a plain CNAME at the apex per the DNS spec. If your provider supports ALIAS/ANAME/flattening, you can “CNAME-like” the apex to a target; the provider will resolve and publish an A/AAAA on your behalf.
– Publish AAAA where possible. IPv6 traffic share continues to rise globally, and many CDNs and clouds perform better when both stacks are available.
– Keep TTL pragmatic. For static IPs, 1–4 hours is fine. During migrations, temporarily drop TTL to 300 seconds a day ahead.

Common pitfalls
– Hardcoding A records to a vendor that expects you to use a CNAME target (e.g., a CDN). You’ll miss vendor-side routing and failover features if you bypass their hostnames.
– Forgetting to update both A and AAAA during a migration.

CNAME records: alias to another name

A CNAME tells resolvers “this name is an alias of that other hostname; go resolve that instead.” It never points to an IP, only to another name.

When to use
– Point a subdomain to a CDN, SaaS, or load-balanced hostname a vendor controls (e.g., www to your CDN-provided URL).
– Keep flexibility when the destination host’s IPs change frequently.

Examples
– www.example.com CNAME example.net.cdnprovider.com.
– files.example.com CNAME mybucket.s3-website-us-east-1.amazonaws.com.
– app.example.com CNAME customer123.saasvendor.com.

Rules and constraints
– No CNAME at the apex (example.com) on pure DNS per spec. Use provider features like ALIAS/ANAME/flattening, or the vendor’s “apex-friendly” solution.
– A name with a CNAME cannot have any other records (no A, MX, TXT, etc., at that exact label).
– CNAMEs chain, but avoid long chains for latency and reliability.

Modern realities
– Flattening/ALIAS is common. Route 53 Alias, Cloudflare flattening, NS1 ALIAS, and others resolve a target and publish A/AAAA at the apex. This is how you put a CDN or managed LB at your root domain cleanly.
– Subdomain takeovers happen when you delete a vendor resource but leave a CNAME pointing to it. Attackers can re-register the vendor endpoint and control your subdomain. Audit CNAMEs during deprovisioning.

MX records: where your mail should go

MX records tell other mail servers where to deliver mail for your domain. Each MX has a priority (lower is tried first), and you usually configure multiple for redundancy.

Examples
– example.com MX 1 aspmx.l.google.com.
– example.com MX 5 alt1.aspmx.l.google.com.
– example.com MX 10 alt2.aspmx.l.google.com.

Key points
– Don’t point MX to an IP—MX must point to a hostname that has A/AAAA records.
– Use at least two MX records per provider. If you use two providers, understand how each expects you to configure primary/secondary so you don’t create delivery loops.
– You don’t send email via MX. MX is only for receiving mail. Sending flows depend on your outbound mail systems and their authentication (SPF, DKIM, DMARC).

2024–2026 deliverability reality check
– Gmail and Yahoo tightened bulk-sender rules in 2024 and have increasingly applied them to business senders. Expect:
– SPF and DKIM must pass for your domain or subdomain.
– DMARC must be published with at least a monitoring policy (p=none), and enforcement (p=quarantine or p=reject) is encouraged or required for higher volumes.
– Alignment matters: the domain in From: should align with SPF/DKIM-authenticated domains.
– One-click unsubscribe and low spam rates are also part of the equation, but that’s beyond DNS.
– MTA-STS and TLS-RPT are increasingly used by security-conscious orgs:
– _mta-sts.example.com TXT v=STSv1; id=2024020101
– A policy at https://mta-sts.example.com/.well-known/mta-sts.txt enforces TLS for inbound mail.
– _smtp._tls.example.com TXT v=TLSRPTv1; rua=mailto:tlsrpt@example.com

TXT records: flexible text for policies and proof

TXT is the Swiss Army knife of DNS. It stores arbitrary text—used for email authentication (SPF, DKIM, DMARC), domain verification, and service metadata.

Common uses
– SPF: Defines which servers can send mail for your domain.
– example.com TXT v=spf1 include:_spf.google.com include:sendgrid.net -all
– DKIM: Publishes your email provider’s public key to validate message signatures.
– selector1._domainkey.example.com TXT v=DKIM1; k=rsa; p=MIIBIjANBgkqh…
– DMARC: Tells receivers how to handle failing emails and where to send reports.
– _dmarc.example.com TXT v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100; adkim=s; aspf=s
– Domain verification for SaaS: e.g., google-site-verification=, ms=, atlassian-domain-verification=, facebook-domain-verification=, etc.
– BIMI (brand logos in inboxes):
– default._bimi.example.com TXT v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/authority.pem

Best practices and limits
– SPF’s 10-DNS-lookup rule: Each include:, a, mx, ptr, exists, redirect in SPF may cause DNS lookups. Exceed 10 and SPF will fail “permerror” with many receivers. Use vendor-provided “flattened” SPF, or consolidate providers.
– One SPF record per domain. If you add a new provider, update the existing record—don’t create a second SPF record at the same label.
– TXT length: Single strings are limited to 255 characters; long DKIM keys are split into quoted chunks, which clients reassemble.
– DMARC rollout: Start with p=none; collect reports; move to p=quarantine, then p=reject as alignment and subdomains are cleaned up.

Putting it together: real-world scenarios

1) Launch a site on a CDN at your apex and www

Goal: example.com and www.example.com served by your CDN vendor.

– At DNS provider:
– example.com: Use ALIAS/ANAME/flattening to target your CDN hostname (e.g., example.net.cdnvendor.com). If flattening isn’t supported, point the apex A/AAAA to your load balancer’s anycast IPs if vendor provides them.
– www: CNAME to example.net.cdnvendor.com.
– Set TTL to 300–900 seconds for launch day; raise to 1 hour after stabilization.
– Ensure HTTPS: Upload certs or use the vendor’s managed certificates; confirm the apex is covered.
– Redirect: If your brand standard is apex, set CDN/page rules to redirect www → apex (or vice versa).

Watch-outs
– Don’t place a raw CNAME at the apex unless your provider explicitly supports apex CNAME via flattening.
– Confirm both A and AAAA are being served by the provider for better global performance.

2) Move email from Provider A to Provider B

Goal: Clean cutover without lost mail.

– Lower TTL on MX and relevant TXT (SPF, DMARC) to 300 seconds at least 24 hours ahead.
– Add new MX records for Provider B with lower preference values (e.g., 1, 5). Keep old provider’s MX at higher values temporarily (e.g., 20, 30) for fallback during transition if both providers support it.
– Update SPF to include Provider B and, if possible, temporarily include both providers. Ensure you remain under the SPF 10-lookup cap.
– Publish DKIM for Provider B (new selector) and keep Provider A’s selector active during the overlap.
– DMARC stays the same domainwide; alignment must continue to pass via DKIM or SPF.
– Switch sending in your apps to Provider B. Monitor delivery and DMARC reports for 24–48 hours.
– Remove old MX records and old SPF/DKIM entries once stable. Restore TTLs to 1–4 hours.

3) Verify your domain for a SaaS and send via a marketing platform

– Add the SaaS-provided TXT verification token at the root (or specified subdomain).
– For marketing sends, add the provider’s SPF include and set up DKIM at the selector they give (e.g., k1._domainkey.example.com).
– Ensure DMARC is at least p=none while you validate alignment and engagement; move to p=quarantine/reject once your marketing and transactional flows are authenticated and aligned.

Operational tips that pay off

– TTL strategy: Keep critical records (A/AAAA for apex, www; MX; SPF/DKIM/DMARC) at 1–4 hours normally. Before a planned change, lower to 5–15 minutes a day in advance, make the change, verify, then raise back. Avoid leaving TTLs extremely low—they increase query load and cost.
– Health checks and failover: Use a DNS provider with health checks and traffic steering to remove down endpoints from A/AAAA pools automatically.
– Propagation checks: Use dig or nslookup against multiple public resolvers and directly against your authoritative nameservers.
– dig +short www.example.com @1.1.1.1
– dig +trace example.com
– nslookup -type=txt _dmarc.example.com 8.8.8.8
– Verify email auth: Use Gmail Postmaster Tools, Microsoft SNDS, and DMARC aggregate reports (RUA) to track authentication at scale. For one-off tests, use tools like Gmail’s original message view (Show original) or third-party testers that decode SPF/DKIM/DMARC.
– Change management: Version your DNS as code where possible (Terraform, Pulumi). Peer-review changes. Set up alerts for unexpected changes to NS records or critical TXT records.
– Audit regularly: Look for dangling CNAMEs, wildcard records that are too broad, duplicate or conflicting TXT (especially SPF), and stray MX entries.

Security and resilience extras

– DNSSEC: Signs your zone to prevent forged DNS answers. Many enterprises now expect DNSSEC for higher-assurance domains. Make sure your registrar supports DS records and your DNS provider manages key rollover.
– Registry and registrar locks: Prevent accidental or malicious domain transfers or NS changes. Critical for high-value domains.
– Anycast authoritative DNS: Choose providers with global anycast networks for faster, more resilient answers. Multi-provider DNS can further reduce risk but adds complexity.
– Split-horizon DNS: Serve different answers internally and externally (e.g., private IPs for corp users). Keep documentation tight; this can complicate troubleshooting.
– Subdomain takeover prevention: Periodically confirm that every CNAME target still exists with the vendor. Remove or update stale references immediately.

Trends shaping DNS choices right now

– Stricter email authentication is the norm: DMARC enforcement is steadily rising, not just for marketing but for transactional and corporate mail. BIMI adoption continues for brands seeking visual trust in inboxes (but it requires strong DMARC).
– Apex CNAME workarounds are standard: Flattening/ALIAS has gone mainstream, which simplifies routing apex domains to CDNs, serverless platforms, and managed LBs.
– IPv6 growth: Many networks prefer IPv6 where available. Publishing AAAA alongside A gives performance and reach benefits in more regions.
– Privacy-respecting resolvers (DoH/DoT): DNS over HTTPS/TLS is now common on consumer devices and browsers, which can affect how quickly you perceive “propagation” changes from your own machine versus the wider internet.
– Multi-region and multi-CDN architectures: Teams increasingly use DNS-based traffic steering for latency improvements and resilience. Your DNS provider’s feature set (geolocation, health checks, weighted routing) matters more than in the past.

Cheat sheet: which record when?

– Use A/AAAA when you have stable IPs or your provider expects direct address targets.
– Use CNAME for subdomains pointing to vendor-managed hostnames (CDNs, SaaS, storage sites). Don’t use CNAME at the apex unless your DNS supports flattening/ALIAS.
– Use MX to route inbound mail. Never point MX to IPs; use hostnames with valid A/AAAA.
– Use TXT for SPF, DKIM, DMARC, domain verification, and email security extras (MTA-STS, TLS-RPT, BIMI).

Common pitfalls to avoid

– Multiple SPF records at the same label. Merge into one.
– CNAME plus other records at the same name. Not allowed.
– Exceeding SPF’s 10-lookup limit. Consolidate or flatten includes.
– Assuming TTL changes are instant. They affect future lookups, not cached ones.
– Forgetting to remove decommissioned vendor targets, leaving a subdomain takeover risk.
– Publishing DMARC but forgetting alignment, leading to authentication failures during enforcement.

Closing thoughts

DNS doesn’t have to be mystical. With a small set of records—A, CNAME, MX, and TXT—you can run a modern, resilient web and email stack that aligns with today’s deliverability, performance, and security expectations. If you haven’t reviewed your zone lately, this week is a good time to:

– Confirm your apex and www point to the right place (and consider flattening if you rely on a CDN).
– Publish AAAA alongside A where possible.
– Audit email: working MX; single, correct SPF; active DKIM keys; DMARC with reporting; and a plan to move to enforcement.
– Remove dangling CNAMEs and old verification tokens.
– Raise or lower TTLs intentionally based on change frequency.

Do that, and the internet “maps app” will always get people—and their messages—to the right place, fast.