DNS Record Types Explained for Developers: A, AAAA, CNAME, MX, TXT, and More

Overview

Here is the shortest useful way to think about DNS: it is the system that maps names to the information other systems need in order to connect, route, verify, or trust traffic. Most teams interact with DNS during common tasks such as pointing a domain at an app, setting up a CDN, enabling email delivery, proving domain ownership, or handling a migration between providers.

The reason DNS changes feel risky is that records often work together. A web app may rely on an A or AAAA record, a subdomain may use a CNAME, email may depend on MX, TXT, and sometimes CNAME records for authentication, and domain authority is governed by NS records. A single incorrect entry can lead to outages, failed verification, broken mail flow, or traffic sent to the wrong place.

Below is a plain-language reference for the most common record types:

• A: Maps a hostname to an IPv4 address. Example use: app.example.com -> 203.0.113.10.
• AAAA: Maps a hostname to an IPv6 address. Same idea as A, but for IPv6.
• CNAME: Points one hostname to another hostname. Common for subdomains that should follow a provider-managed target.
• MX: Tells other mail servers where to deliver email for a domain.
• TXT: Stores arbitrary text values, often used for verification, SPF, DKIM, DMARC, and other policies.
• NS: Defines which name servers are authoritative for the domain or delegated subdomain.
• SOA: The start of authority record. Usually managed automatically, but useful during troubleshooting and zone transfers.
• CAA: Specifies which certificate authorities are allowed to issue TLS certificates for the domain.
• PTR: Reverse DNS record mapping an IP address back to a hostname. Often relevant for email infrastructure and some network policies.
• SRV: Defines service endpoints with host and port information. More common for protocols like SIP, XMPP, LDAP, and some internal service discovery cases.

Two practical rules help avoid a lot of trouble:

1. Choose the record type based on what the destination expects, not what feels convenient.
2. Check whether the change affects only web traffic, or also email, certificates, verification, edge routing, and internal tooling.

If your team works across CI/CD, platform engineering, or edge delivery, DNS should be treated like shared infrastructure. It benefits from review, change history, and a repeatable checklist just like application config. That same mindset shows up in adjacent operational work such as DevSecOps best practices for CI/CD pipelines and platform engineering operating models.

Checklist by scenario

Use this section as the reusable part of the article. Start with the scenario, then verify the required record types, dependencies, and common provider-specific constraints.

1. Point a website or app to a server or load balancer

Usually needed: A and/or AAAA records, sometimes CNAME for subdomains.

• For the root domain, confirm whether your DNS provider supports direct flattening or alias behavior if the target is a hostname rather than a static IP.
• If you have a fixed IPv4 address, use an A record.
• If you have a fixed IPv6 address, use an AAAA record.
• For subdomains such as www, api, or docs, a CNAME is often appropriate when the provider gives you a canonical hostname.
• Verify whether your hosting or edge platform requires both example.com and www.example.com to be configured separately.
• Plan redirects intentionally. DNS does not perform HTTP redirects by itself.

Good fit: A/AAAA when you control the destination IPs; CNAME when the destination hostname may change under a managed platform.

2. Connect a domain to a CDN, edge platform, or managed hosting provider

Usually needed: CNAME for subdomains, sometimes A/AAAA or provider-specific apex support.

• Read the provider instructions closely for apex domains versus subdomains.
• Check if TLS issuance depends on domain validation through DNS or HTTP.
• Confirm whether the provider expects the DNS to be authoritative elsewhere or transferred fully to its own name servers.
• Keep a note of rollback values before cutover.
• Validate cache and propagation expectations with a low-risk subdomain first when possible.

Good fit: CNAME when the provider rotates infrastructure behind a stable hostname.

3. Set up inbound email for a domain

Usually needed: MX records, often TXT for SPF, DKIM, and DMARC.

• Create the MX records exactly as specified, including priority values.
• Make sure the hostname referenced by the MX record resolves correctly.
• Add SPF as a TXT record to describe authorized sending sources.
• Add DKIM records as instructed by the mail provider, often long TXT values or provider-managed CNAMEs.
• Add a DMARC TXT record to define alignment and reporting behavior.
• Check that old MX records are removed if they are no longer valid, especially during a mail provider migration.

Good fit: MX for mail routing; TXT for mail policy and authentication.

4. Verify domain ownership for SaaS tools, cloud services, or certificates

Usually needed: TXT or CNAME.

• Use the exact host label requested. Some providers expect the root, others a prefixed label such as _acme-challenge or a service-specific subdomain.
• Paste verification tokens carefully. Extra quotes, spaces, or duplicated domain suffixes are common causes of failure.
• If multiple verifications are needed, ensure the provider allows multiple TXT values on the same name.
• Decide whether to leave the record in place for future renewals or remove it after one-time validation, based on the provider workflow.

Good fit: TXT for one-time or policy-like verification; CNAME when a service wants ongoing delegation to a managed target.

5. Delegate a subdomain to another team, vendor, or environment

Usually needed: NS records at the parent zone.

• Use NS records when you want a separate authoritative zone for something like dev.example.com or status.example.com.
• Confirm the child zone exists and is populated before updating the parent NS records.
• Document ownership clearly so future engineers know which provider controls which portion of the namespace.
• Avoid partial delegation confusion, where records are edited in the wrong provider after authority has moved.

Good fit: NS when a subdomain should be independently managed.

6. Lock down certificate issuance

Usually needed: CAA.

• Add CAA records if you want to restrict which certificate authorities may issue certificates for the domain.
• Check inherited behavior from parent domains if the subdomain does not define its own CAA policy.
• Review CAA before onboarding a new edge, CDN, or certificate management vendor.

Good fit: CAA as a security control, especially in larger environments.

7. Run services that depend on named ports or protocol-specific discovery

Usually needed: SRV, sometimes alongside A/AAAA or CNAME.

• Use SRV only when the client or protocol actually supports it.
• Verify the service name, transport, priority, weight, port, and target host formatting.
• Do not assume browsers or standard web traffic will use SRV records.

Good fit: Internal services, communications tools, or legacy protocols that explicitly support SRV.

8. Configure reverse DNS for mail or network trust requirements

Usually needed: PTR, often managed by the IP owner rather than your normal DNS zone.

• Check who controls the IP block. Reverse DNS is often handled by your hosting provider, ISP, or cloud vendor.
• Make sure the PTR target also resolves forward to the expected IP where possible.
• Use a stable hostname that matches the mail server or service identity.

Good fit: Mail servers and infrastructure services where reverse lookup matters.

What to double-check

Before saving a DNS change, pause and review the details below. This is where most avoidable mistakes are caught.

• Host vs fully qualified name: Different DNS editors treat names differently. Some expect only the label, while others append the zone automatically. Entering the full domain in the wrong place can create an unintended duplicate name.
• Root domain vs subdomain: The apex behaves differently from www or other subdomains. Not every provider accepts CNAME at the root.
• TTL values: Lower TTLs can help before planned migrations, but keep expectations realistic. Lowering TTL after the fact does not instantly remove old caching everywhere.
• Existing records at the same name: Some record combinations are invalid or operationally risky. For example, a CNAME generally should not coexist with other record types at the same name.
• Mail record interactions: Updating MX without checking SPF, DKIM, and DMARC creates partial migrations that are hard to diagnose.
• IPv6 readiness: If you publish AAAA records, make sure the application, firewall, edge path, and observability setup actually support IPv6 traffic.
• Certificate issuance path: If you add CAA or switch providers, verify that certificate automation still works.
• Authoritative provider: Confirm where the active zone is hosted. Teams often edit stale records in the wrong DNS provider after a registrar or name server change.
• Propagation and cutover planning: Schedule changes with enough time for cache expiry and rollback if needed.
• Documentation: Record why the change exists, who requested it, and what depends on it. DNS debt accumulates quickly when records are left unexplained.

For teams standardizing operational work, it helps to treat DNS entries like application config: review changes, keep naming conventions consistent, and document ownership. The same approach improves other engineering workflows too, from scalable GitHub Actions workflows to engineering productivity tooling decisions.

Common mistakes

This is the part most readers come back to after something breaks. The patterns are familiar, and nearly all of them are preventable.

• Using CNAME where an A or AAAA record is required: Especially at the root domain, where provider behavior may differ.
• Leaving old records in place during migrations: Traffic or mail may keep flowing to the previous provider in inconsistent ways.
• Breaking email while changing web hosting: Developers sometimes update domain settings with a web-first mindset and overlook MX or TXT records tied to email.
• Publishing SPF incorrectly: Multiple separate SPF TXT policies or malformed syntax can create delivery issues.
• Forgetting DKIM or DMARC: Mail may route, but authentication and trust suffer.
• Creating duplicate names accidentally: A UI that appends the zone automatically can turn app.example.com into app.example.com.example.com.
• Changing NS records without preparing the target zone: This can cause a full outage for the delegated domain or subdomain.
• Assuming DNS does redirects or health checks by itself: DNS routes names to destinations, but redirect logic and application health behavior often live elsewhere.
• Ignoring reverse DNS for mail hosts: Everything may look right in the main zone while outbound mail reputation still suffers.
• Making urgent changes without a rollback note: Even simple DNS edits deserve a before-and-after record.

If your team regularly handles infrastructure changes under pressure, it may be worth building a lightweight preflight checklist into your deployment process. That operational discipline aligns well with topics like secrets management and broader developer workflow utilities.

When to revisit

DNS is not a set-it-and-forget-it task. Revisit your records whenever the underlying system, provider, or ownership model changes. A short recurring review can prevent stale configuration from turning into an incident later.

Revisit DNS records when:

• You migrate hosting providers, CDNs, edge platforms, or load balancers.
• You add or retire email providers.
• You onboard a new SaaS tool that needs domain verification or branded sending.
• You enable IPv6 or retire legacy network paths.
• You change certificate management or tighten issuance with CAA.
• You reorganize teams and need clearer subdomain delegation.
• You prepare for seasonal traffic, launch windows, or major campaign periods.
• You discover records with no documented owner or purpose.
• Your workflows or tools change and DNS automation needs to be updated.

Practical action plan for your next review:

1. Export or inventory the current zone.
2. Group records by purpose: web, edge, email, verification, security, delegated subdomains.
3. Mark each record with an owner, dependency, and last confirmed use.
4. Remove or archive stale entries only after confirming they are unused.
5. Standardize a change checklist for future edits, including validation and rollback notes.
6. Store DNS decisions somewhere engineers can actually find them during incidents.

If you want a simple habit, review DNS before major infrastructure planning cycles and again whenever your toolchain changes. That timing works well because DNS often sits underneath CI/CD, platform migrations, security controls, and customer-facing delivery. It is rarely the loudest part of the stack, but it is often one of the most consequential.

Used well, DNS becomes predictable infrastructure rather than tribal knowledge in a registrar dashboard. That is the real goal of understanding record types: not memorizing acronyms, but making domain changes safer, faster, and easier to repeat.