DNS for Email: Everything You Need to Know (But Were Afraid to Ask)
Email depends on DNS more than any other internet service. Without the right DNS records, your emails will not be delivered, will land in spam, or will be rejected outright. Yet DNS is one of the least understood parts of email infrastructure.
This guide explains every DNS record type that affects email — what it does, why it matters, and how to set it up correctly.
The essential records
MX (Mail Exchange)
What it does: Tells the internet where to deliver email for your domain.
When someone sends email to you@yourdomain.com, their mail server asks DNS: "Where should I deliver mail for yourdomain.com?" The MX record answers.
yourdomain.com. MX 10 mx1.mailprovider.com.
yourdomain.com. MX 20 mx2.mailprovider.com.Priority: The number (10, 20) indicates preference. Lower = higher priority. The sending server tries the lowest number first, falling back to higher numbers if the primary is unavailable.
Common mistakes:
- No MX record at all — email cannot be delivered to your domain
- MX pointing to a CNAME — technically invalid per RFC, though some servers tolerate it
- MX pointing to an IP address — MX must point to a hostname, not an IP
- Conflicting MX records from different providers — email gets split randomly
SPF (Sender Policy Framework)
What it does: Lists which servers are authorized to send email for your domain.
SPF is a TXT record at the root of your domain:
yourdomain.com. TXT "v=spf1 include:_spf.google.com include:_spf.cleanbox.to -all"See the complete authentication guide for detailed SPF syntax and common mistakes.
Critical rule: One SPF record per domain. Two SPF records = both invalid.
DKIM (DomainKeys Identified Mail)
What it does: Publishes the public key used to verify email signatures.
DKIM records are TXT records at a selector subdomain:
selector1._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."Key points:
- The selector name is chosen by your email provider (e.g.,
google,selector1,k1) - Use 2048-bit RSA keys minimum (1024-bit is considered weak)
- Long keys may need to be split across multiple strings in the TXT record
- You can have multiple DKIM records with different selectors (useful when migrating providers)
DMARC (Domain-based Message Authentication, Reporting and Conformance)
What it does: Defines the policy for handling authentication failures and enables reporting.
_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"Always published at the _dmarc subdomain. See the authentication guide for the full DMARC rollout path.
The delivery records
PTR (Pointer / Reverse DNS)
What it does: Maps an IP address back to a hostname. The reverse of an A record.
PTR records are not set in your domain DNS — they are configured by whoever owns the IP address (your hosting provider or ISP). But they affect email delivery significantly.
Why it matters: Many mail servers reject or penalize email from servers without a valid PTR record. The PTR should resolve to a hostname that in turn resolves back to the same IP (forward-confirmed reverse DNS).
# Forward: mail.yourdomain.com -> 203.0.113.10
# Reverse: 203.0.113.10 -> mail.yourdomain.com (PTR record)If you self-host a mail server, make sure your hosting provider sets the PTR record. If you use a cloud email provider (Google, Microsoft, Cleanbox), they handle this.
A / AAAA records for mail servers
Your MX record points to a hostname. That hostname needs an A record (IPv4) or AAAA record (IPv6) to resolve to an IP address:
mx1.yourdomain.com. A 203.0.113.10
mx1.yourdomain.com. AAAA 2001:db8::10If you use an external provider (MX points to their hostname), you do not need to create these — the provider manages them.
The security records
MTA-STS (Mail Transfer Agent Strict Transport Security)
What it does: Forces all incoming email connections to use TLS encryption. Prevents downgrade attacks where a man-in-the-middle strips encryption.
Two components:
1. DNS TXT record:
_mta-sts.yourdomain.com. TXT "v=STSv1; id=20260101"2. Policy file served over HTTPS:
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.yourdomain.com
max_age: 86400Modes:
testing— Report failures but do not enforce (start here)enforce— Reject connections that cannot establish TLS
TLSRPT (TLS Reporting)
What it does: Tells sending servers where to send reports about TLS connection failures to your domain.
_smtp._tls.yourdomain.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"Works alongside MTA-STS. Sending servers report when they could not establish a secure connection, helping you identify configuration issues.
DANE (DNS-Based Authentication of Named Entities)
What it does: Publishes TLS certificate information in DNS, preventing certificate forgery. Uses TLSA records.
_25._tcp.mx1.yourdomain.com. TLSA 3 1 1 abc123...Requirement: DNSSEC must be enabled on your domain. Without DNSSEC, DANE records can be spoofed, defeating the purpose. This limits adoption — many domains do not use DNSSEC.
The branding records
BIMI (Brand Indicators for Message Identification)
What it does: Displays your brand logo next to your emails in supporting clients (Gmail, Apple Mail).
default._bimi.yourdomain.com. TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem"Requirements:
- DMARC policy must be
p=quarantineorp=reject - Logo must be in SVG Tiny PS format
- A Verified Mark Certificate (VMC) from a certificate authority ($1,000-1,500/year)
- Only the
l=(logo URL) is required; thea=(VMC) is needed for Gmail
BIMI is primarily a branding feature, but it incentivizes strong DMARC enforcement — you cannot display a logo without p=quarantine or p=reject.
Record checklist by use case
Minimum viable email (personal domain)
| Record | Required? |
|---|---|
| MX | Yes |
| SPF | Yes |
| DKIM | Yes (provider sets up) |
| DMARC | Recommended (start with p=none) |
Business domain
| Record | Required? |
|---|---|
| MX | Yes |
| SPF | Yes |
| DKIM | Yes |
| DMARC (p=reject) | Yes |
| MTA-STS | Recommended |
| TLSRPT | Recommended |
| BIMI | Optional (branding) |
| PTR | Yes (if self-hosting) |
Debugging DNS issues
When email is not working, DNS is the first place to check:
# Check MX records
dig MX yourdomain.com +short
# Check SPF
dig TXT yourdomain.com +short | grep spf
# Check DKIM (replace "selector1" with your actual selector)
dig TXT selector1._domainkey.yourdomain.com +short
# Check DMARC
dig TXT _dmarc.yourdomain.com +short
# Check MTA-STS
dig TXT _mta-sts.yourdomain.com +short
# Full diagnostic
dig ANY yourdomain.comOnline tools like MXToolbox, Google Admin Toolbox, and mail-tester.com provide visual DNS diagnostics with explanations of any issues found.
DNS propagation
After changing DNS records, the changes need to propagate across the global DNS system. Propagation time depends on:
- TTL (Time to Live) — How long DNS resolvers cache the old record. Lower TTL = faster propagation. Set TTL to 300 (5 minutes) before making changes, wait for the old TTL to expire, then make changes.
- Provider — Cloudflare propagates in seconds. Traditional registrars may take 15-60 minutes. Full global propagation can take up to 48 hours in edge cases.
Tip: Before making DNS changes that affect live email, lower the TTL 24 hours in advance. This ensures the old cached records expire quickly when you make the switch.
