Why does a Google DMARC report show DKIM fail?

What usually causes it?

The source is not in your authorized sender inventory

If source_ip does not match an approved mail system, do not assume it is a broken legitimate sender. Preserve the row, check the source with the service owner or your mail logs, and look for repeated volume. Aggregate reports are intended to give domain owners visibility into IP addresses sending on their behalf and their authentication outcomes, as RFC 9990 explains. The conclusion that an unmatched IP is unauthorized is an investigation inference, not a property the report can prove by itself.

An authorized sender is not signing with the expected key

When the source is legitimate, compare the reported DKIM domain and selector with that sender's configuration. DKIM verification uses the public key retrieved from the selector record, and RFC 6376 defines the d= signing domain and s= selector as inputs to that lookup. A missing, retired, malformed, or wrong-key record can make the sender's signature fail.

The message changed after it was signed

If a fresh message from the same service shows a verification failure, compare the message path and any downstream processing. DKIM signs selected headers and a hash of the canonicalized body; RFC 6376 specifies that the verifier recomputes the body hash. A footer, disclaimer, link rewrite, gateway, list, or forwarder can therefore break a previously valid signature. That causal mapping is an inference you confirm with the delivered message and Received headers.

The signature verifies but does not align

If the message's verifier result is dkim=pass but the report's policy result for DKIM is fail, the signature may be valid without aligning to header_from. DMARC can still pass through aligned SPF. This is an alignment branch, not a verification repair; use the DKIM alignment troubleshooting guide after you confirm that distinction.

How do I diagnose the failure?

1. Preserve one complete report row and its reporting period

Save the compressed XML safely, then record report_metadata/email, the date range, source_ip, count, header_from, policy_evaluated, and every DKIM result under auth_results. RFC 9990 defines source_ip as the connecting address and count as the number of messages to which that policy evaluation applied. Redact report IDs and any data your incident process treats as sensitive before sharing it.

2. Match the source to an approved sender before editing DNS

Compare the IP and header_from with your sending-service inventory, outbound logs, and any documented source ranges. If the source is not recognized, investigate ownership and spoofing exposure. If it is recognized, identify the system that applied the listed selector. For a broader cross-layer header method, see email authentication failure troubleshooting.

3. Separate verification from DMARC alignment

Read both DKIM locations in the XML. A failed auth_results/dkim/result calls for message and key evidence. A passing verification result with failed policy_evaluated/dkim calls for alignment evidence. RFC 9990 explicitly keeps these fields separate, so a policy relaxation is not a substitute for discovering which condition the row records.

4. Inspect a fresh message from the same sender path

Send a new test through the affected service and preserve the receiver-added Authentication-Results, DKIM-Signature, and Received headers. RFC 8601 defines Authentication-Results as a receiver-added field, so use it from the receiver you are investigating rather than a copied header from an untrusted hop. Capture header.d, header.s, and the verification reason if present.

How do I fix it?

Repair an authorized sender's selector or public key

Only after the source and selector are confirmed, publish or correct the public key at the exact selector name the sender uses. A public lookup is useful for this narrow check: run the Palisade DKIM checker with the reported signing domain and selector. It cannot identify an IP owner, reconstruct an old report, or prove that a historical message was modified.

Move signing after the last content-changing hop

When fresh-message evidence shows post-signing modification, move DKIM signing after the footer, gateway, or rewrite that changes the message, or have the modifying system re-sign it. Do not add a body-length workaround or loosen DMARC policy as a substitute. If the verifier specifically says body hash did not verify, follow the focused DKIM body-hash repair guide.

Contain an unknown source without changing the policy first

For an unknown source, verify ownership and stop unauthorized use through the responsible system or incident process. Keep the current policy decision separate from this technical investigation. Changing p, adkim, or aspf may alter reporting or enforcement, but it does not repair a source that cannot produce an aligned authentication result.

How do I validate the repair?

Repeat the same sending path that produced the row. Confirm the fresh message has the intended header.d and header.s, the receiver's Authentication-Results shows the expected verification and alignment outcome, and the public selector record resolves. Then wait for a later aggregate-report period and compare the affected source's count and results. A passing public key lookup alone does not prove delivery behavior or that Google will report a particular outcome.

Check the reported selector, then address recurring report gaps

If the report names an exact DKIM domain and selector, check whether its public key is currently published before changing it.

Check a DKIM selector

The lookup cannot identify the reporting IP owner, inspect a past message, or explain a receiver's historical verification result. Keep those decisions tied to the aggregate row and a fresh same-path message.

If later report windows keep identifying unknown sources or failing legitimate senders, the work becomes recurring source-specific investigation rather than another one-time selector check. Palisade's DMARC Agent analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and detects when a domain appears ready for the next policy stage.

Start with Palisade

Palisade does not autonomously change DNS or DMARC policy, repair every sender, prove every future message will authenticate, or control a receiver's delivery decision. Your team reviews the evidence and applies changes.

Evidence

Sources and further reading

• RFC 9990: DMARC Aggregate Reporting
• RFC 6376: DomainKeys Identified Mail
• RFC 8601: Authentication-Results
• Palisade Docs: Domain overview