A valid DKIM signature can appear on unwanted or abusive mail. An attacker may obtain a legitimately signed message and redistribute it without changing the covered content. The signature can continue to verify because DKIM does not promise that each delivery is unique, requested or benign.
Understand what survives replay
RFC 6376 §8.6 describes replay abuse in which a message signed by a reputable domain is resent to many recipients. A valid signature establishes the signing domain's responsibility for covered content under DKIM's rules. It is not proof that the domain intended every subsequent delivery or that the recipient consented to receive it.
SMTP envelope recipients are not included merely because a visible To header is signed. A replay can retain the signed header while using different envelope recipients. A signed Date or Message-ID does not create a cryptographic one-delivery restriction. Expiration can constrain a time comparison but is explicitly not intended as an anti-replay defense in RFC 6376 §3.5.
Separate three incident hypotheses
First, a genuine signed message may have been redistributed unchanged. Second, an attacker may be using an authorized account or application to obtain newly signed abusive messages. Third, a private signing key may have been compromised. These explanations require different evidence and remediation. A DKIM pass alone cannot distinguish them.
Preserve raw samples from trusted receiver reports and compare signature values, signed content, message identifiers, creation times and delivery traces. Identical signatures and covered content across complaints support investigation of reuse, but do not prove its origin. New signatures over distinct abusive content raise questions about signer access and account control. Investigate authenticated submission logs and key access under your incident procedures.
Use a bounded illustrative case
In a hypothetical controlled test specification, a service would sign one message and a harness would deliver the same signed message to two authorized test inboxes with different SMTP envelope recipients. No such test was executed for this article. Both can verify the same signature if covered content and other verification conditions remain valid. The expected outcome illustrates why signature validity and uniqueness are separate. It is not a test of provider spam filtering and should not be expanded into unsolicited delivery.
Respond at the right layer
For an abused sending account, contain the account or application path and review submission controls. For suspected key exposure, follow key-compromise procedures and assess the delivery impact of revocation. For replay of previously signed content, combine signature analysis with rate, reputation, complaint and message-pattern signals. RFC 6376 §8.6 discusses reputation-based partial responses; none converts DKIM into a complete spam classifier.
Do not revoke a shared selector solely because a complaint includes a valid signature without investigating. Removing its public key can affect legitimate messages still awaiting verification and may not address how abuse entered the system. Conversely, do not dismiss credible key-exposure evidence because replay is possible.
Report assurance accurately
Use separate incident fields for authentication result, suspected abuse mechanism, account or key evidence and recipient impact. A DMARC pass can coexist with replay when an aligned signature remains valid. Authentication is useful evidence, but safe handling still depends on the receiving system's broader assessment. Close the incident with a supported cause and response, not with a blanket statement that valid DKIM proves the mail harmless.
Keep hypotheses separate in the incident record
Use the observations to choose the next investigation, not to declare a cause prematurely:
- Same signature and covered content seen repeatedly: investigate reuse and delivery traces; this does not alone prove who redistributed it.
- Distinct abusive messages newly signed through an account: review submission and application-access evidence.
- Credible secret exposure or unauthorized key access: invoke the key-compromise response, even if replay also occurred.
Record the evidence supporting each hypothesis and the remaining uncertainty. Check the legitimate-mail impact before retiring a shared selector; RFC 6376 §8.7 describes that limitation. No abuse traffic or delivery experiment was performed for this article.