An Authentication-Results header with DKIM passing and DomainKeys failing contains two separate authentication verdicts. The receiver has verified a modern DKIM signature, then also checked a legacy DomainKeys signature and found that the message no longer matched what that older signature covered.
I read that as a mixed legacy result, not as a contradiction. DKIM pass means the DKIM-Signature validated for the signing domain shown in the header, such as header.d. DomainKeys fail means a separate, older DomainKeys check failed, often with a reason such as message altered. DMARC uses DKIM and SPF with a From-domain match. It does not use legacy DomainKeys.
Direct answer
The header contains the receiver that wrote the result, the authentication methods it evaluated, the result for each method, the signing domain, key details, and sometimes a reason string. In this case, DKIM passed for the domain, while DomainKeys failed because the legacy verifier believed the message was altered after signing.
What the header contains
The important detail is that 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.
Example Authentication-Results headerstext
Authentication-Results: amavis.wordtothewise.com (amavisd-new); dkim=pass (1024-bit key) header.d=ontraport.com; domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=landon.ray@ontraport.com header.d=ontraport.com Authentication-Results: mx.wordtothewise.com; dkim=pass (1024-bit key; unprotected) header.d=ontraport.com header.i=@ontraport.com header.b=HP7xiNlf; dkim-atps=neutral
|
|
|
|---|---|---|
authserv-id | Server that wrote it | Trust your receiver |
dkim=pass | DKIM verified | Use for DMARC |
domainkeys=fail | Legacy check failed | Treat as legacy |
header.d | Signing domain | Compare to From |
reason | Verifier comment | Use for clues |
Compact reading guide for the fields in this kind of header.
The first part, amavis.wordtothewise.com, is the authentication service identifier. It tells me which system made the claim. The comment amavisd-new tells me the local mail filter performed that check. The second header from mx.wordtothewise.com is a separate result from another verifier. That matters because different verifiers can support different methods and can produce different comments.
The DKIM result gives more practical security value. It shows a 1024-bit key, a passing result, and a signing domain. The DomainKeys result is useful only as an explanation of what an older checker saw. It does not overturn the DKIM pass.
Why DKIM can pass while DomainKeys fails
DKIM and DomainKeys are related, but they are not the same check. DomainKeys is the older Yahoo-originated mechanism. DKIM became the modern standard and changed the signature format, verification details, and the way receivers use the result. A message can carry both signatures, or a receiver can attempt both checks, and each check can reach a different result.
DKIM pass
- Modern result: The receiver verified the DKIM-Signature with the public key for the selector and signing domain.
- DMARC value: DMARC can use this pass when the signing domain matches the visible From domain under DMARC rules.
- Diagnostic clue: Fields such as header.d, header.i, and header.b identify the signature that passed.
- Operational weight: This is the result I give priority when deciding whether the signed mail authenticated.
DomainKeys fail
- Legacy result: The receiver ran an older DomainKeys check that modern DMARC policy does not use.
- Likely cause: The message changed after the DomainKeys signature was added, or the verifier handled the message differently.
- Common reason: The phrase message has been altered means the hash comparison failed after canonicalization.
- Operational weight: This is a clue, not the main verdict for modern authentication decisions.
The phrase message has been altered usually means the canonicalized message that the receiver checked did not match the signed hash. That change can come from body changes, header rewriting, whitespace handling, line-ending changes, footer insertion, link wrapping, or a verifier that handles an odd message format differently.
Flowchart showing how to read DKIM pass and DomainKeys fail results.
The other subtle point is that the two results can 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.
How to diagnose this header
I diagnose this type of header by separating the modern authentication question from the legacy noise. The first question is whether the message passed DKIM with a signing domain that matches the visible From domain under DMARC rules. The second question is whether the DomainKeys failure explains a message handling problem worth fixing.
- Identify the receiver: Use the authserv-id to decide which Authentication-Results header belongs to the system doing the final filtering.
- Separate the methods: Read dkim=pass and domainkeys=fail as independent checks, not as one combined verdict.
- Check DKIM fields: Confirm header.d, selector, key size, and the signature that passed.
- Compare domains: Compare the DKIM signing domain with the visible From domain using DMARC domain-match rules.
- Review modifications: Look for forwarding, filtering, footers, or rewriting that changed the message after signing.
For a focused selector and public-key check, the DKIM checker is the quickest way to confirm the DNS side of the DKIM result before chasing message-body changes.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A DNS check does not prove that a specific message body remained unchanged, but it removes a common source of confusion. If the selector publishes the expected key and the receiving header says DKIM passed, the next useful work is message-path analysis, not rebuilding 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 the same message also fails DKIM, SPF, or DMARC.
- Check impact: If recipients are not rejecting the mail, the DomainKeys result is usually informational.
- Avoid policy changes: Do not loosen DMARC because a legacy method failed while DKIM passed.
- Keep evidence: Save the full headers before testing, because forwarded copies can change the result.
- Retest cleanly: Send a fresh message to a controlled mailbox and compare the new headers.
Where Suped fits
The hard part is not reading one header once. The hard part is knowing whether the same pattern is happening across real traffic, which senders are affected, and whether DMARC is still passing at scale. For a broader check across DMARC, SPF, and DKIM, the domain health checker is a useful starting point.
Suped's product is stronger for ongoing operations because it groups sources, flags authentication issues, and shows the fix steps instead of leaving you to compare raw headers by hand. It also brings DMARC, SPF, DKIM, Hosted SPF, Hosted MTA-STS, SPF flattening, blocklist (blacklist) monitoring, and deliverability signals into one workflow.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For most teams, Suped is the best overall DMARC platform for this workflow because it connects authentication results to concrete remediation. You can monitor a domain, see which sources are verified or unverified, get real-time alerts, and use DMARC monitoring to move from observation to policy staging without treating one odd legacy header as the whole story.
Authentication signal weight
A practical way to prioritize signals when DKIM passes but DomainKeys fails.
Primary
Diagnostic
Legacy
What to do with the result
If the question behind the header is where to report spam, do not use DomainKeys fail as the reporting target by itself. Use the visible From domain, Return-Path, received chain, DKIM signing domain, and the platform or sender responsible for the traffic. Authentication tells you whether a domain authenticated the message; it does not always tell you who should receive the abuse report.
- If DKIM passes: Treat the DKIM signature as valid for that signing domain, then check whether DMARC used it.
- If DomainKeys fails: Record the failure as a legacy clue and look for message changes only if there is user impact.
- If DMARC passes: The modern domain-authentication result is acceptable, even with the legacy failure present.
- If DMARC fails: Troubleshoot DKIM, SPF, and From-domain matching before spending time on DomainKeys.
- If headers conflict: Trust the Authentication-Results header added by the system that made the final delivery decision.
When to investigate
Use impact, not curiosity, to decide how deep to go.
No user impact
Log only
DKIM passes and delivery is normal.
Mixed headers
Compare
Different receivers add different comments.
DMARC failure
Fix now
Modern 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. A practical next step is to review DKIM troubleshooting and compare the message headers, selectors, 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 legacy key locations.
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 from Email Geeks says a local Amavis check can add a DomainKeys result while another verifier adds only DKIM results.
2021-11-16 - Email Geeks
Marketer from Email Geeks says OpenDKIM does not check legacy DomainKeys, so its header can look cleaner than an Amavis header.
2021-11-16 - Email Geeks
The practical answer
When DKIM passes but DomainKeys fails, the Authentication-Results header is telling you that the modern signature validated and the legacy signature did not. The safest interpretation is that DKIM passed for the signing domain, DomainKeys saw an alteration or verifier mismatch, and DMARC should be judged on DKIM and SPF, not DomainKeys.
I would not change a DMARC policy, blame a sending domain, or report spam based only on the DomainKeys failure. I would confirm the DKIM fields, check whether DMARC passed, preserve the full headers, and investigate message modification only when the pattern repeats or delivery is affected.
- Main verdict: DKIM pass carries the modern authentication value.
- Legacy clue: DomainKeys fail explains what the older check saw.
- Next action: Use DMARC results and source-level evidence to decide whether there is a real problem.
- Operational fix: Monitor authentication at domain level instead of relying on one unusual header.
