DNS Records Explained: A, AAAA, CNAME, MX, TXT, and More

TL;DR: DNS records are instructions that tell the internet how to handle your domain. A records point domains to IPv4 addresses, AAAA records to IPv6, CNAME records create aliases, MX records direct email, and TXT records store text data for verification and security. Understanding these records is essential for managing your website, email, and online services.

Every time someone types your domain name into a browser, a complex lookup happens behind the scenes. DNS (Domain Name System) translates human-readable domains like "example.com" into IP addresses that computers use. The instructions for these translations are stored in DNS records.

What are DNS Records? {#definition}

DNS records are database entries that provide information about a domain, including which IP addresses are associated with it, where to send email, how to verify ownership, and more. They're stored on DNS servers and queried whenever someone accesses your domain. Think of DNS records as a phone book for the internet - they map names to numbers and provide instructions for routing different types of traffic.

Why DNS Records Matter for Indie Hackers

Understanding DNS isn't just for sysadmins. Whether you're setting up a new domain, connecting email, or integrating third-party services, you'll encounter DNS configuration regularly. Getting it wrong can make your site unreachable, break your email, or prevent services from connecting entirely.

Security also depends on proper DNS configuration. Records like SPF, DKIM, and DMARC protect your domain from being used in phishing attacks. Misconfigure them, and your legitimate emails might land in spam folders while attackers spoof your domain freely.

Perhaps most importantly, understanding DNS makes troubleshooting dramatically easier. When something breaks, you'll be able to diagnose whether the problem is your server, your DNS configuration, or something else entirely.

The Essential DNS Record Types

A Record (Address Record)

The A record is the most fundamental DNS record type. It creates a direct mapping between a domain name and an IPv4 address. When someone visits example.com, DNS looks up the A record and directs them to the IP address specified there.

example.com.        A    192.0.2.1
www.example.com.    A    192.0.2.1

You'll use A records primarily to point your domain to your web server, though they're also useful for pointing subdomains to specific servers. For load balancing, you can create multiple A records for the same domain - a technique called round-robin DNS that distributes traffic across several servers.

A records at the domain root (example.com rather than www.example.com) are called "apex" or "naked domain" records. These behave slightly differently from subdomain records, which becomes important when we discuss CNAME records later.

Every A record has a TTL (Time To Live) that controls how long resolvers cache the record before checking for updates. A typical TTL of 3600 seconds means the record is cached for one hour. Lower TTLs mean faster propagation of changes but more DNS queries; higher TTLs reduce load but slow down updates when you need to make changes.

AAAA Record (IPv6 Address Record)

The AAAA record works exactly like the A record but for IPv6 addresses instead of IPv4. The name comes from the fact that IPv6 addresses are four times longer than IPv4 addresses (128 bits vs 32 bits).

example.com.    AAAA    2001:0db8:85a3:0000:0000:8a2e:0370:7334

IPv6 matters more than many developers realize. IPv4 addresses have essentially run out, and adoption of IPv6 continues to grow steadily. Many mobile networks now use IPv6 as their primary protocol, meaning a significant portion of your mobile users might be connecting via IPv6.

Most websites should have both A and AAAA records to ensure accessibility for all users. If your hosting provider doesn't support IPv6 yet, you can skip the AAAA record, but it's worth checking - most modern hosts support it. Before adding AAAA records, test that your server actually responds correctly on IPv6 to avoid creating records that point to unreachable addresses.

CNAME Record (Canonical Name Record)

A CNAME record creates an alias from one domain name to another. Unlike A records that point to IP addresses, CNAMEs point to other domain names.

www.example.com.     CNAME    example.com.
blog.example.com.    CNAME    myblog.wordpress.com.

When someone visits www.example.com with the configuration above, DNS first follows the CNAME to example.com, then looks up that domain's A record to find the actual IP address. This indirection is useful because it means you don't need to update multiple records when an IP address changes.

CNAMEs are particularly valuable when connecting to third-party services. When you set up a CDN, email provider, or SaaS platform, they'll typically give you a CNAME to point to their infrastructure. If they ever change their IP addresses, your DNS automatically follows because you're pointing to their domain name, not their IP.

However, CNAMEs come with important restrictions. Standard DNS doesn't allow CNAME records at the apex domain (example.com without any subdomain). This is because CNAMEs can't coexist with other record types, and the apex domain needs other records like NS and SOA. Some DNS providers work around this limitation with proprietary features called "CNAME flattening" or "ALIAS records" that behave like CNAMEs but are technically implemented as A records behind the scenes.

MX Record (Mail Exchange Record)

MX records tell email servers where to deliver mail for your domain. Without properly configured MX records, email sent to addresses at your domain will bounce.

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.

The number before the mail server is the priority value. Email servers try the lowest priority number first, then fall back to higher numbers if the primary server is unavailable. In the example above, mail1.example.com handles email normally, but if it's down, servers will try mail2.example.com instead.

If you're using Google Workspace for email, your MX records will look something like this:

example.com.    MX    1     ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT1.ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT2.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT3.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365 uses a simpler configuration with a single MX record pointing to their mail protection service:

example.com.    MX    0     example-com.mail.protection.outlook.com.

One important technical detail: MX records must point to domain names that have A or AAAA records, never directly to IP addresses. Also, when switching email providers, remove your old MX records completely. Leaving old records in place can cause email routing loops or delivery to the wrong system.

TXT Record (Text Record)

TXT records store arbitrary text data associated with your domain. Originally designed for human-readable notes, they've become essential for email security and domain verification.

example.com.    TXT    "v=spf1 include:_spf.google.com ~all"
example.com.    TXT    "google-site-verification=abc123"

The most important use of TXT records is email authentication. SPF (Sender Policy Framework) records specify which mail servers are authorized to send email on behalf of your domain:

example.com.    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

This record says "email from my domain should only come from Google's servers or SendGrid's servers; treat anything else with suspicion."

DKIM (DomainKeys Identified Mail) uses TXT records to publish public keys that verify email signatures:

selector._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGf..."

DMARC (Domain-based Message Authentication) tells receiving servers what to do when emails fail SPF or DKIM checks:

_dmarc.example.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

TXT records are also commonly used for domain verification. When you connect a custom domain to services like Google Search Console, Mailchimp, or Stripe, they'll ask you to add a specific TXT record to prove you own the domain. The record typically looks like a random string that the service can query to verify ownership.

NS Record (Name Server Record)

NS records specify which DNS servers are authoritative for your domain. They're the delegation mechanism that tells the rest of the internet where to find your DNS records.

example.com.    NS    ns1.dnsprovider.com.
example.com.    NS    ns2.dnsprovider.com.

When you register a domain, your registrar sets the initial NS records to point to their name servers. If you want to use a different DNS provider (like Cloudflare or Route 53), you change the NS records at your registrar to point to the new provider's servers.

Changing NS records is a significant action because it affects all DNS records for your domain. The new DNS provider becomes the authoritative source for all your records, so you need to recreate your A, MX, TXT, and other records there before making the switch. NS changes can also take 24-48 hours to propagate fully across the internet, so plan accordingly.

Always maintain at least two NS records for redundancy. If your only name server goes down, your entire domain becomes unreachable.

SOA Record (Start of Authority Record)

The SOA record contains administrative information about your DNS zone. It's primarily used for DNS server synchronization and is usually managed automatically by your DNS provider.

example.com.    SOA    ns1.example.com. admin.example.com. (
                        2024011501 ; Serial
                        7200       ; Refresh (2 hours)
                        3600       ; Retry (1 hour)
                        1209600    ; Expire (2 weeks)
                        86400      ; Minimum TTL (1 day)
                        )

The fields in an SOA record control how secondary DNS servers synchronize with the primary:

• Primary NS identifies the main name server for the zone
• Admin email provides a contact address (the @ is replaced with a dot, so admin.example.com means [email protected])
• Serial is a version number that should increase with every change
• Refresh determines how often secondary servers check for updates
• Retry specifies how long to wait before retrying a failed refresh
• Expire sets when secondaries stop answering if they can't reach the primary
• Minimum TTL defines the default TTL for negative caching (when a record doesn't exist)

Most DNS providers handle SOA records automatically, so you rarely need to edit them directly. However, if you're managing your own DNS infrastructure, incorrect SOA settings can cause synchronization problems between servers.

Other Important Record Types

Beyond the core record types, you'll occasionally encounter a few others.

SRV records specify the location of specific services, including the port number. They're commonly used for services like SIP (voice over IP) and XMPP (messaging):

_sip._tcp.example.com.    SRV    10 5 5060 sipserver.example.com.

CAA records (Certificate Authority Authorization) control which certificate authorities can issue SSL certificates for your domain. Adding CAA records is a security best practice that prevents unauthorized certificate issuance:

example.com.    CAA    0 issue "letsencrypt.org"

PTR records provide reverse DNS, mapping IP addresses back to domain names. You don't configure these in your regular DNS - they're managed by whoever owns the IP address block (usually your hosting provider). PTR records are important for email deliverability because many mail servers check that the sending IP's PTR record matches the domain.

How to Configure DNS Records

Accessing DNS Management

DNS records are managed in one of three places depending on your setup. If you haven't changed anything from the default, your records are at your domain registrar - wherever you bought the domain. If you've delegated DNS to a third-party provider like Cloudflare or Route 53, you'll manage records there instead. Some web hosts also include DNS management as part of their service.

Common DNS management interfaces include Cloudflare, AWS Route 53, Google Domains, Namecheap, and GoDaddy. The interfaces vary, but they all ask for the same basic information.

Understanding Record Format

When adding a DNS record, you'll typically need to provide four pieces of information. The Name or Host field specifies the subdomain - use @ or leave it blank for the apex domain. The Type field is the record type (A, AAAA, CNAME, MX, TXT, etc.). The Value or Target field contains the IP address, domain name, or text content depending on the record type. Finally, the TTL field specifies how long to cache the record, with 3600 seconds (one hour) being a reasonable default. MX records also require a priority number.

Making Changes Safely

Before making DNS changes, document your current records so you can restore them if something goes wrong. Make sure you understand what you're changing and why - DNS mistakes can make your entire site or email unreachable.

If you're planning a major change, consider lowering the TTL a day or two in advance. With a lower TTL, any mistakes will propagate out of caches faster, making recovery quicker. After confirming everything works, you can raise the TTL again.

Verifying Your Changes

After making changes, you'll need to wait for the old TTL to expire before the new records are visible everywhere. You can verify your changes using the dig command:

# Check A record
dig example.com A

# Check MX records
dig example.com MX

# Check TXT records
dig example.com TXT

Online DNS checkers can also show you how your records appear from different locations around the world, which is useful for confirming global propagation.

DNS Records Best Practices

Documentation might seem tedious, but keeping a record of what each DNS entry does and why it exists will save you hours of confusion later. When you're staring at a TXT record with a cryptic string six months from now, you'll be grateful for past-you's notes.

Choose your TTLs thoughtfully. One hour (3600 seconds) works well for most records, balancing quick updates against DNS server load. Before planned changes, temporarily lower TTLs to speed up propagation. For records that rarely change, higher TTLs reduce query volume.

Email authentication deserves special attention. Configure SPF, DKIM, and DMARC records properly to prevent your domain from being spoofed in phishing attacks. These records also improve your legitimate email deliverability by proving to recipients that your emails are authentic.

Monitor your DNS records for unauthorized changes. DNS hijacking - where an attacker modifies your records to redirect traffic - is one of the most dangerous attacks because it's nearly invisible. Regular monitoring catches these changes before they cause serious damage.

Finally, audit your DNS periodically and remove records you no longer need. Old records pointing to servers you no longer control are security risks. That staging server you decommissioned months ago? If its A record still exists and someone else gets that IP address, they could serve content that appears to come from your domain.

Common DNS Mistakes to Avoid

The trailing dot catches many people off guard. In some DNS interfaces, example.com and example.com. (with a trailing dot) mean different things. The dot makes the domain name absolute (fully qualified). Without it, some systems append the zone's domain, potentially creating records like example.com.example.com. When in doubt, check your provider's documentation.

Trying to use a CNAME at the apex domain is another frequent mistake. Standard DNS doesn't allow this because CNAMEs can't coexist with other record types, and the apex needs NS and SOA records. If your DNS provider offers ALIAS or ANAME records, use those instead, or simply use an A record pointing directly to the IP address.

Forgetting backup MX records means a mail server outage takes down all your email. Adding secondary MX records with higher priority numbers ensures email keeps flowing even when your primary server has problems.

Impatience with propagation leads to unnecessary panic. DNS changes can take time to spread across the internet's caching resolvers. If your change isn't visible immediately, wait for the old record's TTL to expire before assuming something is wrong.

Chaining CNAMEs (pointing one CNAME to another CNAME) works technically but adds latency and complexity. Each hop requires an additional DNS lookup. Point CNAMEs directly to their final destination whenever possible.

When moving DNS to a new provider, people often forget to recreate their email records. Your website might work perfectly while your email silently breaks. Before changing NS records, verify that MX, SPF, DKIM, and DMARC records are all configured at the new provider.

How SecurityBot Helps with DNS

SecurityBot monitors your DNS records and alerts you to changes that could indicate problems or attacks. You'll get notifications when any DNS record is modified, along with comparison reports showing exactly what changed. This helps catch both unauthorized modifications and accidental misconfigurations.

DNS hijacking is particularly insidious because it can redirect all your traffic silently. Visitors think they're on your site, but they're actually on an attacker's server. Continuous monitoring catches these changes before they cause serious damage.

Start your free 14-day trial - DNS monitoring included with all plans.

Frequently Asked Questions

How long do DNS changes take to propagate?

The propagation time depends on the TTL of the old record. If the TTL was 3600 seconds (one hour), most resolvers will have the new record within an hour. However, some resolvers don't strictly honor TTLs, so allow up to 48 hours for complete global propagation. In practice, most changes are visible within a few hours.

Can I have multiple A records for the same domain?

Yes, and this is a common technique called round-robin DNS. When multiple A records exist for the same name, DNS returns all of them, and clients typically use the first one or rotate through the list. This provides basic load distribution across multiple servers, though it's not a replacement for a proper load balancer.

What's the difference between CNAME and A records?

A records point directly to IP addresses, creating a fixed mapping between a domain and a server. CNAME records point to other domain names, creating an alias that follows wherever that target domain points. Use A records when you know and control the server's IP address. Use CNAMEs when you want to follow another domain's configuration, which is especially useful for third-party services.

Why does my email go to spam?

Missing or misconfigured SPF, DKIM, and DMARC records are among the most common causes. These TXT records authenticate your email and prove it's legitimately from your domain. Without them, receiving mail servers have no way to distinguish your real emails from spoofed ones, so they err on the side of caution and mark messages as suspicious. Check that all three are properly configured and that the servers you send from are included in your SPF record.

Should I use my registrar's DNS or a third-party provider?

Third-party DNS providers like Cloudflare or Route 53 typically offer better performance through globally distributed servers, more features like DNSSEC and advanced traffic routing, and sometimes better security. However, using your registrar's DNS is simpler since everything is in one place. If you don't need advanced features and your registrar's DNS works reliably, there's nothing wrong with keeping things simple.

Last updated: January 2026 | Written by Jason Gilmore, Founder of SecurityBot