Why do SPF and DKIM failures sometimes occur despite correct setup?
Published 15 May 2025
Updated 20 Oct 2026
15 min read
Summarize with
Updated on 20 Oct 2026: We clarified how sending routes and DNS problems cause intermittent SPF and DKIM failures.
SPF and DKIM failures sometimes occur despite correct setup because each recipient does not always check the same message, the same sending IP, or the same DNS state. A single campaign can go directly to some inboxes, pass through forwarding rules for others, get modified by mailing lists or security gateways, or hit temporary DNS lookup problems at specific receivers. That is why the result is not always 0% or 100%.
A low, stable failure rate does not prove the setup works on every route. Some delivery paths break authentication after the message leaves the sending platform, while other failures come from unsigned mail or unauthorized use of the domain. A scattered failure pattern needs different treatment than a concentrated pattern against one provider, source, selector, or recipient group.
A small number of SPF or DKIM failures in a large send needs context. Identify whether the messages are legitimate, then check forwarding, message modification, DNS timing, and receiver differences before changing SPF or DKIM records.
Why correct setup does not guarantee every pass
Email authentication is checked by the receiving system at the point it receives the message. That point changes. Direct mail has the best chance of passing. Mail that goes through forwarding rules, distribution lists, security filters, or mailing lists gets checked after those hops.
SPF and DKIM fail for different reasons. SPF checks whether the connecting server is authorized for the envelope sender domain, also called the MAIL FROM or Return-Path domain. DKIM checks whether the signed headers and body still match the signature added by the sender. DMARC then checks domain alignment with the visible From domain. RFC 9989 requires only one passing mechanism that meets those alignment requirements. A failure in one layer does not always mean the whole message fails DMARC.
- SPF often fails after forwarding because the final receiver sees the forwarder's IP, not the original sender's IP.
- DKIM can fail when a system changes signed headers, footers, subject tags, link wrappers, MIME boundaries, or body content.
- Temporary DNS problems can affect only the receivers that query at the wrong moment.
- Receivers evaluate authentication with their own infrastructure, cache state, forwarding treatment, and policy handling.
Email authentication flowchart showing direct delivery, forwarding, message changes, and receiver checks.
Do not assume intermittent failures are harmless until you check clustering. Ten failures spread across many receivers need different investigation than ten failures tied to the same source, selector, or recipient domain.
Common causes of SPF and DKIM failures
Forwarding is a common cause. Your platform sends mail using an IP that SPF authorizes, and it adds a valid DKIM signature. Then a recipient forwards the message without rewriting the envelope sender. The final mailbox sees the forwarder's server, so SPF checks that new IP against the original envelope sender domain's SPF record. That record normally does not authorize the forwarder, so SPF fails.
DKIM survives forwarding better than SPF, but only when the message stays intact. Some paths add footers, subject tags, rewritten links, tracking, MIME changes, or new encoding. If those changes touch signed content, DKIM fails even though the original signature was correct.
SPF fails or stops helping DMARC when
- Forwarding changes the connecting IP to an intermediate server.
- SPF can pass for the envelope sender but not satisfy DMARC when that domain does not match the visible From domain under the published alignment mode.
- Evaluating more than 10 DNS-querying terms during one SPF check returns permerror.
- A timeout or transient resolver problem can return temperror for one receiver.
DKIM fails when
- A footer, tracker, or gateway alters signed body content.
- A downstream system rewrites a header covered by the signature.
- The receiver cannot retrieve the public key from DNS.
- The signature points to a missing selector or a public key that does not match the active private key.
Another common cause is SPF record sprawl. Teams add marketing platforms, CRMs, billing tools, ticketing systems, and internal mail systems over time. The record can grow until it triggers too many DNS lookups, includes stale senders, or authorizes broad ranges.
|
|
|
|---|---|---|
SPF fail only | Forwarding or authorization | Last-hop IP and SPF result |
DKIM fail only | Content or key problem | Body hash and selector |
Both fail | Message path or unrecognized sender | Received chain and source ownership |
Random temporary errors | DNS timing | Resolver response |
Intermittent authentication failure patterns
Check authentication on every sending route
A published DKIM key does not prove that every outgoing server signs mail. A secondary SMTP relay or third-party sender can use different authentication settings. That creates intermittent results even when the main sending platform is configured correctly.
- Send through each active application and fallback SMTP route. Confirm the actual sending IP is authorized for its MAIL FROM domain, including IPv6 when used.
- Check for a DKIM-Signature on each test message. A published key cannot authenticate mail that was never signed.
- Compare the signature's d= domain and s= selector across passing and failing messages. Confirm each signer uses the matching private key and signs after message changes.
- Review signing-service logs if only some servers send unsigned mail. Check access to the private key and whether an SMTP route bypasses the signer.
In the receiving system's trusted Authentication-Results header, dkim=none means the message was not signed; dkim=fail means signature verification failed. These results need different fixes, as defined in RFC 8601.
How to read mixed pass and fail reports
Mixed pass and fail results are normal in seed tests and DMARC aggregate reports. Where failures group matters more than the overall percentage. A low rate spread across forwarded mail is not the same problem as a higher rate tied to one platform or selector. RFC 9990 defines aggregate reporting, while RFC 9991 defines message-specific failure reporting. Receiver support for failure reports varies, so aggregate data and raw headers remain the main evidence for most investigations.
In aggregate report XML, policy_evaluated contains the SPF and DKIM results after DMARC alignment checks; auth_results contains the underlying authentication results. A technical pass in auth_results can therefore appear as fail in policy_evaluated when domain alignment fails. RFC 9990 defines this distinction. A valid DKIM signature for an unrelated domain is a DMARC alignment problem, not a broken DKIM signature.
Start with raw headers when available. Check Authentication-Results added by the receiving system, Received headers, DKIM-Signature, Return-Path, and the visible From domain. Do not trust an earlier Authentication-Results header solely because it appears in the message. Separate fail from none, neutral, temperror, and permerror because they do not describe the same condition. The Received chain shows intermediate systems. DKIM comments often indicate a missing key, body hash mismatch, or signature mismatch, but wording varies by receiver.
Header fields to inspecttext
Authentication-Results: mx.receiver.example; spf=fail smtp.mailfrom=bounces.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com Return-Path: <bounce-id@bounces.example.com> From: Example Team <news@example.com>
This example shows SPF failing while DKIM passes. Because the DKIM d= domain matches the visible From domain, DMARC passes. If several DKIM signatures are present, inspect each result: a failed signature does not cancel a separate passing signature that meets DMARC alignment requirements. The goal is for at least one passing mechanism to meet those requirements through common delivery paths.
Use the failure rate as a triage signal. Confirm whether failed messages are legitimate before attributing a stable rate to forwarding or receiver differences. A rising rate or tight cluster needs investigation even when the overall percentage is small.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Use Suped's domain checker to inspect published email authentication records. A passing DNS check does not prove that a particular message was signed or survived forwarding; compare the result with the failed message's headers.
SPF forwarding and DNS lookup failures
SPF validates the server that connects to the receiver against the envelope sender domain. It does not travel with the message. Without envelope rewriting, a forwarded message is checked using the forwarder's IP and the original envelope sender domain. Sender Rewriting Scheme (SRS) changes the envelope sender to a domain the forwarder controls, allowing SPF to pass for that domain. When that forwarding domain is unrelated to the original visible From domain, its SPF pass does not satisfy DMARC alignment.
SPF can also fail because the record has become too complex. RFC 7208 limits one SPF evaluation to 10 DNS-querying terms, including nested include and redirect processing. The terms actually evaluated depend on the connecting IP, so an early match can pass while another path exceeds the limit and returns permerror. Multiple SPF records at the same DNS name also cause permerror. The recommended two-void-lookup limit is separate; empty or nonexistent DNS answers count toward it. Explicit ip4 and ip6 mechanisms do not count toward the 10-term limit.
SPF record that can become fragiledns
example.com. TXT ( "v=spf1 include:_spf.sender-a.example " "include:_spf.sender-b.example include:_spf.sender-c.example -all" )
Do not add every IP seen in a failure report. Forwarder IPs can over-authorize mail outside your control. For a real sending source, document it, confirm the envelope sender domain, and then add only the approved include or IP range.
Failure pattern triage
Use the domain's established baseline and business impact instead of a universal percentage threshold.
Confirmed forwarding
At baseline
Investigated indirect mail paths explain failures within the established baseline.
Investigate
Above baseline
Failures rise or repeat by receiver, source, selector, or campaign.
Act now
Mail affected
A controlled sender is broken or legitimate mail faces filtering or rejection.
DKIM message changes and key lookup failures
DKIM signs selected headers and a hash of the body. It proves that the signed parts survived verification and that the signer had the private key for the signing domain. It does not promise every downstream system will preserve the message exactly. Relaxed canonicalization tolerates common whitespace changes, while simple canonicalization tolerates less. Neither mode protects a signature from substantive changes such as added text or rewritten signed headers.
Several normal systems modify messages. Mailing lists add unsubscribe text or subject prefixes. Security systems rewrite links. Gateways add confidentiality footers. Other systems recode content or alter MIME structure. Each change can break DKIM depending on what was signed and which canonicalization mode was used.
DKIM failure infographic showing how changes to signed email content affect verification.
DKIM can also fail when the public key cannot be retrieved. Receivers combine the signature's s= selector and d= signing domain to query a name such as selector1._domainkey.example.com. If DNS times out, returns the wrong key, contains a malformed TXT value, or references a selector removed too early, verification cannot succeed. Compare answers across authoritative nameservers and recursive resolvers; inconsistent zone data and cached records can affect receivers differently. During key rotation, publish the new selector before using it and allow cached missing-record responses to expire. Retain the old public key while messages signed with it are still in transit or queued for retry, with allowance for DNS cache lifetimes. RFC 6376 describes selector lookups and key transitions.
Query the DKIM selector from the messagebash
dig +short TXT selector1._domainkey.example.com
DKIM has a better chance of surviving forwarding than SPF, but forwarding can still break it. Give each legitimate sender a DKIM signature that meets the domain alignment requirements for the visible From domain, and apply signing after systems that modify the message whenever the mail flow permits it.
How ARC helps with forwarded mail
Authenticated Received Chain (ARC) lets a participating intermediary record the authentication results it observed before forwarding or modifying a message. A later receiver can validate that chain and use the earlier results as additional evidence when the final SPF or DKIM check no longer passes.
ARC does not repair SPF, make a broken DKIM signature pass, or override DMARC by itself. The final receiver decides whether to trust the ARC sealing domain and whether the validated chain justifies a local policy exception. Senders also cannot force a forwarding service to add ARC.
- ARC-Authentication-Results records what the intermediary evaluated on arrival.
- ARC-Message-Signature protects the message state handled by that intermediary.
- ARC-Seal protects the order and integrity of the ARC sets.
- Check the final receiver's arc=pass result. A cv=pass value in an ARC-Seal records the sealer's assessment of the preceding chain; acceptance still depends on receiver trust and local policy.
ARC is most useful when a known mailing list, forwarder, or security gateway participates correctly. It is evidence about the path, not a replacement for DKIM with DMARC domain alignment on mail sent directly by your domain. See RFC 8617 for ARC validation and receiver handling.
A practical troubleshooting workflow
Investigate intermittent SPF and DKIM failures by working backward from evidence. Do not start by editing DNS. A premature DNS change can hide the real cause or authorize more infrastructure than intended.
- Group failures by source IP, sending service, receiver, DKIM selector, and envelope domain. Identify legitimate senders before changing authorization.
- Read the receiving system's trusted Authentication-Results, Return-Path, DKIM-Signature, Received fields, and any ARC set.
- Check domain alignment separately from authentication. Relaxed alignment requires the same organizational domain; strict alignment requires an exact domain match. Check adkim for DKIM and aspf for SPF.
- Check DNS for SPF evaluation limits, duplicate SPF records, the complete DKIM selector name, and consistent answers across nameservers.
- Retest the same sending route and recipient path. Compare passing and failing messages, including whether each one has a DKIM signature.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped is our DMARC reporting and email authentication platform. Use its reports to group failures by source and receiver, then compare affected messages' headers with the reported SPF and DKIM results before applying the fix steps.
If the domain uses p=none monitoring mode, establish the normal failure baseline before moving to quarantine or reject. Suped's hosted DMARC workflow supports staged policy changes while keeping visibility on sources that still fail.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After reviewing report data, validate the live record with the DMARC checker. Check syntax, reporting configuration, and policy values against the rollout plan. Verify actual report receipt separately; a DNS check cannot prove that a reporting mailbox accepts reports.
How third-party tests can mislead
Seed tests and inbox placement tests are useful, but they compress a lot of behavior into a small report. A result can show SPF fail, DKIM fail, or DMARC fail without proving where the break happened. Treat the result as a lead, then confirm it with raw headers and the actual delivery path.
Email authentication test workflow comparing seed results with headers, relay hops, DNS, and root causes.
If a testing report shows a small number of failures, pull the raw headers for the failed seed messages. Different Received chains between passing and failing messages point to a path difference. If the path is the same but DKIM differs, compare signed headers, body hash, selector, and DNS responses. If SPF differs, compare the connecting IP, envelope sender, and exact SPF result.
Do not fix a seed test by relaxing DMARC policy or adding unknown forwarder IPs to SPF. Fix the sender you control, improve DKIM coverage that meets the domain alignment requirements for the visible From domain, and document the remaining forwarded-mail variance.
A related case occurs when DMARC fails even though SPF and DKIM appear correct in a header summary. The missing detail is often domain alignment. The DMARC failure guide separates technical authentication results from DMARC alignment results. Passing authentication also does not guarantee inbox placement; receivers make separate filtering decisions.
When to monitor failures and when to act
No universal percentage defines a normal failure rate. At scale, some variance is expected because not every recipient path preserves SPF and DKIM. Establish a baseline for each legitimate source and receiver, then investigate changes and clusters. Monitor documented forwarding failures once their cause is confirmed; classify unknown sources before dismissing them.
Act when the failure rate rises, failures cluster around a sender you control, DKIM starts failing after a template or gateway change, SPF returns permerror, or legitimate mail faces filtering or rejection under an enforced DMARC policy. Confirm source ownership and delivery paths before deciding which record or sender needs correction. Authentication failures on unauthorized messages are expected and do not justify adding those sources to SPF.
|
|
|
|---|---|---|
SPF fail, DKIM pass with DMARC alignment | Common with forwarding | Confirm the delivery path |
SPF pass, DKIM fail | Message or signing issue | Check hash, selector, and alignment |
Both fail, scattered | Indirect mail paths or unauthorized traffic | Classify sources; compare with baseline |
Both fail, clustered | Sender problem or repeated unauthorized traffic | Confirm source ownership and inspect the route |
What to do with each failure type
A durable setup uses DKIM with DMARC domain alignment across legitimate senders, a controlled SPF record, and DMARC reporting that makes baseline changes visible. Suped groups those reports by source and receiver so teams can identify a broken sender or selector without treating every forwarded message as a DNS problem.
Frequently asked questions
Yes. SPF is checked against the server that connects to each receiver. Direct deliveries can pass while forwarded copies fail because the final receiver sees the forwarder's IP.
Yes. DKIM can fail if a downstream system changes signed content, the signature points to the wrong selector or key, or the receiver cannot retrieve the public key from DNS.
No. DMARC passes when either SPF or DKIM passes and meets the domain alignment requirements for the visible From domain. Many forwarded messages fail SPF but still pass DMARC through a passing DKIM signature with the required domain match.
There is no universal normal percentage. Establish a baseline by legitimate source and receiver. Confirm the causes of stable failures, classify unknown sources, and investigate rising rates or clusters even when the overall percentage is small.
No, not by default. Add only approved sending sources you control or have authorized to send for your domain. For forwarding, preserve DKIM signatures that meet DMARC domain alignment requirements and monitor remaining failures.
Not directly. ARC preserves authentication evidence recorded by participating intermediaries. A receiver can use a valid chain as part of a local policy decision, but ARC does not turn failed SPF or DKIM results into passes.
