DNS Records Explained: A, CNAME, MX, TXT, NS and CAA for App Builders

Quick answer: DNS records tell the internet where your app loads, where your email lands, and who may issue certificates for your domain. A and AAAA map names to addresses, CNAME aliases them, MX routes mail, TXT carries SPF, DKIM and DMARC, NS delegates control, and CAA restricts certificate issuance · audit all six regularly.

By Daniel A · Kraftwire Software

DNS records are the configuration files that tell the internet how to handle your domain. For app builders, the six essential records are A (points to an IPv4 address), CNAME (aliases one name to another), MX (routes email), TXT (holds security policies like SPF/DMARC), NS (identifies authoritative servers), and CAA (restricts which authorities can issue SSL certificates). Correctly configuring these prevents site downtime, email delivery failures, and high-severity security risks like subdomain takeovers.

Why Do DNS Records Matter for Your App?

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.

What Do the Six DNS Record Types Actually Do?

A and AAAA · The Address Records

AAAA does the same for IPv6. This is the foundation of every lookup chain · whatever aliases sit in between, the browser ultimately needs a numerical IP address, and an A or AAAA record is where it comes from.

CNAME · The Alias

A CNAME (Canonical Name) record maps an alias or subdomain to another domain name rather than an IP address. For example, www.example.com → yourapp.netlify.app. According to research on DNS record types, CNAMEs are frequently used to point subdomains to a domain's existing A or AAAA record, simplifying management by centralizing the IP address location.

Two rules often trip up builders:

• This is why the bare apex domain (example.com) usually cannot be a CNAME, as it must also contain NS and SOA records.
• CNAME records are a primary vector for subdomain takeovers if the target (the "canonical" name) is deleted but the DNS entry remains.

MX · Where Email Lands

MX (Mail Exchanger) records list the mail servers responsible for accepting email on behalf of your domain. They include a priority number where the lowest number takes precedence: 10 aspmx.l.google.com. If you lack an MX record, you cannot receive email. If you have a stale MX record pointing to a provider you no longer use, you risk "email blackholing" or unauthorized parties intercepting your communications.

TXT · The Security Workhorse

TXT records hold arbitrary text, but for modern apps, they are the primary home for security protocols. This is where SPF policies (v=spf1 include:_spf.google.com ~all), DMARC policies, and DKIM public keys reside. Most of your domain's email security posture is defined by these strings. Without them, your app's transactional emails (like password resets) are likely to land in spam folders.

NS · Who Answers for the Zone

NS (Name Server) records indicate which servers are authoritative for your domain. These are typically provided by your DNS host (e.g., Cloudflare, Route 53, or Vercel). Changing these at your registrar transfers total control of your DNS zone. Stale NS delegations · where you point to a DNS provider you've stopped paying for · can lead to total domain hijacking.

CAA · Who May Issue Certificates

A CAA (Certificate Authority Authorization) record whitelists specific CAs for your domain: 0 issue "letsencrypt.org". CAs are legally required to check this record before issuing a certificate. This prevents an attacker from using a less-secure CA to spoof a certificate for your site. Setting this up is a critical step in a SaaS security guide to ensure your TLS chain remains untampered.

Which DNS Records Carry Security Weight?

Many of these high-severity risks are directly tied to DNS mismanagement.

1. Email Authentication (SPF, DKIM, DMARC)

Without these TXT records, anyone can send mail claiming to be admin@yourdomain.com. SPF defines who can send; DKIM signs the mail to prove it wasn't altered; DMARC tells the receiving server what to do if SPF or DKIM fails. For vibe-coded apps built on platforms like Lovable or Bolt, setting these up is essential for user trust. You can verify your setup with the email security checker.

2. Subdomain Takeover

This occurs when a CNAME points to a platform resource (like a *.herokuapp.com or *.vercel.app URL) that has been deleted. An attacker can claim that name on the platform and instantly serve content on your subdomain. This is a "High" severity issue because the attacker can often provision a valid SSL certificate for your subdomain, making the phishing attempt nearly indistinguishable from your real site.

3. Certificate Issuance (CAA and DNSSEC)

CAA prevents "shadow" certificates. DNSSEC (Domain Name System Security Extensions) adds a layer of trust by digitally signing DNS records, ensuring that a "Man-in-the-Middle" cannot redirect your users to a malicious IP address by spoofing an A record.

How Does DNS Propagation Actually Work?

"Propagation" is a misnomer. DNS is not pushed; it is pulled and cached. The speed of a change depends entirely on the TTL (Time to Live).

When a resolver (like Google DNS or your ISP) fetches a record, it keeps it in memory for the duration of the TTL. If your TTL is 3600 (one hour), and you change your IP address, users who recently visited your site will continue to see the old IP for up to 60 minutes.

The Migration Playbook:

• Lower TTLs early: 24 hours before a move, lower your TTL to 300 seconds.
• Wait: Ensure the old, long TTL has expired from most caches.
• Switch: Change the record. The update will now be picked up within 5 minutes globally.
• Restore: Once verified, raise the TTL back to a higher value (like 3600 or 86400) to reduce the load on your DNS servers and improve performance.

AEO and AI Visibility for Vibe-Coded Apps

Modern DNS management also impacts how AI agents and search engines perceive your app. Answer Engine Optimization (AEO) is the practice of making your site "readable" for LLMs like ChatGPT or Claude. If your DNS is slow or misconfigured, AI crawlers may fail to index your site, leading to poor visibility in AI-generated answers.

Slow DNS resolution contributes to high "Time to First Byte" (TTFB), which negatively impacts both SEO and AEO. Using a fast, global DNS provider and keeping your records lean is a core part of an AI visibility AEO guide.

How to Audit Your Domain in 10 Minutes

• Enumerate Records: Use the DNS lookup tool to list every A, CNAME, and TXT record.
• Identify "Dangling" Records: Look for CNAMEs pointing to services you no longer use. Delete them immediately.
• Verify Email Security: Check for a DMARC record. If it doesn't exist, or is set to p=none, your domain is vulnerable to spoofing.
• Check for CAA: Ensure you have at least one CAA record to restrict certificate issuance.
• Scan for Vulnerabilities: Run a free security scan to see if your DNS configuration is leaking information or leaving you open to injection attacks.

Wrap Up

DNS is the "invisible" layer of your stack, but it is often the most fragile. A single stale CNAME or a missing SPF record can compromise your entire brand's reputation. By understanding these six record types and performing regular audits, you ensure your app remains fast, secure, and visible to both humans and AI. For a deeper dive into protecting your infrastructure, consult the vibe coding security checklist.

faq:

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

A CNAME maps a name to another name (e.g., www.example.com to yourapp.netlify.app). CNAMEs are aliases that require an additional lookup step, whereas A records provide the final destination IP immediately.

• q: Why can't I put a CNAME on my root domain?

a: DNS specifications require that a name with a CNAME cannot have any other records. Since a root (apex) domain must have NS and SOA records to function, a CNAME would conflict with them. Most modern DNS providers offer "CNAME Flattening" or ALIAS records to solve this.

• q: How long does DNS propagation take?

a: DNS doesn't "propagate" in a push fashion; it relies on caching. The time it takes for a change to be seen globally depends on the Time to Live (TTL) of the old record. If your TTL was set to 3600 seconds, it may take up to an hour for all caches to expire and fetch the new value.

• q: What is a subdomain takeover and how do I prevent it?

a: A subdomain takeover occurs when a DNS record points to a deleted external service (like a GitHub Pages or Heroku app). An attacker can claim that name on the service and control your subdomain. Prevent this by always deleting the DNS record before or at the same time as the service it points to.

• q: Do I need SPF, DKIM, and DMARC if I don't send email?

a: Yes. Even if you don't send email, you should publish a "restrictive" SPF record (v=spf1 -all) and a DMARC policy (p=reject). This prevents attackers from spoofing your domain to send phishing emails, which protects your domain's reputation and your users' safety.

• q: How can I check my DNS records for free?

a: You can use SimplyScan's DNS lookup tool to see your public records instantly. For a more comprehensive check, the DNS security checker evaluates your SPF, DMARC, CAA, and DNSSEC status to identify missing security layers that could be exploited by attackers.

excerpt: DNS records tell the internet where your app loads, where your email lands, and who may issue certificates for your domain. A and AAAA map names to addresses, CNAME aliases them, MX routes mail, TXT carries SPF, DKIM and DMARC, NS delegates control, and CAA restricts certificate issuance · audit all six regularly.

meta_description: Learn the 6 essential DNS records (A, CNAME, MX, TXT, NS, CAA) for app builders. Fix security risks like subdomain takeovers and improve email delivery.

meta_title: DNS Records Explained: A, CNAME, MX, TXT, NS, CAA

title: DNS Records Explained: A, CNAME, MX, TXT, NS and CAA for App Builders