SPF, DKIM & DMARC Setup Guide

SPF, DKIM and DMARC are the three DNS records that prove your email is legitimate. Get them wrong and you land in spam; get them right and you build sender trust. Here's how.

Why authentication matters

Mailbox providers assume unauthenticated mail is forged. As covered in our bulk server setup guide, authentication isn't optional — it's the entry ticket to the inbox. Bulk-sender rules at Gmail and Yahoo now require all three.

1. SPF — Sender Policy Framework

SPF is a TXT record listing which IPs may send for your domain:

v=spf1 ip4:192.0.2.10 include:_spf.yourprovider.com -all

Use -all (hard fail) once you're confident. Keep it under 10 DNS lookups or you'll hit SPF PermError and the record stops working.

2. DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to each message. You publish the public key as a TXT record at a selector:

selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."

Your MTA holds the private key and signs outbound mail. In PowerMTA this is set per domain — see the PowerMTA config guide. Rotate keys periodically for security.

3. DMARC — the policy layer

DMARC tells receivers what to do when SPF/DKIM fail, and sends you reports:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

Start at p=none to monitor, then move to quarantine and finally reject once aligned. Jumping straight to p=reject can block your own legitimate mail.

Don't forget rDNS

A matching PTR (reverse DNS) record on each sending IP complements these three. Together they form your authentication baseline.

Common mistakes

• Multiple SPF records on one domain (only one is allowed).
• Too many SPF lookups → PermError.
• DKIM key not actually signing because the selector is wrong.
• DMARC set to reject before SPF/DKIM are aligned.

AutoPMTA's DNS Health module checks SPF, DKIM, DMARC and rDNS live, so you catch misconfigurations before they cost you the inbox.