SPF vs DKIM vs DMARC: how the three fit together
SPF, DKIM, and DMARC are complementary email-authentication standards, not competing products. SPF checks whether a server is allowed to send for an envelope domain. DKIM verifies a domain's cryptographic signature. DMARC checks whether a passing SPF or DKIM identity aligns with the visible From domain and applies that domain's policy.
Updated July 14, 2026
The differences at a glance
| Standard | What it checks | Published at | Main limitation alone |
|---|---|---|---|
| SPF | Connecting IP is authorized for the envelope domain | A TXT record on the sending/envelope domain | Forwarding can break it; visible From may differ |
| DKIM | A signature validates for its signing domain and signed content | A selector under _domainkey | A valid signature may use an unrelated domain |
| DMARC | SPF or DKIM passes and aligns with the visible From domain | A TXT record under _dmarc | Unsafe enforcement can block forgotten legitimate senders |
What happens when an email arrives
- The receiver notes the connecting server IP and the SMTP envelope sender.
- It evaluates SPF for that envelope domain.
- It validates any DKIM signatures using public keys from DNS.
- It reads the visible From domain and looks up that domain's DMARC record.
- DMARC passes when at least one successful SPF or DKIM identity aligns with the visible From domain.
- If DMARC fails, the receiver considers the published none, quarantine, or reject policy and records the result for reporting.
Why one method is not enough
SPF is tied to the SMTP path, so forwarding can replace the connecting IP and break an otherwise legitimate result. DKIM travels with the message but can break when an intermediary modifies signed content. Either method can also authenticate a provider-controlled domain that does not match the brand in the visible From field.
DMARC solves the visible-domain problem through alignment and tolerates a failure of one method because aligned SPF or aligned DKIM can pass. Configuring both gives legitimate mail two ways to authenticate while DMARC supplies policy and reporting.
The safest setup order
- Inventory every system that sends as your domain: employee mail, marketing, support, billing, product notifications, and infrastructure.
- Create one valid SPF record that authorizes all relevant envelope senders without exceeding 10 DNS lookups.
- Enable custom-domain DKIM in every sending platform and verify real messages use aligned signing domains.
- Publish DMARC at
p=nonewith aggregate reporting. - Fix unaligned sources found in reports, then advance to quarantine and reject.
Do not wait for perfect SPF before enabling DKIM, or vice versa; they can be configured in parallel. The sequence matters most at the DMARC enforcement step, where incomplete discovery can affect delivery.
How to verify the complete chain
DNS checkers tell you whether the records are publicly valid. A real-message test tells you whether your sender actually used them. Run the SPF checker, DKIM checker, and DMARC checker, then send through the inbox test and confirm both the pass results and their domains.
Repeat that real-message test for every sending platform. A successful Google Workspace test says nothing about your CRM or billing service. For a reusable procedure, follow how to check email authentication.
Sources and further reading
- RFC 7208 — Sender Policy Framework (SPF) — The definitive SPF syntax, evaluation, and processing-limit specification.
- RFC 6376 — DomainKeys Identified Mail (DKIM) — The definitive DKIM signing, selector, key, and verification specification.
- RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — The DMARC policy, alignment, reporting, and record-format specification.