Why does Gmail show DKIM failing when it actually passes?
Updated on 11 Oct 2026: We clarified Gmail's DKIM results, SPF-based DMARC passes and checks for real signature failures.
Gmail's Show original summary can say DKIM failed while its raw receiving header records a passing signature. Confirm that both results concern the same delivered message and DKIM signature before treating this as a display discrepancy. The raw Authentication-Results field added by mx.google.com is the source to trust first. If that field says dkim=pass and dmarc=pass, that DKIM signature verified and DMARC passed at Gmail, even if the formatted summary says DKIM failed. These results do not guarantee inbox placement.
A subdomain or sending-service domain changes the DMARC domain comparison, but that alone does not explain a contradictory Gmail summary. Confirm the raw header, compare the visible From domain with the DKIM d= signing domain, then check the selector and key with a DKIM checker. Do not change DNS, loosen DMARC, or rotate keys until the raw header proves a real authentication failure.
- Source first: Use the raw Gmail header before the formatted summary table.
- Real failure: Treat broken signatures, missing selectors, and modified signed content as actual DKIM problems.
- Domain match: Check whether relaxed or strict DMARC matching was in force when the message was sent.
- Delivery signal: If delivery is normal and DMARC passes, the Gmail summary alone is not enough evidence.
Why the two Gmail views disagree
Gmail gives you more than one view of the same message. The formatted original message panel tries to simplify authentication for humans. The raw header records the authentication result stamped by Google's mail system. Email Geeks participants have reported disagreements between these views. Those observations do not establish which rule causes Gmail's summary to differ.
Gmail Show original DKIM FAIL summary beside dkim=pass and dmarc=pass in Authentication-Results.
The raw header is more precise because it separates DKIM and SPF verification from DMARC authentication. The Gmail summary can compress those details. In the confusing case, DKIM has not failed cryptographically. A domain mismatch affects DMARC's use of the signature, not the cryptographic verification result.
A message can contain several Authentication-Results fields and several DKIM results. Start with the field added by Gmail's receiving system, normally identified by mx.google.com, and read every DKIM result in that field. Do not treat an older result added by a forwarding hop as Gmail's verdict. For forwarded mail, ARC-Authentication-Results records earlier authentication checks; a pass there does not prove Gmail's current DKIM check passed. Read the original headers in the recipient's Gmail account, not header text quoted in the message body.
Example of Gmail receiving results with DKIM and DMARC passtext
Authentication-Results: mx.google.com; dkim=pass header.i=@mail.example.com header.d=mail.example.com header.s=smtp1; spf=pass smtp.mailfrom=bounce@mail.example.com; dmarc=pass header.from=example.com
Trust the stamped result first
If Gmail stamps dkim=pass in its Authentication-Results field, that DKIM signature verified at Gmail. A conflicting summary warrants checking every signature and preserving the header sample; it does not by itself establish a DNS fault or a specific Gmail display bug.
How DMARC checks the DKIM signing domain
DKIM verification and DMARC alignment are separate checks. First, the receiver verifies the DKIM signature against the public key at the selector under the signing domain. Second, DMARC checks whether the DKIM d= signing domain has the required relationship to the visible From domain. Those are not the same test. The DKIM identity in i= or header.i is useful context, but DMARC compares the signing domain.
With relaxed DKIM domain matching, a signing domain such as mail.example.com can satisfy DMARC for From example.com because both share the same organizational domain. With strict matching, the DKIM signing domain must exactly match the visible From domain. Email Geeks participants have suggested a strict comparison as an explanation for some summary discrepancies. A subdomain mismatch alone does not establish that explanation, and changing DMARC matching does not repair an invalid DKIM signature.
Relaxed DMARC DKIM matching
- Default mode: Used when the DMARC record does not set adkim=s.
- Subdomain ok: mail.example.com can match example.com for DMARC.
- Common setup: Used by senders that sign from a mail or bounce subdomain.
- Verification result: A DMARC domain match still requires a passing DKIM signature.
Strict DMARC DKIM matching
- Exact mode: Enabled by adkim=s in the DMARC record.
- Subdomain mismatch: mail.example.com does not match example.com exactly.
- Narrow use: Requires an exact DKIM domain match for DMARC to pass through DKIM.
- Fix path: Use the exact From domain for signing, or review whether relaxed matching meets your requirements.
|
|
|
|
|
|---|---|---|---|---|
example.com | example.com | Pass | Pass | Exact match |
example.com | mail.example.com | Pass | Fail | Subdomain match |
example.com | mailer.vendor.net | Fail | Fail | Unrelated signing domain |
mail.example.com | example.com | Pass | Fail | Parent match |
Domain-match results only; each DKIM signature must also pass verification.
When multiple DKIM signatures confuse the result
One message can carry several DKIM signatures, and each signature can pass or fail independently. A sender, outbound gateway, forwarder, or mailing system can add another signature. This explains headers that contain both dkim=pass and dkim=fail without any contradiction.
Google documents a Gmail-specific limit: Gmail checks only the first five signatures listed in the message's Authentication-Results header. If the useful passing signature is outside that set, it cannot supply Gmail's DKIM-based DMARC pass. DMARC still passes if SPF passes with the required From-domain relationship. The Google DKIM troubleshooting page confirms this limit.
- Count signatures: Count every DKIM-Signature field in the received message.
- Map each result: Match each result to its header.d and header.s values when Gmail provides them. If those values repeat, use header.b when present to match the reported signature prefix to its b= value.
- Check the first five: Confirm that a passing signature with the required From-domain relationship appears within Gmail's checked set.
- Reduce redundant signing: Remove obsolete or duplicate signatures at the sender or gateway when they push the useful signature past the limit.
A passing signature still needs the right domain
Any passing DKIM signature proves that signature is valid. For DMARC to pass through DKIM, at least one passing signature must also have a d= domain that satisfies the active relaxed or strict matching mode.
Why DMARC can pass when DKIM fails
A DMARC pass does not prove DKIM passed. DMARC passes when either a verified DKIM signing domain or a passing SPF MAIL FROM domain has the required relationship to the visible From domain. One authenticated domain with the required match is enough for DMARC to pass.
Example: DMARC passes through SPF despite a DKIM failuretext
Authentication-Results: mx.google.com; dkim=fail (body hash did not verify) header.d=example.com header.s=smtp1; spf=pass smtp.mailfrom=bounce@example.com; dmarc=pass header.from=example.com
Here SPF supplies the exact domain match, so DMARC passes even though the DKIM failure is real. Compare smtp.mailfrom with header.from, then check aspf in the applicable DMARC record. Fix the broken DKIM signature rather than classifying this combination as a Gmail display issue.
What to check before changing DNS
Use a short checklist before touching DNS. The goal is to prove whether the problem is cryptographic DKIM failure, DMARC domain matching, a signature-count limit, or a Gmail display issue. A broad domain health check is useful when you also want SPF, DMARC, DNS, and reputation signals in one pass.
- Header result: In desktop Gmail, open the received message, click More next to Reply, then "Show original". Read the Authentication-Results field added by mx.google.com.
- Selector key: Take d= and s= from the DKIM signature and confirm the key exists at s._domainkey.d. If the selector uses a CNAME, follow it to the public-key TXT record.
- Signing domain: Compare the DKIM d= domain, or header.d when present, with the visible From domain.
- Signature count: Check whether the useful signature is among Gmail's first five.
- Message mutation: Look for body hash did not verify after forwarding or outbound gateway processing.
- DMARC tags: Check adkim for DKIM matching and aspf when SPF supplies the DMARC pass, using the record applicable when Gmail received the message.
- Recipient spread: Send controlled test messages to several Gmail accounts and compare raw results. Use the same sender and content, and record any differences in routing or signature order.
A DNS-only DKIM checker confirms that a selector's public-key record is published and readable. It does not verify a particular message's signed headers or body. A valid record therefore does not override dkim=fail in Gmail's receiving results.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
If the selector record is valid and Gmail's trusted header still says dkim=pass, stop treating the summary as the main diagnostic. Check Google DKIM troubleshooting for Google Workspace setup, forwarding, TXT length, and signature-count guidance. For Google Workspace, a published key is only part of setup: use "Start authentication" in the Admin console to enable signing, then check a newly sent message.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
Alternative DMARC records: publish only one at _dmarc.example.comdns
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; adkim=s; rua=mailto:dmarc@example.com
Do not loosen policy on a summary alone
A Gmail summary that says DKIM failed is not enough reason to move p=quarantine or p=reject back to p=none. Investigate real failures using raw headers, aggregate reports and delivery evidence; fix sender authentication first. Review a temporary policy change only if legitimate mail is affected.
When it is a real DKIM failure
There are still cases where Gmail is correctly saying DKIM failed. The fastest way to separate real failure from display noise is to look for a bad signature, a missing DNS key, a broken selector, a truncated public key, or a message that changed after signing. Forwarders and outbound gateways can break DKIM when they alter signed headers or the message body.
|
|
|
|---|---|---|
Missing key | Selector not found | Publish the correct key at the selector name |
Wrong selector | NXDOMAIN | Update sender or DNS |
Changed body | Body hash did not verify | Apply required changes before DKIM signing |
Truncated key | Key parse error | Publish complete TXT strings within one record |
Too many signatures | Useful signature after fifth | Reduce redundant signing |
Missing signature | dkim=none | Enable outbound DKIM signing |
Temporary DNS retrieval error | dkim=temperror; lookup timeout or SERVFAIL | Restore DNS responses and retest a newly sent message |
Unrecoverable verification error | dkim=permerror; required signature data missing | Correct the signature or configuration identified by the receiver |
Key rotation mismatch | Signature fails against the published key | Publish a new selector before switching the signer; retain the old key for queued mail |
Common DKIM failures and non-pass results; receiver reason text varies.
How urgent is the Gmail DKIM warning?
Use raw headers and DMARC results to decide whether to act immediately.
Low
Monitor
The intended DKIM signature and DMARC both pass.
Medium
Investigate
DKIM verifies, but neither DKIM nor SPF supplies DMARC's required domain match.
High
Investigate promptly
The intended DKIM signature fails repeatedly or delivery is affected.
Unknown
Collect data
Only a screenshot or redacted header exists.
The message date matters too. If you changed the DKIM key or DMARC record after the message was sent, current DNS does not prove what Gmail evaluated at delivery time. Keep the original header sample, message timestamp, and relevant DNS history together. After a DNS change, compare authoritative DNS answers and allow cached records to reach their TTL before retesting a newly sent message. DKIM public keys do not expire automatically with age; an optional signature x= tag sets signature expiration, and mismatched keys during rotation are a separate problem.
How Suped fits the workflow
Suped's product helps when one-off header checks do not show whether the issue is isolated or repeating across real traffic. The workflow collects DMARC aggregate data, groups the sending source, compares SPF and DKIM outcomes, and alerts the team when a real failure starts.
Use Suped's DMARC monitoring to compare Gmail's one-message display with aggregate results by domain and sending source. Healthy DKIM and DMARC results support monitoring the display issue. A new source-level failure identifies traffic to investigate; use full message headers and DNS checks to establish the cause.
In DMARC aggregate XML, auth_results/dkim reports signature verification, while policy_evaluated/dkim reports DKIM's DMARC alignment result. Aggregate reports summarize traffic for a reporting period; they do not reproduce a particular message's Gmail summary or prove why its signature failed.
Manual Gmail review
- Scope: One message and one recipient at a time.
- Evidence: Raw headers, screenshots, message timestamps, and manual comparisons.
- Weak spot: Hard to prove whether failures are isolated or widespread.
- Best use: Confirming one suspicious Gmail display result.
Suped workflow
- Scope: All monitored domains and sending sources.
- Evidence: Parsed DMARC reports, source grouping, issue history, and alert history.
- Fix path: Issue detection with practical remediation steps.
- Best use: Ongoing authentication monitoring across a domain portfolio.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Keep the aggregate evidence beside the original Gmail header sample. If Gmail's summary is noisy but aggregate reports show healthy DKIM and DMARC pass rates, monitor rather than rush a DNS change. If Suped shows a new source failing, compare that source's raw headers and DNS configuration before choosing a fix.
Community reports of Gmail DKIM discrepancies
Best practices
Trust Authentication-Results before Gmail's summary when the two disagree on DKIM status.
Compare the visible From domain with the DKIM d= domain before changing DNS records.
Keep dated headers to compare Gmail's current DKIM result with earlier forwarding results.
Common pitfalls
Do not lower DMARC policy because one Gmail account shows a confusing DKIM summary.
Do not troubleshoot redacted headers when the issue depends on exact domain matching.
Do not confuse DKIM verification with DMARC's domain comparison in receiver summaries.
Expert tips
Send the same message to several Gmail accounts when a Gmail display issue is suspected.
Check the applicable DMARC adkim and aspf tags at receipt time, not just current DNS.
Compare raw verification with DMARC matching in reports before diagnosing DNS failures.
Expert view
An Email Geeks report describes a Gmail summary showing DKIM failure while the raw mx.google.com result records dkim=pass and dmarc=pass.
2025-02-07 - Email Geeks
Expert view
An Email Geeks report suggests that strict domain matching explains some summary discrepancies. This is a community explanation, not a confirmed description of Gmail's implementation.
2025-02-07 - Email Geeks
What to do next
Treat Gmail's DKIM fail summary as a prompt to inspect the raw header, not as proof that DKIM failed. If Gmail's trusted header says dkim=pass and DMARC passes, keep monitoring and document the sample. If the intended signature says dkim=fail, fix the selector, key, signer, relay path, or signature count before changing policy.
For ongoing checks, keep the intended signing domain and DMARC matching requirements documented for each sender. Suped's product turns repeated authentication failures into source-level issues with evidence and remediation steps.
Frequently asked questions
Trust the Authentication-Results field added by mx.google.com first. If it says dkim=pass, Gmail verified that DKIM signature. Match the reported domain and selector to the intended signature; a pass copied from an earlier ARC result is not Gmail's current verdict.
Yes. DKIM can verify while DMARC fails because no passing DKIM signing domain has the required relationship to the visible From domain and SPF does not supply a matching pass either. DMARC can also pass through SPF while DKIM fails.
A verified DKIM signature from a subdomain can satisfy DMARC under relaxed matching when it shares the From domain's organizational domain. Under strict matching, the signing domain must exactly match the visible From domain.
The message has more than one DKIM signature, with separate verification results. DMARC can pass when at least one checked DKIM signature passes and its d= domain has the required relationship to the visible From domain, or when SPF provides the required matching pass.
Remove it only after reviewing all senders. Strict DKIM matching is easy to break when third-party senders or subdomain signing are in use.
Compare the raw headers from each recipient, including the signature order. If Gmail's trusted results pass and delivery is normal, keep the samples and monitor. If one recipient shows a raw DKIM failure, investigate that message path.
