SPF and DKIM answer different questions: here’s the difference in plain English
SPF asks whether the connecting host is authorised to use a domain in the SMTP transaction, normally the MAIL FROM domain. The receiver evaluates the client IP against that domain’s published SPF policy. RFC 7208 defines SPF as host authorisation for MAIL FROM and HELO identities. It does not sign the message and it does not normally test the address a person sees in From.
DKIM places a cryptographic signature in the message. The receiver retrieves a public key using the signature’s selector and signing domain, then checks the signed header fields and body hash. RFC 6376 defines the signing domain, selector and verification process. It can survive a route change when the signed content remains intact, but later message modification can invalidate it.
The useful reframe is not “which is better?” but “which identity and failure mode does each cover?” They are complementary evidence. DMARC then compares a passing SPF or DKIM domain with the visible From domain.
If you have ever stared at a deliverability report and wondered why one tool says SPF passed while another says mail is still failing, the answer is usually that the two checks are protecting different things. SPF guards who is allowed to use your domain in the SMTP envelope; DKIM guards the content that carries your signature. Understanding that distinction is the fastest route from confusion to a working DMARC setup that receivers trust.
SPF follows the SMTP route rather than the message body
An SPF check needs the connecting IP and the MAIL FROM identity observed during receipt. Those facts belong to the SMTP session. A forwarded message arrives from the forwarder’s IP, so the original domain’s SPF authorisation may no longer match even though the visible content is untouched.
An SPF policy is one TXT record beginning v=spf1 at the name being authorised. Multiple SPF records at one owner name are not permitted. Evaluation can use mechanisms such as ip4, ip6, a, mx and include, and DNS-querying terms are subject to processing limits. The SPF specification defines record selection and lookup limits.
This makes broad copy-and-paste edits risky. Adding a second record can cause a permanent error; nesting another include can exceed processing limits; removing an unfamiliar include can break an existing sender. Query the exact envelope domain and understand the complete policy before changing it.
DKIM follows a signature and the content it covers
A DKIM signature names its signing domain in d= and its selector in s=. The receiver combines them into a DNS name such as selector._domainkey.example.com to find the public key. The private key stays with the signer and must never be placed in DNS, a ticket or a diagnostic message.
DKIM can use canonicalisation rules that tolerate certain presentation changes, but verification still depends on the signed headers and body matching what the signer hashed. Footers added after signing, malformed gateways or content transformations can break a once-valid signature. RFC 6376 explains canonicalisation, hashes and the limits of the integrity assertion.
A DKIM pass proves that the signature verified for the named signing domain. It does not by itself prove that this domain matches the visible From domain, that the content is benign or that the human sender is genuine. Those are separate assessments.
When a signature names a selector but fails, use the DKIM key and selector guide to query the exact signing identity.
DMARC connects either passing path to From
DMARC uses the SPF-validated MAIL FROM domain and the DKIM d= domain as authenticated identifiers. It passes when at least one passing identifier aligns with the Author Domain. RFC 9989 defines this OR relationship and identifier alignment. Requiring both SPF and DKIM to align for every message is not the DMARC pass rule.
Consider a campaign showing news@example.com. SPF might pass for bounce.vendor.net, while DKIM passes for example.com. DMARC passes through DKIM only. Another route may use return.example.com for SPF and carry no useful DKIM signature; relaxed SPF alignment can carry that message.
This is why an aggregate dashboard that reports “SPF pass” is not enough. Record the domain attached to the result. The same applies to DKIM. A passing result for an unrelated provider domain authenticates that provider identity, not the business domain in From.
The practical consequence for a business owner is that you rarely need to guarantee both checks on every message: DMARC only needs one aligned path to pass. That does not mean you should ignore the other; each check has failure modes the other does not cover, which is why balanced configuration matters. If you want the details of that comparison, the DMARC alignment guide explains it properly.
Match the fix to the mechanism that actually failed
If SPF returns none, query the exact MAIL FROM domain and confirm whether a policy should exist there. If it returns permerror, inspect multiple records, syntax and lookup expansion. If it fails only after forwarding, do not authorise the forwarder blindly; determine whether aligned DKIM survives or whether the intermediary changes the message.
If DKIM is absent, find whether the sending platform offers domain authentication and whether signing is enabled for the affected route. If DKIM fails, use the observed d= and s= values to query the precise public-key name. Separate a missing DNS key from a body-hash or signature failure. Do not rotate unrelated selectors.
If either mechanism passes but DMARC fails, alignment is the first comparison. Changing SPF syntax cannot align an unrelated DKIM domain, and publishing a DKIM key cannot alter a provider-controlled envelope domain. Give the issue to the owner of the identity that must change.
Getchanges every subsequent stage. A DKIM failure needs its key and selector investigated; an SPF failure needs the envelope route and include chain examined: and the fixes are not interchangeable. If you suspect an SPF problem, the SPF repair guide walks the diagnostic path in detail, while selector issues belong in the DKIM troubleshooting guide.
Collect a four-identity evidence row
- Visible identity: copy the domain after @ in the single From address.
- Route identity: copy the MAIL FROM domain represented by Return-Path or trusted receiver evidence, plus the connecting source if available.
- Signing identity: copy each passing or failing DKIM
d=domain ands=selector. - Receiver verdicts: preserve SPF, DKIM and DMARC results, reason text, UTC time and receiving service.
Google’s current sender guidance requires SPF or DKIM for all senders to personal Gmail accounts and both mechanisms plus DMARC for senders above its published bulk threshold. It also tells users of service providers to verify that their domain mail is authenticated. Google lists its current sender requirements and verification advice. Provider rules are operational requirements, not replacements for the protocol definitions.
Use one row per route and message type. A marketing platform, website form and staff mailbox may all display the same domain while producing different evidence.
Redundancy helps only when both paths are maintained
Configuring aligned SPF and aligned DKIM gives a receiver two possible routes to a DMARC pass. That can help when forwarding changes the SMTP path or when an isolated signing fault occurs. The trade-off is operational ownership: every authorised sender, SPF dependency, selector and key lifecycle must be maintained.
Do not add mechanisms merely to make a dashboard show more green marks. An oversized SPF design is fragile, and an old DKIM key left active after a supplier closes is unnecessary authority. Prefer a documented envelope subdomain, provider-specific selector and clear owner over a root-domain record that nobody understands.
Review evidence after migrations, template gateways and routing changes. SPF is sensitive to the path that connects; DKIM is sensitive to the signed material that arrives. The right maintenance check follows those mechanisms rather than assuming yesterday’s pass applies to tomorrow’s route.
Separate routing evidence from signing secrets
An SPF investigation needs the connecting source, MAIL FROM domain, receiver result and the policy retrieved for that domain. A DKIM investigation needs the d= domain, s= selector, verification result and public-key answer. Record those items in the four-identity row and keep the full received header in a restricted mailbox-administration folder. Remove names, local parts and subject text from the working copy unless one of them is directly relevant to the fault.
Treat the two mechanisms differently when evidence is shared. An SPF include chain and public DKIM key are public DNS data, but a complete header can disclose internal relays and recipients. A DKIM private key is never diagnostic evidence and must stay inside the signing service. Supplier support should receive only the failing identity, selector or source, the exact result, a UTC timestamp and a redacted header extract through its authenticated support channel.
Set access and deletion dates for the case material. If a provider requests mailbox credentials or private signing material, refuse and escalate to the service owner. If staff or customer mail is the only available sample, obtain approval from the relevant data owner before copying it. Stop rather than moving personal message data into an uncontrolled ticket.
Test SPF and DKIM as two different mechanisms
Run one authorised message through the affected route and inspect it at a receiver you control. For SPF, capture the Return-Path or trusted MAIL FROM evidence, connecting source and SPF verdict. For DKIM, capture every signing domain and selector, then note which signature verified. Finally compare each passing domain with the visible From domain for DMARC alignment. This is more useful than a checker that reports only that some DNS text exists.
The acceptance result should name the mechanism that carries the route. If aligned DKIM is meant to survive forwarding, verify that signature on the forwarded copy as well as the direct copy. If aligned SPF is the intended path, confirm the actual envelope domain and source rather than the web page’s From address. Repeat a separate known-good sender after any shared SPF or selector change.
Save the expanded SPF policy, selector query, received headers and test times beside the route record. DNS caches can explain a temporary difference, but they cannot explain a changed body hash or a provider using another envelope domain. When the test uncovers a different mechanism failure, assign it separately instead of declaring the combined setup repaired.
Stop when the mechanism no longer matches the proposed fix
Do not edit SPF because DKIM is unaligned, and do not publish a DKIM record to cure an SPF route failure. Stop if the MAIL FROM domain has not been observed, if the selector in the received signature differs from the provider instruction, or if the SPF policy cannot be expanded within its processing rules. An occupied selector and a second SPF record are also reasons to halt before publication.
Send SPF-limit questions to the DNS and mail-routing owners. Send missing or invalid signatures to the service that performs signing. Provide each owner with the exact domain, result, query and redacted header rather than a broad request to “fix authentication”. Roll back the last isolated change if a known-good sender stops working.
Never add unrelated IP addresses, delete an unexplained include, overwrite an active selector or hand a private key to support. Resume only when one owner can explain the affected identity, the change is reversible and a direct receiver test has been agreed.
Sources and further reading
- RFC 7208: Sender Policy Framework
- RFC 6376: DomainKeys Identified Mail signatures
- RFC 9989: Domain-based message authentication, reporting and conformance
- Google email sender guidelines