Email DNS: MX, SPF, DKIM and DMARC

MX priority and routing, SPF syntax and its lookup limit, publishing and rotating DKIM keys, DMARC policy and reporting, and where BIMI fits.

MX records

; lower priority number wins; equal numbers are used randomly
@    IN  MX  10  mx1.mailprovider.example.
@    IN  MX  20  mx2.mailprovider.example.

; never a CNAME, and never behind a wildcard
mail IN  A   203.0.113.70

• An MX target must be a hostname with an address record, never a CNAME - a large share of reported mail outages trace back to exactly this.
• Production and backup servers should be at different priorities so a secondary is only tried when the primary is unreachable.
• Removing an MX record does not stop mail being queued by senders; they retry for days. Plan a transition window.
• The apex of the domain is where MX usually belongs; a null MX (0 .) tells senders the domain accepts no mail.

SPF

; one SPF record, and only one
@    IN  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.mailprovider.example include:transactions.example -all"

; the -all at the end is a hard fail. ~all is a soft fail and is safer during rollout.
; ?all is no policy at all and should never ship.

• Two SPF TXT records on the same name is a permanent error and the whole record is ignored - check for leftovers from old providers.
• The mechanism count is limited to ten DNS lookups. include:, a, mx, ptr and exists each cost one or more, and exceeding the limit is a permerror.
• ptr is deprecated and expensive. Use ip4, ip6 or include instead.
• SPF checks the envelope sender, not the visible From header. It is one of three signals, and on its own it is weak.

# count the lookups before you publish
dig +short TXT example.com | grep spf1

# and check the whole authentication story from outside
dig +short TXT mail._domainkey.example.com       # DKIM key
dig +short TXT _dmarc.example.com                # DMARC policy

DKIM and DMARC

; the provider gives you the public key and the selector
selector1._domainkey   IN  CNAME  selector1-mx1.mailprovider.example.
; or the key itself
selector1._domainkey   IN  TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

; DMARC: start permissive, watch the reports, then tighten
_dmarc   IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100"

; after a few weeks with a clean report, move to quarantine, then reject
_dmarc   IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=s; aspf=s"

1. Publish SPF and DKIM for every legitimate sender, including the invoicing system nobody remembers.
2. Publish DMARC at p=none with an aggregate report address and collect data for at least a month.
3. Read the reports and fix the senders that fail. These are usually internal applications with a misconfigured SMTP relay.
4. Move to p=quarantine, wait, then to p=reject. Never skip straight to reject.
5. Rotate DKIM keys on a schedule, publishing the new selector before switching the sender and keeping the old one for at least one key-rotation period.

FAQ

Related

Migrating DNS providers without downtime Record types that matter

Last refreshed 2026-09-18.