SPF, DKIM and DMARC records

The three records

Email authentication is three DNS records doing three jobs. SPF authorises which IP hosts may send like your domain, DKIM signs the message so the receiver can verify it was not altered, and DMARC tells the receiver what to do with mail that fails both. None is optional for deliverability: receivers increasingly reject mail that does not carry all three.

SPF

example.com. TXT "v=spf1 include:_spf.provider.example.com ~all"

The string is a chain of mechanisms. include: pulls in the listed domain's record (a provider publishes its own), and the terminal ~all or -all says what to do with everyone else: ~all soft-fail, -all hard-fail. A hard-fail with an incomplete allow-list silently breaks email from a host you forgot to include.

Hard limits to respect:

• An SPF record may do at most 10 DNS lookups including the included domains. Each include or a/mx mechanism that forces a lookup counts. A host that tells you to add three include: lines can push you past the 10-lookup ceiling.
• Never set two TXT spf strings on the domain. The first one is authoritative; any others are ignored.
• -all is the correct firm end state once every real sender is listed. Work there in stages (~all first, watch the reports).

DKIM

DKIM is a TXT record at a selector from the mail provider: often default, google, or s1, named like s1._domainkey. The mail server looks up that record when it verifies a signed message.

default._domainkey. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0...base64-key"

• The selector is provider-specific and printed in the provider's setup table; yours may be default and the record value a long base64 line.
• The public key is harmless to publish (it is public by design); the private key stays off the public record.
• The TTL does not matter day to day; it matters pre-rotation. Lower TTL before any DNS change that could fail, then restore; see DNS TTL.

DMARC

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

The p= policy is a progression. Start at p=none to watch reports, move to p=quarantine when you confirm mail passes, then p=reject once you trust the list. Common failure modes:

• Missing policy: no _dmarc TXT at all, or the value unquoted. Keep it a TXT record, not an A record, and quote the whole value in one line.

Deploy order

1. Document your senders. Every service that emails from your domain (host, newsletter, CRM, transactional API) has an allow entry; list them before editing SPF.
2. Add SPF first with ~all, verify each sender from a fresh mailbox, then tighten to -all.
3. Add DKIM key from each provider, verify with dkimvalidator or the provider's own test.
4. Add DMARC at p=none with reports, collect two weeks of rua aggregate XML, confirm pass rates, then move policy up one notch.
5. Validate with a send from each provider and read the headers with a mail-tester service; check spf=pass, dkim=pass, dmarc=pass.

Common mistakes

• Editing a live SPF string and dropping a sender. Every edit rewrites the same single RRset, so a line a provider added disappears unless you paste the full string. Copy the current value first, then amend it.
• Two SPF records, or SPF on a CNAME target. SPF must live once on the apex TXT where the MX points; two SPF strings is a softfail nobody resolves.
• -all too early. Moving to hard fail before every sender is listed mid-week means one sender's mail gets dropped and the replay window with receivers only closes after days of reports.

When to involve a professional

If the mail upstream is a third party that runs its own helpers (Google Workspace, Microsoft, a B2B CRM) and reports spf=pass while a delivery test still quarantines, the sender requirements and header signer are the expert's territory. Hand them the "who sends this domain's mail" list and let them align the pieces.