Skip to main content

DKIM Replay Problem Statement

Document Type Replaced Internet-Draft (dkim WG)
Expired & archived
Authors Wei Chuang , Dave Crocker , Allen Robin , Bron Gondwana
Last updated 2023-04-14 (Latest revision 2023-04-02)
Replaced by draft-ietf-dkim-replay-problem
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Additional resources Mailing list discussion
Stream WG state Adopted by a WG
Document shepherd (None)
IESG IESG state Replaced by draft-ietf-dkim-replay-problem
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


DomainKeys Identified Mail (DKIM, RFC6376) permits claiming some responsibility for a message by cryptographically associating a domain name with the message. For data covered by the cryptographic signature, this also enables detecting changes made during transit. DKIM survives basic email relaying. In a Replay Attack, a recipient of a DKIM-signed message re-posts the message to other recipients,while retaining the original, validating signature, and thereby leveraging the reputation of the original signer. This document discusses the resulting damage to email delivery, interoperability, and associated mail flows. A significant challenge to mitigating this problem is that it is difficult for receivers to differentiate between legitimate forwarding flows and a DKIM Replay Attack.


Wei Chuang
Dave Crocker
Allen Robin
Bron Gondwana

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)