SPF, DKIM, and DMARC: The Complete Email Authentication Guide

Three records control whether email from your domain is trusted by the world's mail servers: SPF, DKIM, and DMARC. Together, they determine whether your email reaches the inbox, goes to spam, or gets rejected entirely — and whether your domain can be spoofed by someone sending phishing emails that appear to come from you.

Most domains have at least one of these misconfigured. Many have none of them correctly in place.

SPF — Sender Policy Framework

SPF answers the question: which servers are authorised to send email for this domain?

It's a DNS TXT record that lists the IP addresses and services permitted to send email claiming to be from your domain.

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

• v=spf1 — Identifies this as an SPF record.
• include:_spf.google.com — Authorise all IPs in Google's SPF record.
• include:sendgrid.net — Authorise SendGrid for transactional email.
• ip4:203.0.113.10 — Authorise a specific IP.
• -all — Reject email from any server not explicitly listed.

The 10-lookup limit. SPF allows a maximum of 10 DNS lookups during evaluation. Each include:, a:, and mx: can trigger additional lookups. Exceeding 10 causes a PermError. The fix is SPF flattening — replacing include: statements with explicit IP addresses.

~all vs -all. Use -all. Softfail (~all) means unauthorised senders may still be delivered. Hard fail (-all) rejects them. ?all (neutral) provides no protection at all.

Only one SPF record. Multiple TXT records starting with v=spf1 cause a PermError. Combine all sources into one record.

DKIM — DomainKeys Identified Mail

DKIM answers the question: has this email been tampered with, and was it sent by an authorised server?

Your mail server adds a cryptographic signature to outgoing email using a private key. The corresponding public key is published in your DNS. Receiving servers verify the signature against it.

google._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

DKIM keys should be at least 1024 bits. 2048 bits is now strongly recommended — some mail platforms reject email signed with shorter keys.

Important: DKIM signs the message and verifies the signing domain. It doesn't verify the From: address. DMARC enforces that alignment — which is why DMARC is necessary for complete protection.

DMARC — Domain-based Message Authentication, Reporting & Conformance

DMARC does three things: sets a policy for email that fails SPF/DKIM alignment, enforces alignment between the From: domain and authenticated domain, and sends reports back to you.

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100;"

DMARC alignment is what prevents attackers from passing SPF on their own domain while spoofing yours in the From: header. Strict alignment requires exact domain match; relaxed (default) accepts subdomains of the authenticated domain.

Aggregate reports (rua=) are sent daily by receiving servers to your specified address. They show in aggregate how many emails passed or failed authentication, and from which IPs. Use a tool like dmarcian or Google Postmaster Tools to parse them.

How SPF, DKIM, and DMARC work together

Layer 1 — SPF controls which servers can send email for your domain.
Layer 2 — DKIM verifies email hasn't been tampered with and was signed by an authorised server.
Layer 3 — DMARC ties them together: requires at least one to align with the From: domain, and specifies what happens when they don't.

An email passes DMARC if SPF passes and the SPF-authenticated domain aligns with the From: domain, or DKIM passes and the DKIM signing domain aligns with the From: domain. If neither aligns, DMARC fails — and your policy determines what happens.

Setting up email authentication: recommended order

1. Set up SPF first — list all legitimate sending sources, end with -all.
2. Set up DKIM — configure signing in your email platform, publish the public key.
3. Set up DMARC at p=none with a reporting address — collect data before enforcing.
4. Review aggregate reports — confirm all legitimate senders are covered.
5. Move to p=quarantine — start with pct=10, increase gradually.
6. Move to p=reject — full enforcement. Your domain is now spoofing-resistant.