What a DKIM Result Says About a Delivered Message

What the receiving system checks

A sending system creates a DKIM signature using a domain under its control. The signature covers selected message headers and, typically, the body. The receiving system uses information associated with the signing domain to check whether the signed parts still match. A pass means that this check succeeded for that system and that message as received.

The result is usually recorded in a receiving-side authentication-results header or shown in a message’s security details. The signing domain is useful context: it identifies the domain associated with the signature, which might not be the same as the visible From address. DKIM verifies a signature; it does not, by itself, establish that the visible sender is genuine.

Why a pass is not an inbox receipt

Authentication and delivery are related but different stages. A system may verify DKIM and then apply its own spam, policy, or mailbox-handling decisions. The message could be accepted and placed in a folder, quarantined, rejected for another reason, or handled in another way. A DKIM result does not report that final destination.

Likewise, a DKIM failure does not by itself prove that a message is malicious or that it was rejected. A receiving system considers its own policies and other available signals. Treat a pass or fail as one piece of evidence, not as a delivery receipt or a complete verdict on the message.

Forwarding and edits can change the result

A forwarded message may arrive with its original signed content intact, but forwarding services can also alter a message. For example, a service might add text to the body, change a signed header, or reformat content. If a change affects a part covered by the signature, the receiving system may be unable to verify it.

This means the same original message can show different DKIM outcomes at different points in its journey. A failure after forwarding does not necessarily mean the original sender’s system created an invalid signature. Check whether the message was forwarded, modified, or relayed before drawing that conclusion. The exact effect depends on what was signed and what changed.

Read the surrounding results

Look at the complete set of receiving-side authentication results rather than isolating the DKIM line. If available, review SPF and DMARC results too; they answer different questions and are interpreted by the receiving system. Pay attention to the domains shown in those results and whether they relate to the visible From address. A DKIM pass from a domain that does not align with the From domain may not have the same significance as an aligned result for DMARC evaluation.

Then compare those details with the delivery report or other status information from the receiving service. Look for whether the message was accepted, deferred, or rejected and for any stated reason. A report may not reveal every mailbox-placement decision, so avoid treating acceptance as proof that the message appeared in the recipient’s inbox.

A practical example

Suppose [sender@example.com] sends a message to [recipient@example.com]. The receiving system reports DKIM pass for a signing domain, but the recipient cannot find the message in the inbox. The pass confirms that the signature check succeeded at receipt; it does not locate the message. The recipient can check other folders or quarantine information available to them, while the sender reviews the receiving service’s delivery report for an acceptance, rejection, or delay.

If the report shows acceptance but the message is missing, the available evidence supports acceptance by that service—not a confirmed inbox placement. If a forwarded copy later shows DKIM fail, compare it with the original and consider whether forwarding changed signed content before concluding that the original message was incorrectly signed.

Original recipient: [recipient@example.com]
DKIM: pass for [signing-domain.example]
Delivery report: accepted by receiving service
Next check: recipient folders and any available quarantine or status details

A short check before you conclude

When investigating one message, preserve the original if possible and examine the receiving-side details for that copy. Results can differ across receiving systems, and a forwarded copy may not have the same result as the original. Use the report and authentication details together; neither necessarily provides a complete account of what happened after receipt.

Confirm your interpretation by matching the report to the recipient and message in question, then checking the destination information available from that receiving service. If the report is unclear, ask its administrator or provider what its status means. Do not infer inbox delivery from DKIM alone, and do not infer malicious intent from a failure alone.

• Identify which receiving system recorded the DKIM result and the signing domain it names.
• Check the other authentication results and the delivery report for the same message.
• Note whether the copy was forwarded or changed, and confirm the recipient’s available folder or quarantine information.