DNS records are the public settings for a domain, and email uses them to find mail servers and to publish authentication policies.
Key points
- DNS was specified in RFC 1034 and RFC 1035, which define resource records with a name, type, class, time to live (TTL) and data [1][2].
- An MX Record tells senders where to deliver mail; A and AAAA records map host names to IPv4 and IPv6 addresses [2].
- TXT records carry SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), DMARC and BIMI policies, so most Email Authentication lives in TXT data.
- CNAME records create aliases and are used for DKIM key delegation and for a Custom Tracking Domain.
- PTR records support Reverse DNS (PTR Record), which Gmail requires for all sending IPs [3].
- Changes take effect as cached copies expire, so the TTL controls how quickly an update reaches receivers [1].
The record types that matter for email
Five record types do most of the work for email. An MX Record names the servers that accept mail for a domain. A and AAAA records give those servers IP addresses. TXT records hold free-form text, and the email world uses them for policies: an SPF (Sender Policy Framework) record starting v=spf1, a DKIM (DomainKeys Identified Mail) public key at a selector under _domainkey, a DMARC policy at _dmarc and a BIMI record at default._bimi. CNAME records point one name at another, which lets a sending service host and rotate DKIM keys for you or serve a branded link domain. PTR records live in the reverse zone for an IP address and map it back to a host name. RFC 1035 defines the base types and the wire format that every DNS server still uses [2].
Why DNS is central to deliverability
Mailbox providers cannot call a sender to ask who they are, so they read DNS. Every authentication decision, from SPF lookups to DKIM key retrieval, depends on records being present, correctly formatted and reachable. Gmail's sender guidelines require valid forward and reverse DNS for sending IPs and published SPF or DKIM records for sending domains, and bulk senders need all three authentication records [3]. A typo in a TXT record or a missing selector causes authentication to fail silently: the mail still sends, but it lands in spam or is rejected. That makes DNS a common first stop when Email Deliverability drops. It is also why a Secondary Sending Domain needs its own complete set of records rather than inheriting the primary domain's.
Managing email DNS records
Records are edited at the domain's DNS host, which may be the registrar or a separate provider. A few habits prevent most problems. Keep exactly one SPF record per name, and check the lookup count after adding a vendor. Give each sending service its own DKIM selector so keys can be rotated without affecting others. Start DMARC at p=none with a reporting address, then tighten the policy once reports are clean. Lower the TTL before planned changes so errors can be corrected quickly, then raise it again. Cloudflare's learning center has plain-English explanations of each record type for anyone new to DNS [4]. After any change, send a test message and read the Authentication-Results line in the Email Headers to confirm the records are working.
Related terms
Outreach without the busywork.
PineLead finds new B2B prospects every day, qualifies them against your criteria and writes the first email in your voice. You approve — PineLead sends.
Start free with 100 credits →