What does an Authentication Results Header contain when DKIM passes but DomainKeys fail?
Updated on 19 Oct 2026: We clarified how to read mixed DKIM and DomainKeys results, match signature fields, and check DMARC alignment.
An Authentication-Results header with DKIM passing and DomainKeys failing contains two independent authentication verdicts. The receiver verified a modern DKIM signature and separately reported that a legacy DomainKeys signature failed. In the example below, the DomainKeys verifier reports "message has been altered" as its failure reason.
DKIM pass means the DKIM-Signature validated for the signing domain reported in header.d. DomainKeys fail means a separate, older DomainKeys check failed. DMARC uses an aligned DKIM or SPF pass. It does not use legacy DomainKeys.
Direct answer
The header contains the authserv-id of the verifier that wrote it, a method=result pair for each reported check, and supporting properties such as the signing domain. It also supports comments and a free-form reason. Here, DKIM passed for the reported signing domain, while DomainKeys failed with a message-altered reason.
What the header contains
Authentication-Results is a container for one or more method results. A receiving server can write DKIM, SPF, DMARC, ARC, DomainKeys, and other local results into the same header field. Another server in the path can add its own Authentication-Results header later, so a single message often carries more than one. The method=result pairs are separated by semicolons; each method's properties belong to that result. The format is defined in RFC 8601.
Illustrative legacy Authentication-Results headerstext
Authentication-Results: filter.receiver.example (local-filter); dkim=pass (1024-bit key) header.d=sender.example; domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=user@sender.example header.d=sender.example Authentication-Results: mx.receiver.example; dkim=pass (1024-bit key) header.d=sender.example header.i=@sender.example header.b=HP7xiNlf
|
|
|
|---|---|---|
authserv-id | Service that wrote the result | Confirm it is trusted |
dkim=pass | DKIM verified | Check DMARC alignment |
domainkeys=fail | Historic method failed | Treat as legacy context |
header.d | DKIM signing domain from d= | Compare it with From |
header.s | DKIM selector from s=, when reported | Locate the public key in DNS |
header.i | DKIM signing identity from i=, when reported | Do not use it as the DMARC comparison domain |
header.b | Full signature value or a distinguishing prefix of b= | Match the result to its DKIM-Signature |
reason | Free-form verifier explanation | Use it as a clue |
Compact reading guide for the fields in this kind of header.
The first part, filter.receiver.example, is the authentication service identifier. It identifies the system making the assertion. The comment local-filter is explanatory text, not a standardized filter identifier. The second header from mx.receiver.example is a separate assertion from another verifier. Different verifiers can support different methods and produce different comments.
The DKIM result reports a passing signature and a signing domain. The 1024-bit key in this older sample meets the RSA minimum in RFC 8301, which recommends RSA signing keys of at least 2048 bits. The DomainKeys result does not overturn the DKIM pass. Neither sample includes an SPF or DMARC verdict, so these lines alone do not establish a DMARC pass.
Which Authentication-Results header to trust
Authentication-Results has no built-in proof that its assertions are genuine. Trust only results accepted through the receiving system's configured trust boundary. A familiar authserv-id alone is insufficient because a sender can forge it. RFC 8601 requires a border server to remove incoming fields that claim its trusted identifiers unless they came through an authenticated trusted path.
|
|
|
|---|---|---|
Authentication-Results | Results from the named authentication service | Verify the authserv-id and trusted message path |
Authentication-Results-Original | A non-standard saved or renamed earlier result | Use as path history, not the final verdict |
ARC-Authentication-Results | Results observed by an ARC participant | Use with a validated ARC chain and local trust |
How similarly named authentication headers differ.
Do not select a header only because it appears first or last in raw source. Header order can change when gateways prepend fields. Identify the service that made the final delivery decision, confirm its authserv-id, and treat earlier-hop results as context.
Why DKIM can pass while DomainKeys fails
DKIM (DomainKeys Identified Mail) and legacy DomainKeys are separate mechanisms. DomainKeys, documented in Historic RFC 4870, uses DomainKey-Signature. DKIM replaced it with DKIM-Signature and different verification rules. A message carrying both signatures can produce different results for each. When the legacy method is evaluated, a missing signature produces none rather than an alteration failure.
DKIM pass
- The receiver verified the DKIM-Signature with the public key for its selector and signing domain.
- DMARC can use this pass when the signing domain meets the visible From domain's alignment requirements.
- Fields such as header.d, header.i, and header.b identify the signature that passed.
- Give this result priority when deciding whether the signed message authenticated.
DomainKeys fail
- The receiver ran a Historic DomainKeys check that modern DMARC does not use.
- The older signature or its key failed that verifier's checks.
- In this example, "message has been altered" is the legacy verifier's explanation for a failed signature check.
- Use this result as context, not the main modern authentication verdict.
The phrase "message has been altered" reports a signature verification failure; it does not prove deliberate tampering or identify the changed part. Covered-header rewriting, footer insertion, link rewriting, or body re-encoding can cause a mismatch. DKIM simple and relaxed canonicalization tolerate different formatting changes; relaxed does not tolerate arbitrary content edits. Legacy DomainKeys uses simple or nofws rules. The signatures can cover different headers or be applied at different points in the message path.
Flowchart for interpreting DKIM pass and DomainKeys fail in email authentication headers.
The two results can also use different keys. Seeing 1024-bit in both comments does not mean the same key was used. The DKIM selector and the DomainKeys selector can publish different public keys, and a failure in one method does not prove a failure in the other.
Match each result to its original signature
Open the original message source and match DKIM results to DKIM-Signature fields. Compare header.d and header.s with d= and s=; header.b identifies the full b= value or a distinguishing prefix. Check legacy results against DomainKey-Signature separately.
- d= and s= identify the signing domain and selector for the DNS lookup.
- c= specifies canonicalization; h= lists signed headers.
- bh= is the DKIM body hash; b= is the cryptographic signature, not the public key.
- An optional l= limits the signed body length, so a pass does not always cover the entire body.
Look up the DKIM public key using the actual selector and domainbash
dig TXT selector._domainkey.sender.example +short
Replace selector and sender.example with s= and d=. The _domainkey label is also used by DKIM; it does not imply legacy DomainKeys. Signature tags and DNS lookup rules are defined in RFC 6376.
How to diagnose this header
Diagnose this header by separating the modern authentication question from the legacy result. First, determine whether DKIM passed with a signing domain that aligns with the visible From domain. Then decide whether the DomainKeys failure points to a message-handling problem that still affects users.
- Use the authserv-id to identify the Authentication-Results field written by the system responsible for final filtering.
- Read dkim=pass and domainkeys=fail as independent checks, not as one combined verdict.
- Confirm header.d and any reported signature properties. If header.s is absent, read the s= selector in DKIM-Signature.
- Compare header.d with the visible From domain. Relaxed DKIM alignment requires the same Organizational Domain; strict alignment (adkim=s) requires an exact domain match.
- Review forwarding, filtering, footer insertion, or rewriting that changed the message after signing.
For a focused selector and public-key check, Suped's DKIM checker checks the current DNS record. It does not validate the signature of a specific message or establish which key was available when the receiver checked it.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
DNS records can change after delivery. A successful lookup today does not reproduce an earlier verification result. If the trusted receiving header reports DKIM pass and the published key is correct, preserve the original message and inspect the path before changing a working DKIM record.
Do not overreact to DomainKeys
A DomainKeys failure on a message with DKIM pass is not enough reason to change DMARC policy, reject the sender, or declare the signing domain broken. Treat it as a legacy diagnostic signal unless modern authentication also fails or delivery is affected.
- If recipients are not rejecting the mail, the DomainKeys result is usually informational.
- Do not loosen DMARC because a legacy method failed while DKIM passed.
- Save the full headers before testing because forwarded copies can change the evidence.
- Send a fresh message to a controlled mailbox and compare the new headers.
Monitor DKIM and DMARC results with Suped
One header explains one delivery. Domain-level operations also need to show whether the pattern repeats across real traffic, which sending sources are affected, and whether aligned authentication still passes at scale. The domain health checker provides a broader configuration check.
Suped's DMARC reporting product groups aggregate data by sending source and shows whether SPF or DKIM meets DMARC alignment requirements. Use those reports to identify recurring failures, compare affected sources, and check results after a configuration change. DMARC aggregate reports do not include legacy DomainKeys verdicts or the full message needed to reproduce this failure reason.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
With DMARC monitoring, a team can verify sending sources, watch aligned pass rates, receive alerts, and stage policy changes without treating one unusual legacy header as the whole traffic picture.
How these results affect DMARC and delivery
A DKIM pass verifies a signature for its signing domain, but it does not guarantee inbox placement or safe content. If header.d is other.example while the visible From address uses sender.example, that signature cannot satisfy DMARC alignment. DMARC can still pass through SPF if SPF passes with the required alignment. One passing DKIM signature with the required alignment is sufficient even if another signature fails.
- When DKIM passes, treat the signature as valid for its signing domain, then check that domain's DMARC alignment.
- When DomainKeys fails, record it as a legacy clue and investigate message changes only if there is user impact.
- When DMARC passes, the use of the visible From domain has been validated, but message safety and inbox placement remain separate decisions.
- When DMARC fails, troubleshoot aligned DKIM or SPF before spending time on DomainKeys.
- When headers conflict, verify the recognized authserv-id and trusted path for the system that made the final delivery decision.
When to investigate
Use delivery and authentication impact to decide how deep to go.
No user impact
Log only
DMARC passes and delivery is normal.
Mixed headers
Compare
Different receivers add different comments.
DMARC failure
Fix now
Modern aligned authentication is failing.
Spoofing risk
Escalate
Unauthenticated mail is reaching users.
When the same domain shows repeated DKIM problems across receivers, move into a full DKIM investigation. Review DKIM troubleshooting and compare the message headers with selector DNS records and any forwarding path that modifies the mail.
Views from the trenches
Best practices
Separate DKIM and DomainKeys results before deciding whether a sender has failed authentication.
Keep the full original headers because forwarded copies can change the authentication evidence.
Trust the final receiver's Authentication-Results header over copied headers from earlier hops.
Common pitfalls
Treating a legacy DomainKeys fail as a DMARC failure leads to unnecessary DNS changes.
Comparing two verifier comments without checking authserv-id can create false conflicts.
Assuming 1024-bit comments mean the same key ignores selectors and distinct public keys.
Expert tips
Retest with a clean message path before blaming DKIM records for a legacy DomainKeys fail.
Look for body changes, footers, and header rewrites when the reason says message altered.
Use aggregate DMARC data to confirm whether one strange header reflects a wider pattern.
Marketer view
Marketer from Email Geeks says a local filter can add a DomainKeys result while another verifier adds only DKIM results.
2021-11-16 - Email Geeks
Marketer view
Marketer from Email Geeks says different keys can explain why DKIM passes while the older DomainKeys check fails.
2021-11-16 - Email Geeks
Frequently asked questions
No. DomainKeys and DKIM are separate checks. A header can show DKIM pass and DomainKeys fail because each method verifies a different signature format.
No. Under RFC 9989, DMARC passes when DKIM or SPF passes and the authenticated domain meets the visible From domain's alignment requirements. Legacy DomainKeys does not determine the DMARC result.
It is the legacy verifier's explanation for a failed signature check, not proof of deliberate tampering. Covered-header changes or body re-encoding can cause it. Use the original message and verifier logs to identify the cause.
Trust results from the receiving system's configured trust boundary, including the recognized authserv-id and authenticated trusted path where applicable. Treat copied or renamed earlier-hop headers as context unless the receiver explicitly trusts their source.
Stop generating legacy DomainKey-Signature headers after confirming no required sender depends on them. Before deleting DNS, check whether a selector record is also used by active DKIM, because some key records were designed for backward compatibility.
