DNS Records Explained: Every Record Type with Real-World Examples

What DNS Records Actually Are (And Why They Are Not Just Pointing a Domain)

DNS records do not point anything. They answer questions that resolvers ask.

This is not a semantic distinction. When a browser needs to load your website, it does not follow a pointer from your domain name to your server. It sends a query to a recursive resolver — typically your ISP's or a public resolver like 8.8.8.8 — and the resolver works through a chain of lookups to find the authoritative answer. That chain is: recursive resolver asks the root nameserver which TLD nameserver handles .com domains; asks the TLD nameserver which nameserver is authoritative for your domain; asks your authoritative nameserver what the A record for your domain is; and returns the IP address to the browser. The browser never interacts with any nameserver except through its resolver. The resolver does all the work.

Understanding this chain explains three things that confuse people constantly. First: why propagation is not instant. The recursive resolver cached your old A record for however long the TTL said it should. It is not asking again until that timer expires. Second: why some DNS changes appear to take effect immediately while others seem frozen. The resolver cached different records at different TTL values. Third: why your monitoring tool might show the new record while your ISP shows the old one. The two are querying through different resolvers with different cache states.

The more accurate mental model for DNS records is a distributed database, not a routing table. Your authoritative nameserver holds records. Resolvers cache copies of those records for the duration the TTL specifies. When you change a record, you update the authoritative copy. Resolvers update their cached copy when their TTL expires and they re-query. The "propagation" window is the time it takes for all cached copies worldwide to expire and be replaced with the new authoritative value.

DNS is also the operational layer that controls far more than where your website points. Your email authentication lives in DNS. Your SSL certificate authority restrictions live in DNS. Your subdomain security — or vulnerability — lives in DNS. Every section of this page covers a different domain where DNS records have real operational, financial, or security consequences.

Every DNS Record Type Explained: A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, CAA, and More

Most DNS tutorials explain A records and CNAME records, then stop. That covers maybe 40% of what is actually in your DNS zone. The other records — CAA, SRV, SOA, PTR, ALIAS — control things that break quietly when they are wrong and that nobody investigates until something fails in production.

This is the reference section. Every record type, what it controls, a real example value, and the mistake that causes problems in practice.

<!-- DNS Record Types Reference — Source: thatmy.com/dns-records -->
<table>
  <thead>
    <tr>
      <th>Record Type</th><th>What It Does</th><th>Controls</th><th>Common Mistake</th>
    </tr>
  </thead>
  <tbody>
    <tr><td>A</td><td>Maps hostname to IPv4</td><td>Where HTTP traffic goes</td><td>Forgetting to update after migration</td></tr>
    <tr><td>CNAME</td><td>Maps hostname to hostname</td><td>CDN aliases, www redirect</td><td>Using CNAME at zone apex — breaks everything</td></tr>
    <tr><td>MX</td><td>Specifies mail server</td><td>Inbound email delivery</td><td>MX pointing to a CNAME instead of A record</td></tr>
    <tr><td>TXT</td><td>Free-form text</td><td>SPF, DKIM, DMARC, ownership verification</td><td>Multiple SPF records breaking validation</td></tr>
    <tr><td>CAA</td><td>CA authorization</td><td>Which CAs can issue SSL certs</td><td>Not setting it — leaves SSL issuance open</td></tr>
  </tbody>
</table>
<p>Full reference: <a href="https://thatmy.com/dns-records">thatmy.com/dns-records</a></p>

Two of these records deserve more depth than a table row can provide. CNAME at the zone apex is the most catastrophic DNS mistake I have seen site owners make, and it requires a dedicated explanation. NS records during a provider migration have a failure mode that takes domains completely offline for hours. Both are covered next.

A Record vs CNAME vs ALIAS vs ANAME: The Zone Apex Problem Nobody Explains

Every DNS tutorial explains CNAME as "an alias that points a hostname to another hostname." What almost none of them explain is why this breaks completely at the root of your domain — and why the fix requires a record type that is not part of any RFC standard.

Why the Zone Apex Is Different

The zone apex is your root domain: domain.com with no subdomain prefix. It is special because it must contain SOA and NS records. These records define the zone itself — who owns it, which servers answer for it, and its metadata. A CNAME record at the same name would, by DNS specification (RFC 1034 Section 3.6.2), replace all other records at that name. Including the SOA and NS records. Which would destroy the zone.

This is why you can set a CNAME on www.domain.com without any problem. There are no SOA or NS records at www.domain.com — just your record. But at domain.com itself, a CNAME is a specification violation, and DNS providers that enforce RFC compliance will reject it or silently ignore the CNAME while keeping the NS and SOA, resulting in a non-functioning alias.

The ALIAS and ANAME Solution

ALIAS (used by DNSimple, NS1, and others) and ANAME (used by some other providers) are non-standard record types that solve the zone apex CNAME problem. Cloudflare implements this as "CNAME flattening" — you enter a CNAME, but Cloudflare resolves it server-side and returns A record values to clients. The effect is CNAME-like behavior (follow a hostname to its IP) without the RFC violation.

The critical caveat: not all DNS providers support ALIAS or ANAME. If you point your domain at a CDN or platform that gives you a hostname rather than an IP, and your DNS provider does not support ALIAS/ANAME, you have two options: add an A record pointing to the IP address the hostname currently resolves to (which breaks if the CDN changes its IP), or move DNS to a provider that supports the record type your setup requires.

The zone apex problem is the number one source of "my www works but my root domain does not" support tickets. Understanding why it happens is the first step to fixing it without randomly trying different records until something works.

SPF, DKIM, and DMARC: The DNS Records That Control Whether Your Email Reaches the Inbox

If your business emails are landing in spam, the answer is almost certainly in your DNS. SPF, DKIM, and DMARC are all TXT records that together form an email authentication system. Most domains have one of the three configured partially. Few have all three configured correctly. Almost none have verified them after a hosting migration that changed mail server infrastructure.

SPF: Which Servers Are Authorized to Send Your Email

SPF (Sender Policy Framework) is a TXT record that lists the mail servers authorized to send email claiming to be from your domain. When a receiving mail server gets an email from info@yourdomain.com, it checks your domain's SPF record to verify that the sending server is on the authorized list. If it is not, SPF fails and the email is treated with suspicion.

The most common SPF mistake is having multiple SPF records on the same domain. Only one TXT record starting with v=spf1 is permitted per domain. If you have two, SPF validation fails silently — not with an error, just with "SPF is broken on this domain." I have seen this happen after a hosting migration where someone added the new provider's SPF include without removing or merging the old one. The result was weeks of email landing in spam before anyone checked DNS.

A valid SPF record for a domain using Google Workspace: v=spf1 include:_spf.google.com ~all. If you also send from Mailchimp: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all. One record. All includes merged. The ~all at the end means "treat anything else as suspicious but do not outright reject." A hard -all reject approach breaks legitimate email more often than it stops spam.

DKIM: Cryptographic Proof That the Message Was Not Tampered With

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound emails. The signature is verified against a public key you publish as a TXT record in DNS. When the receiving server sees an email claiming to be from your domain, it checks the DKIM signature against your public key. If the signature matches, the message was genuinely sent by an authorized server and has not been modified in transit.

Most email providers generate DKIM keys automatically, but they require you to manually add the TXT record to your DNS. Google Workspace shows you the record in the Admin Console under Apps > Gmail > Authenticate email. The record lives at a subdomain like google._domainkey.domain.com and contains a long public key string. Missing this step means your emails have no DKIM signature — they are not rejected, but they score worse with spam filters and fail DMARC alignment checks.

DMARC: What Happens When SPF or DKIM Fails

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a policy record that tells receiving servers what to do when an email fails SPF or DKIM checks. It sits at _dmarc.domain.com as a TXT record and has three policy levels: none (monitor and report, do nothing), quarantine (deliver to spam folder), and reject (do not deliver at all).

The correct progression is none for 2-4 weeks while you monitor reports, then quarantine, then reject. Starting with p=reject before you have verified every legitimate sending source will block real emails. Starting with p=none and never moving forward means you are monitoring but never enforcing — spoofed emails can still reach your recipients indefinitely. The monitoring phase at p=none exists to surface every service sending email on your behalf so you can add them to SPF before tightening the policy.

The fourth email DNS record worth knowing is BIMI — an emerging standard that connects a verified brand logo to authenticated email. For details on setting up email hosting including all of these records, the email hosting guide covers the full configuration sequence by provider.

The 24-48 Hour Propagation Myth: What TTL Actually Controls and How to Use It

The myth: "DNS changes take 24-48 hours to propagate." This appears in every hosting control panel, every support ticket response, and every YouTube tutorial about moving domains. It is not exactly wrong. It is just the wrong model — and the wrong model leads to the wrong preparation.

The truth: DNS changes propagate exactly as fast as your TTL allows. If your A record TTL is 300 seconds and you change the IP, resolvers that honored the TTL will re-query within 5 minutes. If your TTL is 86400 and you change the IP, resolvers can serve the old IP for up to 24 hours. The 24-48 hour figure comes from the era when 86400 was the default TTL across the industry. Most modern DNS providers now default to 3600 (one hour). But the myth survived the TTL change.

The ISP Resolver Problem (This Is the Legitimate Source of Real Delays)

Some ISP recursive resolvers ignore TTL values and cache records for longer than you instructed. This is a real phenomenon and the legitimate source of propagation delays that exceed your TTL. An ISP caching a record for 4 hours when your TTL is 300 seconds is unusual but documented. The important nuance: this is outside your control, it affects a small fraction of users, and it is not your host's fault or your fault. When a tech support agent says "wait 24-48 hours," they are either citing the old default TTL era or preparing you for the ISP resolver edge case.

How to Check Propagation Right Now

Three tools tell you the current state of DNS propagation in real time. dnschecker.org queries your domain from 22 global locations simultaneously and shows which resolvers have the new record and which still have the old one. whatsmydns.net does the same with a cleaner interface. From the command line, dig domain.com A queries your local resolver; dig @8.8.8.8 domain.com A queries Google's public resolver; dig @1.1.1.1 domain.com A queries Cloudflare's resolver. If all three return the new IP, propagation is complete for any resolver that respects TTL.

The propagation myth creates a specific failure mode I have seen repeatedly: someone changes an A record, waits "the required 24-48 hours," and accepts slow propagation as normal. With a 300-second TTL, the entire change should complete in under 15 minutes. Accepting 24-48 hours as normal is accepting a failure to prepare — not a DNS limitation.

TTL Strategy for Migrations: The Exact Numbers to Use Before, During, and After

TTL is the only variable you actually control in DNS propagation timing. Using it correctly transforms a painful multi-hour migration window into a 15-minute switch. Using it incorrectly is how sites stay partially unreachable for an entire business day after a routine hosting move.

The Three-Phase TTL Playbook

Phase 1 — 48 to 72 hours before migration: Lower the TTL to 300 seconds on every record you plan to change. This burns off the cached high-TTL values. Any resolver that has your current records cached at 3600 will re-query within an hour. By the time your migration window opens, virtually all resolvers that honor TTL will have fresh caches set at 300. Your actual record values have not changed yet — only the TTL. This phase costs you nothing except planning ahead.

Phase 2 — Migration window: Make the record changes with TTL already at 300. With a 300-second TTL, resolvers will pick up the new values within 5-15 minutes globally. Monitor propagation at dnschecker.org. Confirm the new records are resolving before you decommission the old server. Keep the old server running for at least one full TTL cycle (5 minutes) after confirming propagation is complete.

Phase 3 — 24 to 48 hours after stable migration: Raise TTL back to 3600. High TTL has real operational benefits: it reduces the load on your authoritative nameservers, improves DNS response times for end users (cached responses are served without a live query), and reduces your surface area during a BGP hijack attack (attackers who redirect traffic can only poison caches for the TTL duration).

The NS Record Trap During Provider Migrations

If you are moving DNS providers — not just changing A records at your current provider — there is a specific failure mode that catches people by surprise. When you change NS records at the registrar, you are telling the global DNS system to ask a different server for all records. Any records you then change at the old nameserver have zero effect because nothing is querying the old nameserver anymore.

The correct sequence: change NS records at registrar and wait for full NS propagation (24-48 hours, since NS TTLs are set by the registry, not you). Only after confirming the new nameservers are authoritative should you create and update records at the new provider. Setting up records at the new provider before NS propagation completes is fine — those records sit there ready — but do not decommission old records or servers until NS propagation is confirmed.

For a complete walkthrough of DNS changes as part of a full hosting migration, the hosting migration guide covers this sequence in the context of moving an entire site including files, databases, and email.

Cloudflare Proxied vs DNS-Only: A Decision Framework, Not a Setting

Most Cloudflare documentation describes proxied and DNS-only as toggle options. Most hosting tutorials say "turn on the orange cloud for everything." Both framings lead to the same support ticket: "FTP stopped working after I moved to Cloudflare" or "My email stopped delivering after I set up Cloudflare."

The orange cloud and grey cloud are not cosmetic preferences. They represent completely different network paths with completely different protocol support. Treating them as a global setting rather than a per-record decision is the source of most Cloudflare configuration problems.

What Proxied Actually Does

When a record is proxied, Cloudflare returns one of its own IP addresses in DNS responses instead of your origin server's IP. All HTTP and HTTPS traffic goes to Cloudflare's edge network, passes through the WAF and DDoS protection layers, and is then forwarded to your origin. Your server's real IP is hidden from DNS lookups — which means it is also hidden from attackers trying to bypass Cloudflare by targeting your origin directly.

Proxied records only support HTTP and HTTPS on standard and non-standard ports that Cloudflare explicitly supports. Everything else — FTP, SSH (for SFTP), SMTP, IMAP, POP3, game server protocols, SIP — passes through Cloudflare's network without the WAF layer but still with Cloudflare's IP in the DNS response. This means the traffic still routes through Cloudflare, but the non-HTTP protocol handlers at the origin cannot be reached because Cloudflare does not forward those protocols.

The FTP Trap and the Mail Subdomain Trap

FTP (File Transfer Protocol) cannot be proxied through Cloudflare. FTP uses ports 20 and 21, which Cloudflare does not proxy. If you proxy an FTP subdomain, clients can establish a connection but all file transfers fail. The connection appears to work at the TCP level because Cloudflare responds, but the FTP protocol exchange breaks down immediately. The fix is to set the FTP subdomain to DNS-only.

Mail subdomains (mail., smtp., imap., pop3.) should always be DNS-only. Your mail server needs a direct IP connection for SMTP delivery and client access. Proxying these subdomains routes mail client connections through Cloudflare's HTTP proxy, which adds unexpected SSL termination and breaks the SMTP/IMAP handshakes. The symptoms are mail clients that appear to connect but cannot authenticate, or SMTP relay failures with no obvious error. For more on mail server configuration, the email hosting guide covers subdomain setup in detail.

Cloudflare SSL Modes in the Context of Proxied Records

When records are proxied, Cloudflare handles SSL termination at the edge. The SSL mode controls what happens between Cloudflare and your origin server: Flexible means Cloudflare uses HTTP to your origin (insecure, not recommended), Full means HTTPS but Cloudflare does not validate your origin's certificate, and Full (Strict) means HTTPS with a valid SSL certificate at the origin. If you have a valid SSL certificate on your server — which you should, especially when using SSL certificates from Let's Encrypt — always use Full (Strict). Flexible mode creates a false sense of HTTPS security and is exploitable by MITM attacks between Cloudflare and your origin.

DNS as a Security Attack Surface: Dangling Records, Subdomain Takeover, and CAA

DNS security is not abstract. It is not primarily about sophisticated state-level attacks. The most common DNS security failures happen because of one thing: records that were never cleaned up after a service was cancelled. The attack that exploits them is trivially simple, and it has been used against major brands including Microsoft, Starbucks, and Uber.

Dangling DNS and Subdomain Takeover

When you cancel a Heroku app, a Shopify Plus subdomain, an AWS S3 bucket configured as a website, or any third-party service with a custom subdomain, you delete the service. But if you do not delete the CNAME record pointing to that service, the CNAME still exists in DNS. It points to a hostname that nobody owns anymore.

An attacker can create a new account on that platform, claim the hostname your CNAME points to, and start serving content from your subdomain. Your subdomain. The CNAME was never removed, so DNS still resolves staging.yourdomain.com to the attacker's new Heroku app. The subdomain is real. The SSL certificate is valid (because the attacker can issue one for the hostname they now own). Visitors see a legitimate-looking subdomain of your brand serving phishing content or malware.

The audit is simple: list every CNAME record in your DNS zone. For each one, verify that the destination hostname is still active and under your control. If you deleted an app on Heroku three months ago and forgot to remove the CNAME, it is vulnerable right now. Tools like can-i-take-over-xyz on GitHub maintain a list of services with known subdomain takeover vulnerabilities.

CAA Records: One-Line SSL Security

A CAA (Certification Authority Authorization) record specifies which certificate authorities can issue SSL certificates for your domain. Without one, any CA can issue a certificate for your domain — which means if an attacker redirects your DNS, they can also obtain a valid SSL certificate for your domain from a compliant CA and create a convincing fake site.

Adding a CAA record takes 30 seconds and costs nothing. For Let's Encrypt: domain.com. CAA 0 issue "letsencrypt.org". For ZeroSSL: domain.com. CAA 0 issue "sectigo.com". This single record prevents every other CA from issuing a certificate for your domain, even if an attacker compromises your registrar and redirects DNS. The redirected site cannot get a valid certificate from a CA that is not on your CAA list, and modern browsers will refuse to connect to sites with certificates from unauthorized CAs.

DNSSEC: Cryptographic Zone Signing

DNSSEC adds cryptographic signatures to DNS responses so resolvers can verify the responses have not been tampered with in transit. It protects against cache poisoning attacks where an attacker injects false DNS records into a resolver's cache. The overhead is real but small: DNSSEC adds 1-2 additional DNS lookups for signature validation, which adds a few milliseconds to uncached lookups. For domains handling financial transactions, healthcare data, or anything sensitive, the protection is worth the overhead. Both your DNS provider and your domain registrar need to support DNSSEC — enable it at both layers or not at all.

The Wildcard Record Trap

A wildcard A record at *.domain.com resolves every non-existent subdomain to your server. The intended use case: catch-all routing so you do not need individual records for every subdomain. The unintended consequence: wildcard records mask dangling DNS vulnerabilities. If you have a wildcard record and a dangling CNAME, the wildcard may intercept queries for the subdomain and return your server's IP, hiding the fact that the CNAME is also present and still vulnerable if the wildcard is ever removed. Audit for both independently.

DNS security is connected directly to site availability — a successful DNS hijack takes your site offline more completely than any server failure.

DNS Performance and TTFB: The Hidden Latency Most Developers Ignore

DNS lookup time appears as a separate phase in browser DevTools waterfall charts, between the initial connection and the TCP handshake. Most people dismiss it as negligible. For returning visitors with cached DNS, it is negligible. For first-time visitors on cold connections, it can add 20-120 milliseconds that contribute directly to your TTFB — which is a Core Web Vitals measurement.

How DNS Lookup Time Accumulates

Every unique hostname on your page incurs a DNS lookup for first-time visitors. Your main domain: one lookup. Your CDN subdomain: another lookup. Google Fonts: another. Google Analytics: another. A Facebook pixel: another. A payment widget from Stripe: another. A marketing automation script: another. Most pages have 8 to 15 unique hostnames. On a fast connection with low-latency DNS, this adds up to 50-200ms of serial DNS resolution that happens before any of those resources can begin loading.

DNS Prefetching: Eliminate the Latency

The <link rel="dns-prefetch"> tag tells the browser to resolve third-party hostnames during page parsing, before those resources are requested. Add these to your page head for every external hostname your page uses:

<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//www.googletagmanager.com">
<link rel="dns-prefetch" href="//cdn.yourdomain.com">

For resources you are certain will be needed, rel="preconnect" goes further — it resolves DNS and completes the TCP + TLS handshake, eliminating the full connection latency rather than just the DNS lookup. Use preconnect for critical external resources like font APIs; use dns-prefetch for non-critical ones to avoid unnecessary connection overhead.

DNS Provider Performance Is a Real Performance Variable

Not all DNS providers have the same global query response times. Registrar-bundled DNS (the DNS that comes free with GoDaddy, Namecheap, etc.) typically has response times of 40-200ms globally because the nameserver infrastructure is secondary to the registrar's core business. Purpose-built DNS providers are significantly faster. According to DNSPerf.com global benchmark data, Cloudflare's 1.1.1.1 resolver and Cloudflare's authoritative DNS consistently achieve sub-20ms average query times globally. AWS Route 53 and DNSimple are in the 15-40ms range. Registrar-bundled DNS from major providers averages 80-150ms globally.

For a site with high global traffic, moving authoritative DNS to Cloudflare's free plan or Route 53 ($0.50/month per hosted zone) is one of the cheapest TTFB improvements available. The DNS lookup phase shrinks from 80-150ms to 5-20ms for many global locations. This improvement connects directly to cache efficiency — faster DNS resolution means faster TTFB even on cache misses, and faster first connection on every CDN edge lookup. For a deeper look at how DNS lookup time connects to Core Web Vitals scores, see the Core Web Vitals guide.

DNS Records for a New Hosting Account: In the Right Order

Setting DNS records for a new hosting account is not difficult, but order matters. Some records depend on others being in place. Some create problems when added too early. And the order in which support teams tell you to do this is often wrong — they focus on what gets the site visible, not what prevents email problems from appearing two weeks later.

The Correct Sequence

For registrar-specific instructions, the process is the same across Namecheap, GoDaddy, and Cloudflare — only the interface differs. Namecheap: Advanced DNS tab in domain management. GoDaddy: DNS Management in My Products. Cloudflare: DNS section of the domain dashboard. All three use the same record types and formats. For a broader view of choosing a registrar and managing DNS at the registrar level, see the domain registration guide.

The Seven Most Common DNS Record Mistakes (And What They Break)

Every one of the mistakes below is something I have seen in production setups during migrations, post-launch audits, and support conversations. None of them are exotic. All of them cause real problems that are disproportionately difficult to diagnose because DNS failures are often attributed to the wrong layer.

How to Find These Mistakes for Free

Three tools surface every mistake in this table. MXToolbox SuperTool (mxtoolbox.com/SuperTool) checks your MX records, SPF, DKIM, DMARC, blacklist status, and PTR in a single dashboard. It explicitly flags the multiple-SPF-record problem and the MX-pointing-to-CNAME problem. dnschecker.org shows propagation status from 22 global locations — if you changed something and some locations still show the old record, you can see exactly which resolvers have not yet updated. The dig command from any terminal: dig domain.com TXT | grep spf returns all TXT records matching SPF so you can immediately see if there are two v=spf1 records.

For the dangling CNAME check, there is no single tool that does it reliably. The audit is manual: pull a full list of your DNS records, then visit or query each CNAME destination and verify the hostname resolves to something you still control. For a hosting environment with dozens of service integrations, budget 30 minutes for this audit and repeat it after every major service change. It connects directly to the uptime and availability conversation — a subdomain takeover is a form of outage where your subdomain is online but serving the wrong content.

DNS Record Builder: Generate the Right Records for Your Setup

Instead of searching through documentation to find the exact records for your setup, select your scenario below. The builder generates copy-paste ready DNS records with field labels matching the interfaces in Cloudflare, Namecheap, and cPanel.

The embed version of this tool is available for use on hosting tutorials and provider documentation with attribution. The SPF builder scenario is particularly useful for sites that send email through multiple services simultaneously — it merges all includes into a single valid v=spf1 record, which is the only format that passes SPF validation.

Your DNS Records Audit Checklist: 12 Things to Verify Before and After Any Migration

Run this checklist before any planned hosting migration and again 24 hours after the migration is confirmed stable. Each item catches a specific failure mode. None of them take more than 2 minutes to verify.

This checklist is designed to be worked through in 15-20 minutes. Every item has a specific, free verification method. Save this page before any hosting migration — the TTL strategy from Section 6 combined with this checklist covers the full pre and post-migration DNS protocol. For a complete view of what can go wrong during migrations and how DNS failures cause downtime, the uptime and downtime guide has the failure taxonomy.

DNS Records FAQ

What is the difference between an A record and a CNAME record?

An A record maps a hostname directly to an IP address. A CNAME maps a hostname to another hostname, which then resolves to an IP. The practical difference: A records are terminal — they give you the final answer. CNAMEs are referential — they point to something that needs to be looked up again. For a subdomain like www.domain.com, either works. For the root domain (domain.com with no prefix), only an A record works correctly because CNAMEs at the zone apex violate RFC 1034 and break DNS entirely. Use A records when you have a static IP. Use CNAMEs when you are pointing a subdomain at a CDN, hosting platform, or external service that gives you a hostname rather than an IP.

Why does DNS propagation take so long?

It takes as long as your TTL says it can. TTL (Time to Live) is the number of seconds resolvers are permitted to cache your DNS record before re-querying. If your TTL is 86400, resolvers that already cached your record can serve the old value for up to 24 hours. The '24-48 hours' figure repeated across the web is based on old industry defaults that set TTL to 86400 by default. Modern DNS providers often default to 3600 (one hour) or lower. If you set your TTL to 300 before making a change, propagation takes about 5-15 minutes. The legitimate source of longer delays is ISP recursive resolvers that ignore TTL — some cache records longer than instructed. This is rare and outside your control, but it is why some users report seeing old records hours after you changed them.

How do I point my domain to a new hosting provider?

There are two approaches: change nameservers (NS records) or change A records. If your new host provides nameservers, changing NS records at your registrar transfers all DNS management to the new host. This is cleaner for a full migration but takes longer to propagate (24-48 hours because NS TTLs are typically high). If you keep your current DNS provider and just move the website, update the A record for your root domain and www to the new host's server IP. With TTL at 300, this propagates in 5-15 minutes. Before either approach, lower your A record TTL to 300 at least 48 hours in advance. For email, do not change MX records until the email migration is complete and verified at the new provider.

What DNS records do I need for Google Workspace email?

You need five DNS records to fully configure Google Workspace email. First, the MX records: add five MX records pointing to Google's mail servers (ASPMX.L.GOOGLE.COM with priority 1, plus four ALT servers with priorities 5, 5, 10, 10). Second, an SPF TXT record: v=spf1 include:_spf.google.com ~all (this must be merged with any existing SPF record if you have one — only one v=spf1 record allowed per domain). Third, a DKIM TXT record: generate the key in Google Workspace Admin under Apps > Gmail > Authenticate email, then add the long TXT record at the selector subdomain Google specifies (usually google._domainkey.domain.com). Fourth, a DMARC TXT record at _dmarc.domain.com: start with v=DMARC1; p=none; rua=mailto:your@domain.com to monitor before enforcing. Fifth, optionally a BIMI record if you want brand logo display in supporting clients.

Why are my emails going to spam even though my DNS looks correct?

The most common cause is a DMARC policy of p=none, which means you are monitoring failures but not enforcing anything. Receiving servers see that your domain has no enforcement policy and may still route to spam. The second most common cause is multiple SPF records on the same domain — only one v=spf1 record is valid, and having two causes SPF to fail validation silently. Third: DKIM may be technically present but the key was rotated at the provider and the old DNS record is no longer valid. Fourth: your IP address may be on a blocklist — check at MXToolbox Blacklist Check. Fifth: your sending domain may have recently changed mail providers and the DMARC alignment check is failing because SPF or DKIM do not align with the From address. Run your domain through Google's Email Sender Guidelines checker and MXToolbox SuperTool to surface the specific failure.

What does Cloudflare's orange cloud actually do to my DNS records?

When a DNS record is proxied (orange cloud), Cloudflare returns its own IP address when anyone queries your hostname, not your server's real IP. All HTTP and HTTPS traffic goes to Cloudflare's edge network first, where it passes through the WAF, DDoS protection, and caching layers before being forwarded to your origin server. Your origin IP address is hidden from DNS lookups. When a record is DNS-only (grey cloud), Cloudflare returns your actual server IP in DNS responses, and traffic goes directly from the visitor to your server. Cloudflare adds no value for proxied records other than DNS management itself. The practical implications: proxied records benefit from Cloudflare's security and performance features but require HTTPS to work correctly. Non-HTTP services (mail, FTP, game servers) break when proxied because Cloudflare only proxies HTTP and HTTPS traffic.

Can I use a CNAME at my root domain?

Not with standard DNS. RFC 1034 prohibits CNAMEs at the zone apex because a CNAME replaces all other records at the same name. At the zone apex (domain.com with no subdomain), the SOA and NS records must exist. A CNAME would replace them, making the entire zone invalid. The workaround is ALIAS or ANAME records, which are non-standard extensions provided by some DNS providers including Cloudflare (as CNAME flattening), Amazon Route 53, DNSimple, and NS1. These records behave like CNAMEs but are resolved server-side, returning the A record value rather than a CNAME reference, which satisfies the RFC restriction. If you need to point your root domain at a CDN or platform that gives you a hostname rather than an IP, check whether your DNS provider supports ALIAS or ANAME before assuming you can use a CNAME.

What is a TXT record used for?

TXT records are general-purpose text containers that DNS was extended to support. Because they can hold arbitrary text, they became the standard mechanism for everything that needs to be verified or configured in DNS without requiring a new record type. Current uses include: SPF (email sender authorization), DKIM (email cryptographic key), DMARC (email authentication policy), domain ownership verification for Google Search Console, Google Workspace, Microsoft 365, and dozens of other services, BIMI (brand logo for email), ACME challenge for Let's Encrypt certificate issuance, and custom application-level configuration. A domain's TXT records are essentially its credential store — every service that needs to verify ownership or publish a policy does it through TXT.

How do I check if my DNS records are correct?

Three tools cover every case. For global propagation status, use dnschecker.org — enter your domain and record type and it checks from 22 global locations simultaneously. For deep inspection of all record types, use MXToolbox SuperTool at mxtoolbox.com/SuperTool — it checks MX, SPF, DKIM, DMARC, blacklists, and PTR in one dashboard. For command-line verification, use dig: dig domain.com A returns the A record; dig domain.com MX returns mail server records; dig domain.com TXT returns all TXT records. To check from a specific nameserver: dig @8.8.8.8 domain.com A queries Google's resolver. To see the full resolution chain: dig +trace domain.com shows every step from root to authoritative. The combination of dnschecker.org for propagation and MXToolbox SuperTool for email authentication covers 90% of real-world DNS troubleshooting.

What is the difference between NS records and A records?

An A record answers the question: what IP address does this hostname map to? An NS record answers a different question: which server is authoritative for answering DNS queries about this domain? They operate at completely different levels. NS records are set at your domain registrar and tell the global DNS system which nameservers to ask when anyone queries your domain. A records are set at those nameservers and contain the actual IP routing information. Changing your NS records means telling the internet to ask a different server for all DNS answers. Changing your A records means changing what the current nameserver tells people when they ask where your domain points. You can change A records quickly. Changing NS records requires waiting for the old NS records to expire from caches worldwide, which can take 24-48 hours.

How long does it take for DNS changes to take effect?

Exactly as long as your TTL says, plus a small window for ISP resolvers that ignore TTL. If your TTL is 3600 (the most common default), a DNS change becomes visible to all properly-behaving resolvers within one hour. If your TTL is 300, within 5-15 minutes. If your TTL was 86400, up to 24 hours. The key insight: the TTL that matters is the one that was set before you made the change, not after. If you change your A record and simultaneously change the TTL from 86400 to 300, resolvers that already cached the old A record will cache it for up to 24 hours before they ever see the new TTL. This is why the correct approach is to lower TTL 48-72 hours before any planned DNS change, let the high-TTL cached values expire, then make the actual change with TTL already low.

What is a CAA record and do I need one?

A CAA (Certification Authority Authorization) record specifies which certificate authorities are permitted to issue SSL certificates for your domain. Without a CAA record, any CA in the world can issue a certificate for your domain if they can pass the domain control validation. With a CAA record set to 'letsencrypt.org', only Let's Encrypt can issue certificates. This matters because: DNS hijacking attacks often involve redirecting your domain to a server with a fraudulently obtained certificate. A CAA record that restricts issuance to your current CA prevents the fraudulent certificate from being obtained in the first place, making the attack ineffective. CAA records take 30 seconds to add and cost nothing. If you use Let's Encrypt: domain.com. CAA 0 issue "letsencrypt.org". If you use ZeroSSL: domain.com. CAA 0 issue "sectigo.com". If you use Cloudflare for SSL: domain.com. CAA 0 issue "comodoca.com" and also add one for "letsencrypt.org". Every production domain should have one.

Where to Go Next

DNS records sit at the intersection of performance, security, and deliverability. The three pages that extend most directly from what you have just read: the SSL certificates guide covers CAA record implications in detail alongside how certificate issuance works end-to-end. The CDN guide goes deep on Cloudflare's proxy behavior, CNAME flattening mechanics, and what the edge network does between DNS resolution and your origin server. And the cache guide explains how DNS TTL caching interacts with browser cache and CDN cache — three separate caching layers with different expiry mechanics.

For choosing a hosting provider that uses quality DNS infrastructure and does not bundle slow registrar-level DNS with shared hosting plans, the best web hosting comparison covers DNS provider quality as part of the infrastructure evaluation. ScalaHosting and Cloudways both use infrastructure-level DNS that avoids the registrar-bundled slowness described in Section 9.