DNS Record Lookup & Generator

You’re setting up email for a new domain and need SPF, DKIM, and DMARC TXT records — plus MX records pointing to your email provider, a CAA record for your SSL certificate authority, and an SRV record for a SIP service. That’s 6+ record types with different syntaxes, and getting the SPF include: chain wrong means your emails land in spam. You need a builder, not a text editor.

Why This Tool (Not the DNS Lookup Tool)

PureDevTools has a DNS Lookup Tool for querying existing DNS records via Cloudflare’s DoH API. This tool is for building — create A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, CAA, and PTR records visually, with built-in SPF/DKIM/DMARC email configuration presets, and export the complete zone file. Everything runs in your browser; no data is sent anywhere.

What Are DNS Records?

DNS (Domain Name System) records are instructions stored in a DNS zone that tell the internet how to handle traffic for a domain. Every time someone visits your website, sends you an email, or connects to your service, DNS records are consulted to route the request to the right destination.

DNS records live in a zone file — a structured text file that defines all the records for a domain. This tool helps you build, validate, and export those records without needing to remember the exact syntax.

DNS Record Types Explained

A Record — IPv4 Address

The most fundamental record type. Maps a hostname to an IPv4 address.

example.com.  3600  IN  A  203.0.113.1
www           3600  IN  A  203.0.113.1
api           3600  IN  A  203.0.113.42

Multiple A records for the same name enable round-robin load balancing — the DNS resolver rotates through the IPs on each query.

AAAA Record — IPv6 Address

The IPv6 equivalent of an A record. Modern best practice is to publish both A and AAAA for dual-stack support.

example.com.  3600  IN  AAAA  2001:db8::1

CNAME Record — Canonical Name (Alias)

Creates an alias from one name to another. The resolver follows the chain until it finds an A or AAAA record.

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

CNAME restrictions:

• Cannot be used at the zone apex (root domain) — use A/AAAA instead
• Cannot coexist with other record types at the same name
• Always include the trailing dot (.) to prevent relative resolution

MX Record — Mail Exchange

Specifies which mail servers receive email for your domain. The priority (lower = preferred) controls failover order.

example.com.  3600  IN  MX  10 mail.example.com.
example.com.  3600  IN  MX  20 backup-mail.example.com.

Without MX records, email to your domain will fail to deliver.

TXT Record — Text

Stores arbitrary text for machine-readable purposes. The three most important uses:

NS Record — Name Server

Identifies the authoritative name servers for a zone. Every zone must have at least two NS records for redundancy.

example.com.  86400  IN  NS  ns1.example.com.
example.com.  86400  IN  NS  ns2.example.com.

NS records are set at both your zone file and your domain registrar (delegation).

SOA Record — Start of Authority

The first record in every zone file. Contains administrative metadata and timing parameters for zone transfers.

example.com.  IN  SOA  ns1.example.com. hostmaster.example.com. (
    2024010101  ; Serial
    3600        ; Refresh
    900         ; Retry
    604800      ; Expire
    300 )       ; Minimum TTL

Serial number convention: YYYYMMDDNN — increment on every zone change so secondary name servers detect the update.

SRV Record — Service Location

Enables clients to discover services without hardcoded ports. Used by SIP (VoIP), XMPP, CalDAV, LDAP, Minecraft, and others.

_sip._tcp.example.com.  3600  IN  SRV  10 20 5060 sip.example.com.
;                                       ▲  ▲  ▲    ▲
;                                 priority weight port target

CAA Record — Certification Authority Authorization

Restricts which Certificate Authorities can issue TLS/SSL certificates for your domain. Prevents unauthorized certificate issuance.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild ";"

PTR Record — Reverse DNS

Maps an IP address back to a hostname. Required by many mail servers for spam prevention.

1.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.example.com.

PTR records are managed by your IP address provider (ISP, cloud provider), not your domain registrar.

Email Authentication Records (SPF, DKIM, DMARC)

Proper email authentication requires three layered records working together:

SPF — Sender Policy Framework

Specifies which mail servers are authorized to send email on behalf of your domain. Published as a TXT record at your root domain.

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

Mechanism guide:

• include:domain — authorize servers from another domain’s SPF record
• a — authorize your A record IP(s)
• mx — authorize your MX server IP(s)
• ip4:x.x.x.x/cidr — authorize a specific IPv4 address or range
• ~all (softfail) — mark unlisted sources as suspicious (recommended during rollout)
• -all (hardfail) — reject unlisted sources (use after full SPF deployment)

SPF limit: A maximum of 10 DNS lookups are allowed during SPF evaluation. Exceeding this causes a permerror.

DKIM — DomainKeys Identified Mail

Adds a cryptographic signature to outgoing email. The receiving server looks up your public key in DNS to verify the signature wasn’t forged or tampered with.

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The selector (default in the example) lets you rotate keys — add a new selector, update your email server, then remove the old one without downtime.

DMARC — Domain-based Message Authentication, Reporting & Conformance

The policy layer that tells receiving servers what to do when SPF or DKIM fails, and where to send aggregate reports.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Deployment sequence:

1. p=none — monitor mode: collect reports, no action (start here)
2. p=quarantine — move failing mail to spam folder
3. p=reject — reject failing mail at SMTP level

DMARC reports show you which servers are sending email claiming to be from your domain — essential for detecting phishing and spoofing.

TTL Recommendations

TTL (Time to Live) controls how long DNS resolvers cache a record. Lower TTLs mean faster change propagation but more DNS queries.

Migration tip: Lower your TTL to 300s at least 1 hour before making a DNS change. After the change, raise it back to 3600s once you confirm everything works.

Understanding the Zone File Format

A DNS zone file uses a specific column layout:

; This is a comment
$ORIGIN example.com.
$TTL 3600

; Format: <name> <ttl> IN <type> <data>
@    IN  SOA  ns1 hostmaster (2024010101 3600 900 604800 300)
@    IN  NS   ns1.example.com.
@    IN  NS   ns2.example.com.
@    IN  A    203.0.113.1
www  IN  CNAME @

Key syntax rules:

• @ represents the zone origin (the domain itself)
• A trailing dot (.) indicates a fully qualified domain name (FQDN)
• Without a trailing dot, the zone origin is appended
• IN is the record class (Internet) — always IN for public DNS
• $TTL sets the default TTL for all records that don’t specify one
• $ORIGIN sets the domain suffix appended to relative names

Frequently Asked Questions

How long does DNS propagation take? DNS changes typically propagate within 1–24 hours, depending on the record’s TTL and your DNS provider’s update frequency. With a 300s TTL, most resolvers will pick up changes within 5–10 minutes. With a 86400s TTL, it can take up to 48 hours.

Why can’t I use a CNAME for my root domain? The DNS standard (RFC 1034) prohibits CNAME records at the zone apex because a CNAME must be the only record at its name, but the root domain also needs NS and SOA records. Many DNS providers offer proprietary solutions (ALIAS, ANAME, CNAME flattening) that behave like CNAMEs at the root while being technically A/AAAA records.

Do I need both SPF and DKIM? DMARC requires at least one of SPF or DKIM to pass. However, best practice is to implement both — they protect against different attack vectors. SPF validates the sending server; DKIM validates message integrity.

What is PTR record and why does it matter for email? PTR records (reverse DNS) map an IP address back to a hostname. Many mail servers check PTR records as part of spam filtering — if your mail server’s IP doesn’t have a PTR record pointing to your mail server’s hostname, your emails may be rejected or marked as spam.

Can I have multiple TXT records at the same name? Yes — multiple TXT records at the same name are allowed. DNS will return all of them. This is commonly used to have both an SPF record and a site verification record at the root domain simultaneously.

Is my data sent to a server? No. All record generation, validation, and zone file export happens entirely in your browser using JavaScript. Nothing is sent to any server, stored, or logged.