← Back to blog
dns-checker

DNS Records Explained for Developers

A developer's guide to DNS record types: A, AAAA, CNAME, MX, TXT, NS, and SOA. Includes dig commands, real-world examples, and email authentication setup.

dnsnetworkingdevopsemaildeveloper-tools

DNS Records Explained



You need to add a CNAME for your CDN, a TXT record for domain verification, and an MX record for email — and the DNS provider's UI shows a dozen record types with no explanation of which one to use when. DNS records are the backbone of how the internet routes traffic, delivers email, and verifies domain ownership. Yet most developers interact with them only when something breaks. This guide explains every DNS record type you will encounter in production, with real dig commands to inspect them and concrete examples of when each type is the right choice.

A Record: IPv4 Address Mapping



The A record maps a domain name to an IPv4 address. It is the most fundamental DNS record.

dig luxkern.com A +short


Output: 198.51.100.75

When to use A records



  • Pointing your root domain (luxkern.com) to a server IP.
  • Pointing subdomains (api.luxkern.com) to specific server IPs.
  • When your hosting provider gives you an IP address, not a hostname.


    • Real-world example



    luxkern.com.        3600    IN    A    198.51.100.75
api.luxkern.com.    300     IN    A    198.51.100.76
staging.luxkern.com. 60     IN    A    10.0.1.50


    The root domain has a high TTL (1 hour) because it rarely changes. The staging subdomain has a low TTL (60 seconds) for quick changes during development.

    Inspecting A records in detail



    dig luxkern.com A +noall +answer +comments


    Output:

    ;; ANSWER SECTION:
luxkern.com.        3600    IN    A    198.51.100.75


    The columns are: domain name, TTL (seconds), class (IN = Internet), record type, and value.

    AAAA Record: IPv6 Address Mapping



    The AAAA record (pronounced "quad-A") is the IPv6 equivalent of the A record.

    dig luxkern.com AAAA +short


    Output: 2001:db8::1

    When to use AAAA records



  • When your server has an IPv6 address (and it should — IPv4 addresses are running out).
  • Alongside A records for dual-stack connectivity. Clients that support IPv6 will use the AAAA record; others fall back to A.


    • Real-world example



    luxkern.com.    3600    IN    A       198.51.100.75
luxkern.com.    3600    IN    AAAA    2001:db8::1


    Most cloud providers and CDNs provide both IPv4 and IPv6 addresses. Always configure both.

    CNAME Record: Canonical Name (Alias)



    A CNAME maps one domain name to another domain name. It is an alias.

    dig www.luxkern.com CNAME +short


    Output: luxkern.com.

    The resolver then looks up the A/AAAA record for luxkern.com to get the final IP.

    When to use CNAME records



  • Pointing www to the root domain.
  • Pointing subdomains to external services (CDNs, SaaS platforms, load balancers).
  • When the target IP might change and you do not control it.


    • Real-world examples



    # www redirects to root
www.luxkern.com.         3600    IN    CNAME    luxkern.com.

    CDN distribution
    
cdn.luxkern.com.         3600    IN    CNAME    d1234abcd.cloudfront.net.

    SaaS platform custom domain
    
docs.luxkern.com.        3600    IN    CNAME    custom.gitbook.com.

    Heroku app
    
app.luxkern.com.         300     IN    CNAME    sharp-rain-123.herokuapp.com.


    CNAME restrictions



    You cannot place a CNAME at the zone apex (root domain). This is invalid:

    # WRONG — violates DNS specification
luxkern.com.    3600    IN    CNAME    something.else.com.


    The root domain must have A/AAAA records (or use provider-specific workarounds like Cloudflare's CNAME flattening or Route 53's ALIAS record).

    A CNAME cannot coexist with other records for the same name. If cdn.luxkern.com has a CNAME, it cannot also have an A, MX, or TXT record.

    Inspecting CNAME chains



    dig www.luxkern.com +trace +nodnssec


    This shows the full resolution chain: root servers, TLD servers, authoritative servers, CNAME resolution, and the final A record.

    MX Record: Mail Exchange



    MX records tell email servers where to deliver mail for your domain.

    dig luxkern.com MX +short


    Output:

    10 mail1.luxkern.com.
20 mail2.luxkern.com.


    The number is the priority — lower values are tried first. If mail1 is unreachable, email is delivered to mail2.

    When to use MX records



  • Always. Every domain that receives email needs MX records.
  • When using a third-party email service (Google Workspace, Microsoft 365, Fastmail).


    • Real-world examples



    # Google Workspace
luxkern.com.    3600    IN    MX    1  ASPMX.L.GOOGLE.COM.
luxkern.com.    3600    IN    MX    5  ALT1.ASPMX.L.GOOGLE.COM.
luxkern.com.    3600    IN    MX    5  ALT2.ASPMX.L.GOOGLE.COM.
luxkern.com.    3600    IN    MX    10 ALT3.ASPMX.L.GOOGLE.COM.
luxkern.com.    3600    IN    MX    10 ALT4.ASPMX.L.GOOGLE.COM.

    Microsoft 365
    
luxkern.com.    3600    IN    MX    0  luxkern-com.mail.protection.outlook.com.

    Fastmail
    
luxkern.com.    3600    IN    MX    10 in1-smtp.messagingengine.com.
luxkern.com.    3600    IN    MX    20 in2-smtp.messagingengine.com.


    Diagnosing email delivery issues



    # Check MX records
dig luxkern.com MX +short

    Verify the MX host resolves to an IP
    
dig ASPMX.L.GOOGLE.COM A +short

    Test SMTP connectivity to the MX host
    
openssl s_client -connect ASPMX.L.GOOGLE.COM:25 -starttls smtp


    If the MX host does not resolve or port 25 is unreachable, email delivery fails silently — senders get a bounce hours later.

    TXT Record: Text Data



    TXT records store arbitrary text. They are used for domain verification, email authentication, and service configuration.

    dig luxkern.com TXT +short


    Output:

    "v=spf1 include:_spf.google.com ~all"
"google-site-verification=abc123..."
"v=DMARC1; p=reject; rua=mailto:dmarc@luxkern.com"


    SPF (Sender Policy Framework)



    SPF tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain.

    luxkern.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ~all"


    Breaking it down:

  • v=spf1 — this is an SPF record.
  • include:_spf.google.com — Google Workspace is authorized.
  • include:sendgrid.net — SendGrid is authorized (for transactional email).
  • ~all — soft-fail for all other senders (mark as spam, do not reject outright). Use -all for strict enforcement.


    • DKIM (DomainKeys Identified Mail)



    DKIM uses a public key in DNS to verify that emails were not tampered with in transit.

    dig google._domainkey.luxkern.com TXT +short


    Output:

    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."


    The selector (google in this case) is provider-specific. Google Workspace uses google, SendGrid uses s1 and s2, etc.

    DMARC (Domain-based Message Authentication, Reporting, and Conformance)



    DMARC ties SPF and DKIM together and tells receivers what to do when authentication fails.

    _dmarc.luxkern.com.    3600    IN    TXT    "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@luxkern.com; ruf=mailto:dmarc-forensic@luxkern.com; adkim=s; aspf=s"


  • p=reject — reject emails that fail both SPF and DKIM.
  • sp=reject — same policy for subdomains.
  • rua — aggregate reports (daily XML summaries).
  • ruf — forensic reports (individual failure details).
  • adkim=s — strict DKIM alignment (domain must match exactly).
  • aspf=s — strict SPF alignment.


    • Domain verification TXT records



    luxkern.com.    3600    IN    TXT    "google-site-verification=abc123def456..."
luxkern.com.    3600    IN    TXT    "stripe-verification=sv_test_abc123..."
luxkern.com.    3600    IN    TXT    "atlassian-domain-verification=abc123..."


    Services like Google Search Console, Stripe, and Atlassian use TXT records to verify domain ownership. Add the record, wait for propagation, and click "Verify" in the service's dashboard.

    Checking all TXT records



    dig luxkern.com TXT +noall +answer


    This shows every TXT record with its TTL — useful when you have multiple and need to identify which belongs to which service.

    NS Record: Nameserver Delegation



    NS records define which nameservers are authoritative for a domain.

    dig luxkern.com NS +short


    Output:

    ns1.cloudflare.com.
ns2.cloudflare.com.


    When you interact with NS records



  • At the registrar: You set NS records to point to your DNS provider (Cloudflare, Route 53, etc.). This is delegation — the registrar tells the world "ask Cloudflare for records about luxkern.com."
  • For subdomain delegation: You can delegate a subdomain to a different DNS provider.


    • # Delegate the staging subdomain to a different nameserver
staging.luxkern.com.    86400    IN    NS    ns1.staging-dns.example.com.
staging.luxkern.com.    86400    IN    NS    ns2.staging-dns.example.com.


    Debugging NS issues



    # Check what the TLD servers think your nameservers are
dig luxkern.com NS @a.gtld-servers.net +short

    Check what your nameservers actually serve
    
dig @ns1.cloudflare.com luxkern.com A +short


    If the TLD servers point to nameservers that do not serve your records, your domain is broken. This usually means the registrar has the wrong NS records.

    SOA Record: Start of Authority



    The SOA record contains administrative information about the zone.

    dig luxkern.com SOA +short


    Output:

    ns1.cloudflare.com. dns.cloudflare.com. 2026040701 10000 2400 604800 1800


    Fields:

  • ns1.cloudflare.com. — primary nameserver.
  • dns.cloudflare.com. — contact email (the first . is actually @, so this is dns@cloudflare.com).
  • 2026040701 — serial number (increments with each change).
  • 10000 — refresh interval (seconds).
  • 2400 — retry interval.
  • 604800 — expire time.
  • 1800 — minimum TTL (used for negative caching — "this record does not exist" is cached for this long).


    • When SOA matters



    The negative cache TTL (last field) affects how long resolvers cache "NXDOMAIN" (domain not found) responses. If you create a new subdomain and it does not resolve immediately, the negative cache TTL is why — resolvers recently looked up the subdomain, got NXDOMAIN, and cached that result.

    Less Common Record Types



    SRV Record: Service Location



    dig _sip._tcp.luxkern.com SRV +short


    Output: 10 60 5060 sip.luxkern.com.

    Fields: priority, weight, port, target. Used by SIP (VoIP), XMPP, and some Microsoft services.

    CAA Record: Certificate Authority Authorization



    dig luxkern.com CAA +short


    Output:

    0 issue "letsencrypt.org"
0 issuewild "letsencrypt.org"
0 iodef "mailto:security@luxkern.com"


    CAA records restrict which CAs can issue certificates for your domain. This prevents unauthorized certificate issuance.

    PTR Record: Reverse DNS



    dig -x 198.51.100.75 +short


    Output: luxkern.com.

    PTR records map IP addresses back to domain names. They are critical for email deliverability — many mail servers reject messages from IPs without valid reverse DNS.

    Practical Workflows



    Setting up email for a new domain



  • Add MX records pointing to your email provider.
  • Add SPF TXT record authorizing the provider.
  • Add DKIM TXT record with the provider's public key.
  • Add DMARC TXT record starting with p=none (monitoring mode).
  • Send test emails and check DMARC reports.
  • Tighten DMARC to p=quarantine then p=reject after confirming legitimate mail passes.


    • # Verify all email records are in place
echo "=== MX ===" && dig luxkern.com MX +short
echo "=== SPF ===" && dig luxkern.com TXT +short | grep spf
echo "=== DKIM ===" && dig google._domainkey.luxkern.com TXT +short
echo "=== DMARC ===" && dig _dmarc.luxkern.com TXT +short


    Connecting a custom domain to a SaaS platform



    Most SaaS platforms require a CNAME and a verification TXT record:

    # CNAME for routing
docs.luxkern.com.    3600    IN    CNAME    custom.gitbook.com.

    TXT for verification
    
docs.luxkern.com.    3600    IN    TXT    "gitbook-verification=abc123"


    Wait for propagation, then verify in the platform's dashboard. Use the propagation checking techniques from how to check DNS propagation to know when the records are live.

    Debugging "site not loading after DNS change"



    # Step 1: What does your resolver say?
dig yourdomain.com A +short

    Step 2: What does the authoritative nameserver say?
    
dig yourdomain.com NS +short
dig @ns1.your-dns-provider.com yourdomain.com A +short

    Step 3: Is it a propagation issue?
    
dig @8.8.8.8 yourdomain.com A +short
dig @1.1.1.1 yourdomain.com A +short

    Step 4: Is the server actually responding?
    
curl -sI http://$(dig +short yourdomain.com A | head -1)


    If step 2 shows the correct IP but steps 3-4 do not, it is a propagation issue. Wait for TTL expiry. If step 2 shows the wrong IP, the DNS change was not saved properly.

    DNS Security Best Practices



  • Enable DNSSEC if your registrar and DNS provider support it. DNSSEC cryptographically signs DNS responses, preventing DNS spoofing.
  • Set CAA records to restrict which CAs can issue certificates for your domain.
  • Use strict DMARC (p=reject) after monitoring shows all legitimate email passes SPF/DKIM.
  • Monitor DNS changes — unauthorized changes to your DNS records can redirect traffic to malicious servers.
  • Keep TTLs reasonable — extremely low TTLs increase DNS query volume and make you dependent on your DNS provider's availability.


    • Use Luxkern DNS Tools



    The Luxkern DNS Checker lets you look up any record type for any domain across global resolvers. For SSL-related DNS records (CAA, TXT for certificate verification), pair it with the SSL certificate expiry checker.

    Try DNS Checker free — no credit card required.

    For ongoing monitoring of your DNS records, uptime, and SSL certificates, PingCheck alerts you when anything changes or goes down.

    Try PingCheck free — no credit card required.