A website can fail for some users even when its server and SSL certificate appear healthy. An old cached address, inconsistent authoritative answers or a broken CNAME chain can send users to different destinations. Start by separating the DNS answer from the application response: a correct record does not prove that the target can serve the requested hostname.
This guide explains common mistakes in A, AAAA, CNAME, MX, TXT, SRV and CAA records. We will connect each record’s purpose to practical checks: which types can coexist, which targets need address records, how mail authentication uses DNS and why TTL changes do not clear existing caches. Use those checks when troubleshooting a service or planning a move.
The Story of DNS: A Friendly Map, Not a Magic Wand
Changing a record at a DNS provider does not push the new answer into every recursive resolver or device. Caches may keep earlier answers, and the authoritative service must also publish the update across its own servers. TTL is the duration, in seconds, before a cached answer normally needs refreshing; it is not an expiry date that deletes the authoritative record. Check both the published answer and the resolver’s cached answer.
Lower TTLs can increase query frequency; higher TTLs let answers remain cached longer. Before a planned move, lower the TTL far enough ahead to account for the previous value. A resolver that already cached the old answer does not learn the shorter TTL immediately. Keep the old service available during the transition, then restore a suitable TTL after checking the new service.
While we’ll talk about specific record types, remember the big picture: DNS is about mapping a name to something—an address, a server, a service, a policy. Get the map right and your site feels fast and reliable; get it wrong and you’ll be chasing ghosts.
A and AAAA: The Addresses on the Internet’s Envelope
What A and AAAA records publish
The A record is your domain’s home address—but specifically for IPv4. If your website is example.com and your server’s IPv4 address is 203.0.113.10, your A record says, “Hey world, go here.” The AAAA record does the same thing but for IPv6. If you’ve ever noticed those long, colon-separated addresses (like 2001:db8::1), that’s AAAA’s territory. That’s the future knocking, and honestly, the future’s pretty nice.
A records provide IPv4 addresses; AAAA records provide IPv6 addresses. Whether you need one or both depends on the networks and clients you serve. Publishing AAAA does not configure IPv6 routing, firewall rules or the web server, and it does not guarantee faster page loads. For the wider planning context, see the guide to IPv4 address costs and alternatives; adding IPv6 does not by itself remove the need to support IPv4-only clients.
Multiple address records are valid, but do not check health
Multiple A records, multiple AAAA records and both types at the same owner name are valid. A resolver or client may vary the order or choose among the returned addresses; equal traffic distribution is not guaranteed. The records alone do not detect a failed server. DNS failover requires health checks and coordinated answer changes, while cached answers and client behavior still affect the transition.
Before publishing AAAA, test the service over IPv6: routing, firewall access, application listeners and HTTPS hostname/certificate handling must all work. An unreachable IPv6 address can cause delays or failures for some clients. Compare actual response times and errors over both protocols instead of assuming a fixed performance gain.
CNAME: The Friendly Alias That Comes with Rules
Think of CNAME like a nickname
A CNAME makes one DNS name an alias of another. For example, blog.example.com might point to hosting.example.net, whose address records identify the target. The CNAME value is a hostname, not an IP address, URL or path. It is not an HTTP redirect: the browser still requests the original hostname, so the destination must support that name and its TLS certificate.
But, and this is a crucial but, you can’t assign a CNAME at the same name as other records like MX or TXT. The zone apex cannot be a standard CNAME because it must also have SOA and NS records. Related DNSSEC metadata is a special exception to CNAME coexistence rules, not permission to add ordinary MX or TXT records alongside the alias. Some providers offer “ALIAS” or “ANAME,” which behave like a CNAME but resolve to A/AAAA behind the scenes. Those can be great, but they’re vendor features, not standard DNS record types. If you’ve ever switched a site to a CDN and the provider said “add a CNAME at your root,” that’s why you may have hit a wall—unless they support flattening.
The CNAME loop nightmare
Consider a hypothetical chain: shop.example.com points to store.example.net, which points to edge.example.org. If the final target is changed to point back to shop.example.com, the chain loops instead of reaching address records. Keep alias chains short, document each external dependency and check the final answer after a provider change. A target resolving successfully still needs to serve the original hostname.
If you’re exploring performance tweaks and traffic routing, it might be a good moment to understand what a content delivery network (CDN) is and how it speeds up your site. CDNs often rely on CNAMEs or ALIAS records, and knowing what’s happening under the hood helps you avoid surprises.
MX: Where Your Email Actually Goes
Setting mail delivery without shooting yourself in the foot
MX records identify servers that accept incoming mail for your domain. The target must be a hostname with direct A and/or AAAA records, not an IP address or a CNAME alias. For example, an MX target of mail.example.com requires address records at mail.example.com. The mail server must also accept mail for your domain and intended recipients; publishing an MX record does not configure that service.
Priority on MX records isn’t a ranking of “best to worst.” It’s more like a fallback order: lower numbers are tried first. If you have equal priorities, mail servers may choose randomly. That’s okay if your setup is designed for it. Just don’t try to encode fancy routing logic with MX priorities alone; it’s blunt.
Deliverability: It’s not just MX
Mail routing and authentication are separate. SPF checks the sending host against the envelope-sender or HELO domain; DKIM verifies a message signature using the signing domain’s public key. DMARC requires a passing SPF or DKIM result aligned with the visible From domain; either aligned mechanism can produce a pass. Our guide to SPF, DKIM, DMARC and rDNS covers these checks. Correct authentication helps diagnose mail problems but does not guarantee inbox delivery.
When changing mail providers, reduce the MX TTL early enough for its previous value to expire. Prepare the new service and DKIM keys before switching, and keep all still-active senders authorized in one SPF policy during overlap. Do not remove old DKIM keys while messages signed with them still need verification. Keep old mail reception and any queued-mail handling available through the transition; a DNS rollback also takes time to reach caches.
TXT: The Sticky Notes of DNS (Verification, SPF, and More)
TXT is where the internet checks your notes
TXT records are the general-purpose notepad for your domain. They get used for SPF policies, ownership verification (think Google, Microsoft, various SaaS tools), domain keys for DKIM, ACME challenges for certificate issuance, and a bunch of vendor-specific settings. If a service asks you to “add a TXT record,” they’re usually proving you control the domain or asking you to publish a policy.
A TXT resource record may contain several character strings, each at most 255 bytes. Applications such as SPF and DKIM concatenate the strings within one record without adding spaces. This is different from publishing several separate SPF records. Zone-file quotes are syntax; some DNS panels expect the value without surrounding quotes. Follow the panel’s format and query the published TXT data to check the resulting value.
The SPF rabbit hole
Publish only one v=spf1 TXT record at a given owner name; unrelated verification TXT records can coexist. SPF evaluation permits at most 10 DNS-querying terms, including nested include and redirect processing; exceeding the limit produces permerror, not a silent pass or ordinary fail. The limit is not simply the count of include entries in the top-level string. A final -all produces fail and ~all produces softfail; neither choice enables reporting, and receiver policy determines message handling.
SRV: The “Service Locator” Record Most People Forget
What SRV really does
SRV records are like a concierge telling clients exactly where to find a service: which hostname, which port, which priority, and even a weighting for basic load spreading. You’ll see SRV used for things like SIP, XMPP, Minecraft servers, and some enterprise services. The name includes the service and protocol, like _sip._tcp.example.com. The record itself points to a target hostname and port.
An SRV target must be a hostname with direct A/AAAA records, not an IP address or CNAME alias. A target of a single dot (.) explicitly indicates that the service is unavailable at that domain. In a zone file, the trailing dot on a complete hostname prevents it being interpreted relative to the zone; a DNS panel may normalize the name for you. Confirm how your editor represents the target.
SRV clients try reachable targets with the lowest numerical priority first. Within the same priority, weight controls relative selection probability; it is not a guaranteed traffic percentage or health check. The application and protocol must support SRV discovery. Adding SRV does not cause ordinary web browsers or every application to use a new port automatically.
CAA: The Bouncer for Your SSL Certificates
Only the CAs you trust should issue certs
CAA restricts which certificate authorities may issue certificates for a name when an applicable policy is present. It reduces the permitted issuer set for CAs that comply with the policy; it does not replace domain-control validation or prevent every possible misissuance. CAA does not revoke existing certificates or tell browsers whether an already issued certificate is valid.
For example, an issue property can authorize Let’s Encrypt using its issuer identifier letsencrypt.org. The issue policy also governs wildcard issuance unless an applicable issuewild property overrides it. The iodef tag provides a reporting contact, not an issuance restriction or a notification guarantee. CAA lookup uses the nearest applicable record set while following aliases and checking parent names, so inspect the policy applicable to each requested certificate name.
Check the CA’s diagnostic error when issuance fails; CAA policy is one possibility alongside challenge failures, DNSSEC validation errors and unreachable DNS servers. A staging request can help test the intended name without requesting a production certificate. A different test subdomain may inherit different CAA records, so its success does not establish that the production name is authorized.
Nameservers, Delegation, and the Mysterious Glue
Who’s actually in charge of your zone?
When you register a domain, the registrar points the world to your nameservers via NS records at the registry. Those nameservers are authoritative for your zone; they publish your A, AAAA, MX, and friends. When things get weird, it’s often because the parent (the registry side) and the child (your zone) disagree about which nameservers to trust. If you changed nameservers recently, the parent might still be pointing to the old set.
Glue records show up when your nameserver is inside your own domain. For example, ns1.example.com being the nameserver for example.com. That can create a chicken-and-egg problem: you need the NS to find the A record, but you need the A record to find the NS. Glue records solve that by putting the IP address at the parent so the loop doesn’t form. If your domain uses in-bailiwick nameservers like that, make sure your registrar has the correct glue on file. Outdated glue causes the kind of intermittent resolution issues that make you question your life choices.
Bonus: DNSSEC without the headache
DNSSEC lets validating resolvers check DNS data origin and integrity through a chain of trust; it does not encrypt DNS queries or secure the application itself. A parent DS record that no longer matches the zone’s keys can cause validation failures. Plan signing-key and nameserver changes together. See the DNSSEC guide and inspect the chain with DNSViz; a diagnostic report still needs interpretation and does not replace application testing.
Propagation Myths, TTLs, and How to Test Changes
TTL, Publication and Delegation All Matter
Cache expiry explains many differences between users, but it is not the only source of delay or error. Authoritative servers may disagree, delegations or glue may be stale, and DNSSEC validation may fail. Some resolvers can serve stale answers when they cannot refresh them from authoritative servers. There is no universal “propagation complete” deadline; compare response codes, targets and TTLs from multiple points.
First query every authoritative nameserver and compare the answers. Then check public or local resolvers to see what those resolvers return. Google Admin Toolbox dig is useful for quick record lookups; a local dig query can target a specific server. If a resolver differs, inspect caching, delegation, DNSSEC and reachability rather than assuming that waiting is the only fix.
Negative caching and the mystery of the vanished record
Negative caching remembers NXDOMAIN (name does not exist) or NODATA (the requested record type is absent). Its TTL is derived from the smaller of the authoritative SOA record’s TTL and SOA.MINIMUM. Adding a new positive record or lowering that record’s TTL does not erase an already cached negative answer. Check the response’s authority section and remaining TTL before changing unrelated records.
For a planned cutover, record the current values, prepare and test the new service, lower TTLs with the previous cache lifetime in mind, and change only the relevant records. Keep the old destination available until the transition is verified. Coordinate writes and data synchronization separately; DNS changes do not synchronize a database or finish a rollback immediately.
Common Pitfalls (and How to Dodge Them)
A checklist of record and target mistakes
Mixing CNAME with other records at the same name. This one bites a lot of people. If “www” has a CNAME, don’t also give “www” an MX or TXT. Most providers will warn you, but not all.
MX pointing to a CNAME. It might work sometimes, but it’s against the rules and can fail in surprising ways. Point MX to a hostname that resolves directly to A/AAAA.
Publishing AAAA before IPv6 is ready. Confirm routing, firewall rules, service listeners and TLS over IPv6 before adding the record. Test the resulting experience; an address allocation is not proof of working connectivity or a fixed speed improvement.
SPF records that are too long or too many. Keep it to one SPF record per name. Watch those “include:” chains and lookup limits. If you’re stuck, consolidate or ask your provider for a simpler include path.
TXT formatting mistakes. Distinguish the provider’s DNS-panel input format from a zone-file example. Check the record owner as well as quotes, spaces and long-string splitting, then query the published value. One SPF record may have several strings; it must not become several competing v=spf1 records.
SRV target set to an IP address or CNAME. Use a direct address-bearing hostname, and verify the port and application’s SRV support. A trailing dot matters in zone files; the editor may handle it differently.
CAA blocking certificate issuance. Check that the applicable issue and issuewild policy authorizes the intended issuer. Use the CA’s error details to distinguish a policy restriction from DNS lookup, DNSSEC or challenge failures.
Forgetting about the apex when using CDNs. Many CDNs rely on CNAMEs, which can’t live at the root without special provider features like ALIAS/ANAME or flattening. Plan for that early to avoid last-minute scrambling.
Mismatched parent/child NS records and stale glue. If nameserver changes don’t seem to stick, check what the registry says. It might be pointing to the wrong place even though your zone looks perfect.
Lowering TTL only at cutover time. Existing caches keep the earlier lifetime, so plan ahead for the previous TTL and negative responses. DNSSEC or delegation errors need correction; a shorter TTL alone cannot resolve them.
Assuming DNS alone will speed up a slow site. DNS can’t compress images, tune PHP, or cache HTML. It’s foundational, not a silver bullet. For performance gains, pair solid DNS with smart caching and delivery strategies. If you’re exploring that path, it’s worth learning how a CDN improves performance and when to use one.
Applying the Checks to Common Changes
1) Moving a site to a new host
For a hypothetical store migration, prepare the destination, test its hostname and TLS behavior, and record the existing A/AAAA values. Lower TTLs before the move, allowing for the previous values. Coordinate a final data sync or write freeze, switch DNS and monitor both destinations for errors. Retain a recovery copy and an explicit rollback plan; a low TTL cannot guarantee a migration without interruption.
2) Switching mail providers
For a mail-provider change, set up domains and pilot inboxes first. Prepare the new DKIM signing key and ensure the single SPF policy authorizes all active senders during the overlap. Switch MX only after incoming and outgoing tests succeed. Review DMARC alignment and delayed aggregate reports before tightening policy; old mail reception and DKIM validation may still be needed during the transition.
3) Enabling IPv6 without drama
For IPv6 rollout, first verify an actual IPv6 route to the service and test its firewall, listener and certificate behavior. Then publish AAAA while retaining the required IPv4 route. Observe both successful and failed connections from representative networks. If a problem appears, removing AAAA is subject to caching, so fix the service or plan recovery accordingly.
Testing and Troubleshooting Without Losing Your Mind
Keep a simple checklist
When troubleshooting, check four layers. First, do all authoritative nameservers publish the intended record? Second, what response code, target and TTL do relevant resolvers return? Third, do target hostnames resolve directly where required, especially MX and SRV? Fourth, do application behavior, mail-authentication policy, CAA or DNSSEC explain the failure? Separate DNS correctness from successful web or mail transactions.
Use Google Admin Toolbox dig for record lookups or a local DNS tool when you need a chosen server. DNSViz can help inspect DNSSEC and delegation. For mail tests, inspect the receiving system’s trusted Authentication-Results header for SPF, DKIM and DMARC results and their domains; the mere presence of a DKIM-Signature header does not prove that it verified.
Security Touchpoints You’ll Thank Yourself For
Start small, win early
Security often feels like a huge project, but small steps count. Add a CAA policy that authorizes only the CAs you use. Sign your zone with DNSSEC if your provider makes it straightforward. Rotate DKIM keys periodically (your mail provider should help with this). And when you go to renew or add certificates, remember that using a trusted CA such as Let’s Encrypt can be automated nicely, especially when your DNS supports ACME DNS challenges.
If you’re curious about the broader security picture beyond DNS, it’s worth pairing proper DNS with strong HTTPS configurations and sensible headers. When you have a minute, take a look at setting up security headers the safe way in this approachable guide: The Friendly Guide to HTTP Security Headers. It complements a well-configured DNS setup beautifully.
Bringing It All Together
A and AAAA map names to addresses and can coexist with other ordinary records. CNAME creates an alias and cannot share its owner with ordinary A, AAAA, MX or TXT data. MX routes incoming mail to address-bearing hostnames. TXT carries policy, keys and verification values; each application defines the expected name and format. SRV supplies service locations to supporting clients, and CAA constrains permitted certificate issuers.
Along the way, keep TTLs in mind, check authoritative publication and delegation as well as caching, and test from the authoritative source and a couple of public resolvers. When things look odd, start small: is the record right? Does the target resolve? Are policies interfering? You don’t need to memorize every rule—just know where to look and keep a calm head.
I hope this walk-through demystified the alphabet soup in your DNS panel. If it saved you a headache or two, that’s a win in my book. And hey, if you’re diving deeper into email trust, don’t miss the practical SPF/DKIM/DMARC guide. For better performance, get comfy with how CDNs fit into the picture. And if you’ve been meaning to bring more integrity to your DNS responses, check out the friendly primer on DNSSEC basics. Hope this was helpful! See you in the next post, and may your records always resolve the first time.
