DNS Records Explained: A, CNAME, MX, TXT, NS and CAA for App Builders
Six DNS record types route your app, your email, and your certificates. Plain-language explanations of each, the ones that carry security weight, and how propagation actually works.
By Daniel A · Kraftwire Software
· 6 min readKey Takeaway
DNS records are the routing table of your product · they decide where your app loads from, where your email lands, and who is allowed to issue certificates for your name. Six record types cover almost everything an app builder touches, and a handful of them carry real security weight. Look yours up with the DNS lookup tool, then let the DNS security checker tell you which protections are missing.
The Records · In Plain Language
A and AAAA · the address records
An A record maps a name to an IPv4 address: app.example.com → 203.0.113.10. AAAA does the same for IPv6. This is the bottom of every lookup chain · whatever aliases sit in between, the browser ultimately needs an address, and an A or AAAA record is where it comes from.
CNAME · the alias
A CNAME says "this name is another name": www.example.com → yourapp.netlify.app. The lookup then continues at the target. Two rules trip people up. A name with a CNAME cannot hold any other records, which is why the bare apex domain (example.com) usually cannot be a CNAME and hosting providers offer ALIAS or ANAME workarounds. And a CNAME pointing at a platform hostname is a delegation of trust · more on that below.
MX · where email lands
MX records list the mail servers that accept email for your domain, each with a priority number where lower wins: 10 aspmx.l.google.com. No MX record means no inbound email · and a stale MX pointing at a provider you cancelled means someone else might be able to receive your email.
TXT · the catch-all that carries security
TXT records hold arbitrary text, which sounds boring until you notice what lives there: SPF policies (v=spf1 include:_spf.google.com ~all), DMARC policies at _dmarc.example.com, DKIM public keys at selector._domainkey.example.com, and the verification strings every SaaS asks you to add. Most of your domain's email security posture is literally a set of TXT records.
NS · who answers for the zone
NS records name the servers authoritative for your domain · typically your DNS host, like Cloudflare or Route 53. Change them at your registrar and you change who controls every other record. That power is exactly why stale NS delegations are dangerous.
CAA · who may issue certificates
A CAA record whitelists certificate authorities for your domain: 0 issue "letsencrypt.org". CAs are required to check it before issuing, so a good CAA policy means an attacker who tricks some other CA's validation still cannot get a certificate for your name. It is one line of DNS with an outsized payoff · the DNSSEC and CAA guide covers the exact records to set.
The Records That Carry Security Weight
Three areas deserve your attention beyond "does the site load".
First, email authentication. Without SPF, DKIM, and DMARC in your TXT records, anyone can send mail that claims to be from your domain, and receiving servers have no policy telling them to reject it. Phishing your own users with your own domain name should not be this easy, and fixing it costs three records. The email security checker grades all three in one pass.
Second, certificate issuance. CAA, as above · plus DNSSEC, which signs your DNS responses so resolvers can detect tampering. Neither is enabled by default anywhere.
Third, subdomain takeover. This is the one app builders ship accidentally. You create demo.example.com as a CNAME to a hosting platform, later delete the project on the platform, and leave the DNS record behind. The name now points at an unclaimed platform hostname · anyone who registers that hostname on the platform controls what loads at your subdomain, complete with valid HTTPS in many cases. The same logic applies to stale NS delegations for subzones. The rule: DNS records and the resources they point at must be created and destroyed together.
How Propagation Actually Works
"Waiting for DNS to propagate" makes it sound like your record is slowly flooding across the internet. It is not. Nothing is pushed anywhere · DNS is pull-based caching, and the only clock that matters is the TTL (time to live) you set on each record.
When a resolver answers a query, it caches the result for the TTL · say 3600 seconds. Change the record, and every resolver that cached the old value keeps serving it until its own copy expires. Different resolvers cached at different moments, so the change appears at different times for different users. That staggered expiry is the entire phenomenon people call propagation.
This gives you a practical playbook:
- Before a planned migration, lower the TTL on the records you will change · to 300 seconds, for example · and do it at least one old-TTL ahead of time, so the short value is what everyone has cached when you flip.
- Make the change, verify, then raise the TTL back so resolvers are not hammering your DNS host forever.
- Remember negative caching · a lookup for a record that did not exist yet is also cached, for the duration set in your zone's SOA record, which is why "I just added it and it still says NXDOMAIN" happens.
When you want to see what the world currently sees rather than what your zone file says, query through a public resolver with the DNS lookup tool instead of trusting your own machine's cache.
A Ten-Minute Audit for Your Own Domain
Run this on any domain you own, today:
- Enumerate what exists. Look up A, AAAA, CNAME, MX, TXT, NS, and CAA for the apex and for every subdomain you remember creating. Unknown records are findings · so are remembered subdomains with no live service behind them.
- Check the email trio. Confirm SPF exists and ends in
~all or -all, DKIM keys are published for your senders, and a DMARC record exists at _dmarc with a policy stronger than p=none once you trust your setup.
- Check issuance protections. Is there a CAA record naming only the CAs you use? Is DNSSEC enabled at your registrar?
- Hunt dangling pointers. For every CNAME to a platform (
*.netlify.app, *.github.io, *.herokuapp.com and friends), confirm the target resource still exists and belongs to you.
- Review TTLs. Records you might need to change in an emergency should not be sitting on 24-hour TTLs.
Steps 2 and 3 are exactly what the DNS security checker automates · it reads your live records and reports SPF, DMARC, CAA, and DNSSEC status in one shot, no zone-file access required.
Wrap Up
DNS is one of the few layers where a single missing line of configuration is invisible right up until it is a headline. Spend the ten minutes: pull your records with the DNS lookup, fix what the audit surfaces, and re-check after every migration. Then zoom out from the domain to the app it serves · a free security scan shows you both layers in one report.