Skip to main content

DNS Record Explainer — 18 Record Types With Syntax, Examples and Real Gotchas

DNS record explainer — all 18 common record types (A, AAAA, CNAME, MX, TXT, SRV, etc.) with syntax, examples, and gotchas.

  • Runs locally
  • Category Developer & DevOps
  • Best for Formatting, validating, shrinking, or inspecting code-adjacent text.
18 types
Core records (9)
A
RFC 1035
Syntax
<name> <ttl> IN A <ipv4-address>
What it does

Maps a hostname to a single IPv4 address. The most basic record on the internet — every domain that serves traffic over IPv4 has at least one A record at the apex or a subdomain.

When to use
  • Point example.com to your web server: 203.0.113.10.
  • Round-robin load balancing by putting multiple A records on the same name.
  • Geo / latency routing where the resolver picks the closest A from the set.
Common gotchas
  • TTL too long (e.g. 86400) means a server move takes a full day to roll out — drop to 300 a day before migration.
  • Adding a second A record does NOT make it failover — it just round-robins. Real failover needs health-checked DNS (Route53, NS1).
  • A record at the apex is fine, but you cannot also have a CNAME at the apex — they conflict.
Examples
example.com.     300  IN A     203.0.113.10
www.example.com. 300  IN A     203.0.113.10
api.example.com. 60   IN A     198.51.100.5
AAAA
RFC 3596
Syntax
<name> <ttl> IN AAAA <ipv6-address>
What it does

Maps a hostname to a single IPv6 address. The IPv6 sibling of A — required for dual-stack hosts and any service that wants to be reachable from IPv6-only networks (mobile carriers, university campuses).

When to use
  • Dual-stack web server: an A and an AAAA on the same name.
  • CDN edge: Cloudflare/Fastly give you AAAA for free.
  • IPv6-only API endpoint for mobile clients on a NAT64 carrier.
Common gotchas
  • Server listens on IPv6 but firewall drops it — clients silently time out instead of falling back to IPv4 quickly (Happy Eyeballs hides the bug for a while).
  • Reverse DNS for AAAA is on ip6.arpa, not in-addr.arpa — easy to forget when setting up PTR.
  • Some old corporate proxies still strip AAAA from responses — test from outside the office.
Examples
example.com.     300  IN AAAA  2001:db8::1
www.example.com. 300  IN AAAA  2606:4700::6810:84e5
api.example.com. 60   IN AAAA  2001:db8:1::a
CNAME
RFC 1035
Syntax
<alias> <ttl> IN CNAME <canonical-name>
What it does

Aliases one name to another canonical name. The resolver follows the chain to find the final A/AAAA records. Use it to point subdomains at SaaS endpoints without hardcoding their IP.

When to use
  • shop.example.com → mystore.shopify.com (Shopify changes IPs, you do not care).
  • docs.example.com → example.gitbook.io
  • cdn.example.com → d1234abcd.cloudfront.net
Common gotchas
  • You cannot put a CNAME at the zone apex (example.com itself) — it conflicts with the mandatory SOA/NS records. Use ALIAS/ANAME or a flattening provider instead.
  • A name with a CNAME cannot have any other record (no MX, no TXT, nothing). Want both? Move the service to a subdomain.
  • CNAME chains slow down resolution and break some validators — keep it to one hop.
  • CNAME loses the original Host header semantics for some apps — be sure the target accepts your hostname.
Examples
www.example.com.  300 IN CNAME example.com.
shop.example.com. 300 IN CNAME mystore.shopify.com.
docs.example.com. 300 IN CNAME example.gitbook.io.
NS
RFC 1035
Syntax
<zone> <ttl> IN NS <nameserver>
What it does

Declares which name servers are authoritative for a zone or subzone. Required at the apex of every zone, and used to delegate subzones to a different provider.

When to use
  • Apex NS records at example.com pointing to ns1/ns2/ns3/ns4.cloudflare.com.
  • Delegate dev.example.com to a separate Route53 zone for the dev team.
  • GeoDNS by delegating asia.example.com to a regional provider.
Common gotchas
  • Glue records (A/AAAA at the registrar for ns1.example.com when the nameserver is inside the same zone) are easy to forget and cause "lame delegation".
  • NS records at the registrar (parent) must match the NS records inside the zone — mismatch causes intermittent resolution.
  • Removing all NS records during a migration kills resolution for the full TTL period.
  • Subdomain NS delegation only works if the subdomain itself has no other records at its apex on the parent zone.
Examples
example.com. 86400 IN NS ns1.cloudflare.com.
example.com. 86400 IN NS ns2.cloudflare.com.
dev.example.com. 86400 IN NS ns-1234.awsdns-25.org.
SOA
RFC 1035 / RFC 2308
Syntax
<zone> <ttl> IN SOA <primary-ns> <admin-email> ( <serial> <refresh> <retry> <expire> <minimum> )
What it does

Start Of Authority — exactly one per zone, declares the primary name server, admin email, and timers that secondary servers use to sync. The serial number is the change marker zones use to trigger zone transfers.

When to use
  • Bumping the serial after editing a zone so secondaries pull the new data.
  • Tuning minimum TTL for negative caching (how long a NXDOMAIN is remembered).
  • Hidden-master setup: SOA points to a hidden primary, secondaries serve traffic.
Common gotchas
  • Forgetting to bump the serial after a change means secondaries never sync.
  • Admin email uses a dot in place of @ (hostmaster.example.com.) — easy to mistype.
  • Setting minimum TTL too high makes deletions cache for that long (negative cache).
  • Two SOA records in a zone is a hard error — provider GUIs prevent it, manual zone files do not.
Examples
example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
              2026052601 ; serial (YYYYMMDDnn)
              7200 3600 1209600 3600 )
PTR
RFC 1035
Syntax
<reverse-name>.in-addr.arpa. <ttl> IN PTR <hostname>
What it does

Reverse DNS — maps an IP address back to a hostname. Used by mail servers to sanity-check sender IPs, by logs to display readable hostnames, and by SSH for the resolveclient option.

When to use
  • Outbound SMTP servers MUST have a matching forward and reverse for mail to be accepted by most providers.
  • Log analysis: nginx access logs show hostnames instead of bare IPs.
  • rDNS in traceroute output makes hop diagnosis easier.
Common gotchas
  • You usually do NOT control PTR — your ISP / cloud provider does. AWS lets you set it via the EC2 console, Azure via the portal.
  • PTR is set in the in-addr.arpa zone for IPv4 and ip6.arpa for IPv6 — never in your forward zone.
  • Mismatched forward/reverse (FCrDNS fails) and your mail goes to spam regardless of SPF/DKIM/DMARC.
  • Cloud images often get a default PTR like ec2-203-0-113-10.compute-1.amazonaws.com — must override for production mail.
Examples
10.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR mail.example.com.
SRV
RFC 2782
Syntax
_service._proto.<name> <ttl> IN SRV <priority> <weight> <port> <target>
What it does

Service location record — lets a client discover the host AND port for a named service (LDAP, XMPP, SIP, Minecraft, Matrix). Encodes priority and weight for load balancing in DNS.

When to use
  • XMPP: _xmpp-client._tcp.example.com → SRV → talk.example.com:5222
  • Active Directory uses SRV for domain controller discovery (_ldap._tcp).
  • Minecraft hosts SRV so players type the bare domain instead of domain:25565.
Common gotchas
  • Service name MUST start with an underscore (_sip not sip) — clients ignore it otherwise.
  • Target must be a hostname with A/AAAA records — never an IP, never a CNAME.
  • HTTP/HTTPS clients (browsers) do NOT consult SRV — only specific protocols do. Do not put your web on SRV.
  • Weight 0 means "use only if nothing else available" — easy to misread as default.
Examples
_xmpp-client._tcp.example.com. 3600 IN SRV 10 5 5222 talk.example.com.
_sip._tls.example.com.         3600 IN SRV 10 60 5061 sipgw1.example.com.
_minecraft._tcp.play.example.com. 3600 IN SRV 0 5 25565 mc1.example.com.
ALIAS
Syntax
<apex> <ttl> IN ALIAS <target>
What it does

Provider-specific record (DNSimple, Namecheap, others) — flattens a target hostname at the zone apex by resolving the target server-side and returning the result as A/AAAA. Lets you point example.com at a SaaS CNAME-like target where a CNAME at the apex would be illegal.

When to use
  • example.com → mystore.myshopify.com without breaking MX/TXT at the apex.
  • example.com → d12345.cloudfront.net for a static site on CloudFront.
  • example.com → app.netlify.com when hosting the apex on Netlify.
Common gotchas
  • Not in any RFC — only works on providers that implement it. Migrating DNS providers may force a rebuild.
  • TTL caching is whatever your DNS provider chooses, not the target — surprise stale results during target IP changes.
  • Some providers charge per query because the resolution happens server-side.
  • If the target itself moves IPs, you depend on your DNS provider re-resolving frequently.
Examples
example.com. 60 IN ALIAS mystore.myshopify.com.
example.com. 60 IN ALIAS d12345.cloudfront.net.
example.com. 60 IN ALIAS app.netlify.com.
ANAME
Syntax
<apex> <ttl> IN ANAME <target>
What it does

Another vendor-specific apex-flattening record (DNS Made Easy, easyDNS), functionally equivalent to ALIAS. Resolves the target server-side and returns A/AAAA at the apex.

When to use
  • Apex apex → ELB / ALB target without breaking apex MX.
  • Apex → Heroku herokudns.com endpoint.
  • Apex → custom CDN host that only exposes a hostname.
Common gotchas
  • Same as ALIAS — non-standard, provider lock-in.
  • Some providers expose ANAME via the UI but encode it as periodic A flattening underneath — check TTL behaviour.
  • Slow resolver-side resolution adds latency when the target is far from the DNS provider.
Examples
example.com. 60 IN ANAME myapp.herokudns.com.
example.com. 60 IN ANAME lb-1234.us-east-1.elb.amazonaws.com.
example.com. 60 IN ANAME cdn.example-provider.net.
Mail records (5)
MX
RFC 1035 / RFC 7505
Syntax
<name> <ttl> IN MX <priority> <mail-server>
What it does

Lists the mail servers that accept email for the domain, ordered by priority (lower number wins). Without an MX, mail for the domain has no defined destination.

When to use
  • Point @example.com email to Google Workspace.
  • Multi-provider failover: primary Microsoft 365 + secondary Mailgun spool.
  • Null MX (priority 0, ".") to declare a domain does NOT accept email.
Common gotchas
  • MX target must be a hostname with an A/AAAA — never an IP literal, never a CNAME (RFC says SHOULD NOT, many providers say MUST NOT).
  • Forgetting to set up SPF/DKIM/DMARC after MX means your outbound goes straight to spam.
  • Two MX records with the same priority means clients pick randomly — that is the intent for load balancing, not a bug.
  • Setting MX without removing the old provider creates a split-brain that loses mail.
Examples
example.com. 3600 IN MX 1  aspmx.l.google.com.
example.com. 3600 IN MX 5  alt1.aspmx.l.google.com.
example.com. 3600 IN MX 0  .                      ; Null MX, no mail
TXT
RFC 1035 / RFC 7208
Syntax
<name> <ttl> IN TXT "<text>"
What it does

Holds arbitrary text — historically free-form notes, now mostly machine-readable policies: SPF, DKIM, DMARC, domain ownership verification, BIMI selectors.

When to use
  • Domain verification for Google Workspace / Microsoft 365 / Cloudflare.
  • SPF policy: v=spf1 include:_spf.google.com ~all
  • BIMI logo selector for branded inbox icons.
Common gotchas
  • A single TXT string is capped at 255 chars — long DKIM keys must be split into multiple quoted strings on the same record (the resolver joins them).
  • Multiple SPF records on the same name is INVALID — collapse into one with includes.
  • TXT lookups are limited to 10 DNS queries — too many SPF includes will fail validation.
  • Removing the verification TXT after setup breaks the provider re-check months later — keep it.
Examples
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 3600 IN TXT "google-site-verification=abcdef123456"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
DKIM
RFC 6376
Syntax
<selector>._domainkey.<name> <ttl> IN TXT "v=DKIM1; k=rsa; p=<base64-public-key>"
What it does

DomainKeys Identified Mail — the public key for verifying email signatures. Lives as a TXT record at <selector>._domainkey.<domain>. Receiving servers fetch it to verify the DKIM-Signature header on incoming mail.

When to use
  • Google Workspace gives you a 2048-bit key and a selector like google._domainkey.
  • SendGrid / Mailgun give per-customer selectors (s1._domainkey, s2._domainkey).
  • Key rotation by adding a new selector before retiring the old one.
Common gotchas
  • 2048-bit keys exceed the 255-char TXT limit — split into multiple quoted segments on the same record (resolver concatenates).
  • Trailing whitespace or line breaks inside the TXT value break verification — copy-paste carefully.
  • Multiple DKIM records under one selector breaks signing — one selector, one key.
  • Rotating without overlap means messages signed by the old key fail verification — keep both for at least one TTL period.
Examples
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
s1._domainkey.example.com.     3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
mg._domainkey.mg.example.com.  3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
DMARC
RFC 7489
Syntax
_dmarc.<name> <ttl> IN TXT "v=DMARC1; p=<policy>; rua=mailto:<reports>"
What it does

Domain-based Message Authentication, Reporting & Conformance — tells receivers what to do when SPF or DKIM fails (none / quarantine / reject) and where to send aggregate reports.

When to use
  • Start in monitor mode: p=none + rua= to collect data without affecting delivery.
  • Tighten gradually to p=quarantine then p=reject once reports look clean.
  • Subdomain policy via sp=reject while the apex stays at p=quarantine during migration.
Common gotchas
  • Jumping straight to p=reject without monitoring breaks legitimate mail from forgotten internal senders (CRM, ATS, billing).
  • Wrong record name — must be _dmarc.example.com, not dmarc.example.com.
  • pct=10 means "apply policy to 10% of failures" — useful for gradual rollout, easy to leave in by accident.
  • rua mailto must be on the same domain OR carry an authorization record at the recipient — cross-domain reporting needs setup on both sides.
Examples
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
SPF
RFC 7208
Syntax
<name> <ttl> IN TXT "v=spf1 <mechanisms> <qualifier>all"
What it does

Sender Policy Framework — a TXT record listing which servers are authorized to send mail from this domain. The old SPF record type was deprecated in 2014; today SPF lives in TXT.

When to use
  • Pure Google: v=spf1 include:_spf.google.com ~all
  • Google + SendGrid + own MX: v=spf1 include:_spf.google.com include:sendgrid.net mx ~all
  • No outbound mail at all: v=spf1 -all (combine with null MX to be explicit).
Common gotchas
  • TWO SPF records on the same name is INVALID per spec — merge into one with multiple include.
  • SPF lookups capped at 10 DNS queries — too many include= chain will fail validation; flatten with a generator.
  • ~all (softfail) vs -all (fail) — start with ~all, switch to -all only after DMARC is green.
  • Forwarded mail breaks SPF — use SRS at the forwarder or rely on DKIM for those paths.
Examples
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 3600 IN TXT "v=spf1 mx include:sendgrid.net include:mailgun.org ~all"
example.com. 3600 IN TXT "v=spf1 -all"
Security records (2)
CAA
RFC 8659
Syntax
<name> <ttl> IN CAA <flags> <tag> "<value>"
What it does

Certification Authority Authorization — tells CAs which ones are allowed to issue certs for this domain. CAs MUST check before issuing; reduces mis-issuance and rogue certs.

When to use
  • Lock issuance to Let's Encrypt only: CAA 0 issue "letsencrypt.org".
  • Allow only DigiCert for the apex and Let's Encrypt for *.dev subdomains.
  • Receive failed-issuance reports: CAA 0 iodef "mailto:security@example.com".
Common gotchas
  • Add CAA BEFORE renewing — if your current CA is not in the CAA, renewal fails.
  • CAA at a subdomain overrides the parent — easy to lock yourself out of a single subdomain.
  • Wildcard issuance needs the issuewild tag, not issue (e.g. CAA 0 issuewild "letsencrypt.org").
  • Some CAs ignore CAA at issuance but still log a violation — keep CAA accurate.
Examples
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
TLSA
RFC 6698
Syntax
_<port>._<proto>.<name> <ttl> IN TLSA <usage> <selector> <match-type> <cert-data>
What it does

DANE TLSA record — pins a TLS certificate or public key in DNS, validated via DNSSEC. Lets clients trust the cert without going through the CA chain. Mostly used for SMTP STARTTLS hardening.

When to use
  • SMTP DANE: pin the MX cert so opportunistic STARTTLS becomes enforced TLS.
  • High-security HTTPS in browsers that support DANE (rare, mostly via plugins).
  • XMPP server-to-server TLS pinning between federation peers.
Common gotchas
  • Requires DNSSEC on the zone — without DNSSEC, TLSA is ignored.
  • Renewing a cert without updating TLSA breaks mail delivery hours after the cert switch.
  • Selector 0 (full cert) vs 1 (SPKI) — SPKI survives cert renewal if the key stays the same; pick selector 1 for less ops pain.
  • Browsers largely do not enforce TLSA — do not assume HTTPS DANE works for end users.
Examples
_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abcdef0123456789...
_443._tcp.www.example.com. 3600 IN TLSA 3 1 1 1234567890abcdef...
_5269._tcp.xmpp.example.com. 3600 IN TLSA 3 1 1 fedcba9876543210...
Modern records (2)
HTTPS
RFC 9460
Syntax
<name> <ttl> IN HTTPS <priority> <target> <params>
What it does

HTTPS Service Binding record — lets a domain advertise modern HTTPS parameters (ALPN, ECH, IP hints, port) in DNS so clients can skip a round trip and connect directly with HTTP/2 or HTTP/3.

When to use
  • Advertise HTTP/3 (h3) so Chrome/Safari skip the HTTP/2 Alt-Svc round trip.
  • Encrypted Client Hello (ECH) key publication via the ech= param.
  • Cloudflare auto-publishes HTTPS records when you enable HTTP/3 — clients pick it up transparently.
Common gotchas
  • Browser support varies — Chrome and Safari read it, older clients ignore. Do not rely on it as the only signal.
  • priority 0 = AliasMode (delegate to another name); priority ≥ 1 = ServiceMode. Easy to mix up.
  • Wrong ALPN list silently fails the upgrade — keep it limited to what the server actually supports.
  • Some legacy resolvers drop unknown record types — test with dig +short HTTPS.
Examples
example.com. 300 IN HTTPS 1 . alpn="h3,h2"
example.com. 300 IN HTTPS 1 . alpn="h3" ipv4hint=203.0.113.10 ipv6hint=2001:db8::1
cdn.example.com. 300 IN HTTPS 0 svc.cloudflare.com.
SVCB
RFC 9460
Syntax
<name> <ttl> IN SVCB <priority> <target> <params>
What it does

Service Binding record — the protocol-agnostic parent of HTTPS. Used by non-HTTP protocols (DoH, DoQ, custom services) to publish endpoint params in DNS.

When to use
  • DoH (DNS over HTTPS) endpoint discovery for resolvers.
  • DoQ (DNS over QUIC) endpoint advertising.
  • Custom protocols that need ALPN + port + IP hints in DNS.
Common gotchas
  • Same caveats as HTTPS — newer than HTTPS in deployment terms, expect more legacy resolver oddness.
  • Use HTTPS, not SVCB, for HTTP/HTTPS services — they share the format but browsers only look at HTTPS.
  • ServiceMode vs AliasMode priority semantics catch people the first time.
Examples
_dns.example.com. 300 IN SVCB 1 dns.example.com. alpn="dot"
_dns.example.com. 300 IN SVCB 1 dns.example.com. alpn="h2,h3" port=443
_dns.example.com. 300 IN SVCB 0 cloud.example.com.
Lookup

Educational page — for real queries use `dig` or `nslookup`. The lookup below uses Cloudflare DNS-over-HTTPS where supported.

What this tool does

Searchable reference for the 18 DNS record types you actually meet in production — A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA, DKIM, DMARC, SPF, ALIAS, ANAME, HTTPS, SVCB, TLSA. Every entry shows the type plus its RFC number, the zone-file syntax line, a plain-English and plain-Chinese description, three real "when to use it" scenarios pulled from actual deploys, three to four gotchas that have burned production teams (CNAME at the apex, two SPF records, the 10-lookup SPF ceiling, MX target as a CNAME, missing PTR for outbound SMTP, TTL too long during migration, TLSA without DNSSEC, the SVCB priority-0 trap), and three real example records copy-paste-ready. Search hits the type, syntax, description, scenarios, pitfalls and examples at once — type "cname" and you get CNAME plus every record that warns about CNAME conflicts. Filter by category (core, mail, security, modern). One-click copy of any syntax line. Built-in optional live DoH lookup against Cloudflare 1.1.1.1 for A/AAAA/CNAME/MX/TXT/NS/SOA/CAA so you can confirm a record without leaving the page — with the explicit reminder that for real ops work `dig` and `nslookup` are still the right tools. Bilingual EN/ZH copy independently written, not machine translated. Pair with our Nginx, Docker, kubectl and HTTP Status cheat sheets.

Tool details

Input
Text
The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output
Live result + Copy
The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy
May use a live lookup
A network call is detected in the component, so redact sensitive data when appropriate.
Save / share
No account required
Open the page and use it; whether results survive refresh depends on the tool.
Performance budget
Initial JS <= 22 KB
No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit
Developer & DevOps · Developer
Category and role tags drive related tools, internal links, and quick fit checks.

How to use

  1. 1. Input

    Paste or drop your content into the tool panel.

  2. 2. Process

    Click the button. All processing is local in your browser.

  3. 3. Copy / Download

    Copy the result or download to disk in one click.

How DNS Record Explainer fits into your work

Use it in the small gaps between coding, reviewing, debugging, and shipping.

Developer jobs

  • Formatting, validating, shrinking, or inspecting code-adjacent text.
  • Preparing snippets for documentation, tickets, commits, or handoff.
  • Checking a small payload quickly without switching tools.

Developer checks

  • Run irreversible transforms like minify or obfuscate on a copy.
  • Keep secrets out of pasted snippets unless the tool explicitly stays local.
  • Use your normal tests or linter before shipping transformed code.

Good next steps

These links move the current task into a more complete workflow.

  1. 1 Regex Cheatsheet Interactive regex cheat sheet — quick reference for every flavor (JS, Python, PCRE). Open
  2. 2 IP Subnet Calculator (CIDR) Type an IPv4 CIDR and get network, broadcast, host range, mask, wildcard, class and subnet splits — browser-only. Open
  3. 3 Nginx Cheatsheet Nginx cheat sheet — common configs, location/server blocks, SSL, reverse proxy, gzip, real examples & gotchas. Open

Real-world use cases

  • Pointing a Shopify store at a bare apex domain

    Shopify hands you shops.myshopify.com and tells you to add a CNAME, but example.com is the apex and a CNAME there is illegal. You open the explainer, type "cname", read the apex gotcha, then switch your DNS to Cloudflare and turn on CNAME flattening so the apex answers with A records. The www subdomain stays a normal CNAME. Five minutes, no broken store.

  • Debugging mail that silently lands in spam after adding SendGrid

    You already send via Google Workspace, then bolt on SendGrid for receipts and publish a second SPF TXT. Mail starts hitting spam. You search "spf", hit the two-records-is-PermError gotcha, and merge into one record: v=spf1 include:_spf.google.com include:sendgrid.net ~all. You also spot the 10-lookup ceiling note before stacking a third provider.

  • Rolling out DMARC without blocking your own newsletter

    Security asks for p=reject by Friday. You pull up the SPF/DKIM/DMARC FAQ, see the staged rollout, and start with p=none + rua for two weeks instead. The reports surface a forgotten Mailchimp sender and your ATS. You fix alignment, move to p=quarantine pct=25, then p=reject. Zero legit mail blocked because you read the rollout order first.

  • Setting up SRV for a self-hosted Matrix or Minecraft server

    You want players to type just play.example.com with no port. You search "srv", copy the zone-file syntax, and learn the two traps in one screen: the service label needs an underscore (_minecraft._tcp) and the target must be a real A/AAAA host, never a CNAME or a raw IP. You point it at a host record, verify with the built-in DoH lookup, and players connect clean.

Common pitfalls

  • Putting a CNAME at the zone apex (example.com). It breaks SOA/NS coexistence; use an A record or a provider ALIAS / CNAME-flattening for the root instead.

  • Publishing two separate SPF TXT records when you add a sender. Receivers return PermError; merge everything into one v=spf1 line with multiple include= mechanisms.

  • Pointing an MX record at a CNAME (mail.example.com as a CNAME). RFC 2181 forbids it; point MX at a hostname that has its own A/AAAA records.

Privacy

This explainer is a static reference: the type, syntax, scenario and example text all live in the page bundle and nothing you type into the search box leaves your browser or enters the URL. The one exception is the optional DoH lookup, which sends only the domain name and record type you explicitly submit to Cloudflare 1.1.1.1 over HTTPS; skip that button and the page makes zero network calls.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Browse all tools for this role
Made by Toolora · 100% client-side · Updated 2026-06-13