SPF, DKIM, and DMARC — Complete Email Authentication Guide

Why one protocol isn't enough

SPF, DKIM, and DMARC form three layers of email authentication. Each solves a different problem — and none provides complete protection on its own.

• SPF verifies that an email was sent from a server authorized for the domain. It doesn't validate the message content or the "From" header address the recipient sees.
• DKIM cryptographically signs the message and verifies it wasn't altered in transit. It doesn't specify what to do when the signature is missing or fails.
• DMARC ties SPF and DKIM results to the domain in the "From" header (alignment) and defines a policy — what the recipient should do with unauthenticated email.

Without DMARC, SPF and DKIM can fail and the recipient may still deliver the email. Without SPF and DKIM, DMARC has nothing to evaluate. Only together do they form a complete chain: server authorization → message integrity → policy and reporting.

How the three protocols work together

The entire authentication process happens when the receiving server processes an incoming email:

1. SPF check — the server verifies whether the sender's IP address matches the SPF record of the domain from the envelope (envelope sender).
2. DKIM check — the server verifies the cryptographic signature in the message header against the public key in the DNS of the signing domain.
3. DMARC evaluation — the server checks whether the domain from the successful SPF or DKIM check matches the domain in the "From" header (alignment). If it does, DMARC passes. If not, the DMARC policy applies — none, quarantine, or reject.

The key concept: alignment

SPF checks the domain from the email envelope (envelope sender), while DKIM checks the domain that signed the message. Neither has to match the domain in the "From" header — the address the recipient actually sees.

DMARC solves this problem. It requires that at least one protocol (SPF or DKIM) passes and that the domain from the successful check matches the "From" header domain. Without alignment, an attacker could send an email from their own server (with valid SPF for their domain) but with a spoofed "From" address of your company.

DMARC distinguishes two alignment modes: relaxed (default) requires organizational domain match — news.example.com satisfies alignment for example.com. Strict requires an exact domain match. Relaxed alignment is sufficient for most organizations.

What each protocol verifies

Correct deployment order

Deploying all three protocols has a logical sequence. Skipping steps leads to deliverability problems.

1. SPF — authorize your sending servers

Start by listing all services that send email on behalf of your domain: your own mail server, Google Workspace, Microsoft 365, marketing platforms, helpdesk, billing systems. Publish an SPF record that includes them all:

v=spf1 include:_spf.google.com include:mail.zendesk.com ip4:203.0.113.10 -all

Check your SPF record with our analyzer — it validates syntax, DNS lookup count (limit is 10), and include mechanism validity.

2. DKIM — enable signing

For each sending service, enable DKIM signing with your domain. The service generates a key pair — you publish the public key as a CNAME or TXT record in DNS:

selector._domainkey.example.com CNAME selector.service.com

Verify your DKIM record for each selector you use.

3. DMARC — add policy and reporting

Only when SPF and DKIM are working, publish a DMARC record. Start in monitoring mode:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com"

The address example.com@rua.spfmonitor.com routes DMARC reports to SPF Monitor, which automatically processes and visualizes them. Analyze the data for several weeks — identify all legitimate senders and fix any issues.

Then gradually tighten the policy: p=quarantine → p=reject.

Requirements from major providers

Since 2024, Google and Yahoo require email authentication from all senders. Microsoft (Outlook.com, Hotmail) joined in May 2025. The rules vary by sending volume:

All senders

• Valid SPF or DKIM record
• Valid forward and reverse DNS for sending IPs

Bulk senders (over 5,000 messages per day)

• SPF and DKIM and DMARC (at least p=none)
• Alignment of the "From" header domain with SPF or DKIM domain
• Easy one-click unsubscribe
• Spam complaint rate below 0.3%

Failing to meet these requirements means deliverability problems — emails end up in spam or get rejected.

Common mistakes when combining protocols

Missing service in SPF record

When you forget to include a sending service in SPF, its emails may pass DKIM (if the service signs them) but SPF fails. If the service doesn't sign with your domain via DKIM, the entire DMARC check fails and with a quarantine or reject policy, emails won't be delivered.

Solution: Before tightening your DMARC policy, review DMARC reports — they reveal all email sources failing SPF or DKIM.

SPF exceeding the 10 DNS lookup limit

Every include, a, mx, and redirect mechanism in an SPF record requires a DNS lookup. The limit is 10 — exceeding it returns a PermError and the entire check fails.

Solution: Consolidate include mechanisms, replace a and mx with direct IP addresses where possible. SPF Monitor shows your current lookup count.

DKIM signing with a third-party domain

Some third-party services sign emails with their own domain instead of yours. The DKIM check passes, but alignment with the "From" header domain fails — and DMARC doesn't approve.

Solution: In the service settings, enable DKIM signing with your domain (custom DKIM domain).

Forwarding breaks SPF

When email is forwarded, the sending server changes. The new server isn't in the original domain's SPF record, so SPF fails. DKIM signatures typically survive forwarding (as long as the message body isn't modified), so DMARC can pass via DKIM.

This is why having working DKIM is important — it serves as a fallback when SPF fails. The ARC protocol helps preserve authentication results across the forwarding chain.

Practical checklist

Before tightening DMARC to p=reject, verify:

1. SPF: Record includes all authorized senders, doesn't exceed 10 DNS lookups, ends with -all
2. DKIM: Every sending service signs with your domain, public keys are in DNS
3. DMARC reports: You've analyzed at least 2–4 weeks of data from p=none, no legitimate traffic is failing
4. Alignment: Domain in envelope sender (SPF) and signing domain (DKIM) match the "From" header domain
5. Subdomains: The sp=reject tag in your DMARC record also protects subdomains you don't send from

Run a complete analysis of your domain — it checks SPF, DKIM, and DMARC at once and shows where you have gaps.

Summary

SPF, DKIM, and DMARC aren't three independent technologies — they're three layers of one system. SPF authorizes servers, DKIM verifies integrity, DMARC enforces policy and provides feedback. Deploy them in this order, monitor reports, and gradually tighten your policy. Full deployment of all three protocols significantly improves your sender reputation and email deliverability.