DKIM replay is the reuse of a legitimately signed email so it continues to appear authenticated after the attacker modifies the lure elsewhere in the delivery chain. The signature may still validate, but the message can be repurposed to support phishing or fraud.
Expanded Definition
DKIM replay is a message reuse problem, not a broken-signature problem. A valid DKIM signature can still verify after an attacker forwards, duplicates, or repurposes the email content elsewhere in the delivery chain, especially when the lure depends on brand trust rather than message freshness. The practical concern is that DKIM authenticates the signed headers and body as delivered, but it does not by itself guarantee that the message is original, time-bound, or safe to reuse. In NHI and email security operations, this makes DKIM one layer of sender validation rather than a complete anti-abuse control. Definitions vary across vendors when replay is discussed alongside DMARC and domain alignment, so practitioners should treat it as a message integrity gap within broader abuse prevention, not as a DKIM failure alone. NIST Cybersecurity Framework 2.0 frames this kind of issue within protective controls around communications and trust relationships, while email-domain controls often require additional policy decisions beyond signature verification. The most common misapplication is assuming a valid DKIM result means the email is trustworthy, which occurs when teams ignore reuse of the signed content after initial delivery.
Examples and Use Cases
Implementing anti-replay handling rigorously often introduces filtering and correlation overhead, requiring organisations to weigh tighter fraud detection against the risk of blocking legitimate forwarded mail.
- A phisher captures a vendor’s signed invoice notice and republishes it with a new payment destination, while the original DKIM signature still validates.
- An attacker reuses a marketing or notification email from a trusted domain as a lure, attaching a credential-harvesting link in a downstream channel that users trust.
- A service desk receives a copied security alert that was originally signed by a legitimate sender, but the attacker has modified the call to action outside the signed content.
- Security teams review whether replayed messages are being accepted because the receiving system checks only signature validity and not message context, timestamps, or policy signals.
- Operational guidance from the Ultimate Guide to NHIs helps teams connect message abuse to broader identity trust problems, especially when automated senders are involved. For standards context, teams often compare this with NIST Cybersecurity Framework 2.0 controls for protective communications and monitoring.
Why It Matters in NHI Security
DKIM replay matters because modern fraud campaigns often exploit trusted automated senders, not just compromised inboxes. When a service account, notification platform, or signing workflow is abused, the result can be a legitimate-looking message that survives basic authentication checks while carrying deceptive intent. That is especially dangerous in environments where secrets, API keys, and other NHI-linked assets trigger downstream messages and workflows. NHI Mgmt Group notes that Ultimate Guide to NHIs reports 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which underscores how often trust is lost through automation rather than human accounts. This is why replay concerns should be evaluated alongside sender governance, message provenance, and post-delivery abuse monitoring, not only email authentication pass or fail states. The issue also aligns with broader defensive guidance in NIST Cybersecurity Framework 2.0, where detection and response must account for trusted-channel abuse. Organisations typically encounter the operational impact only after a signed lure is reused in a fraud attempt, at which point DKIM replay becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers abuse of trusted non-human message flows and related secret-driven impersonation. |
| NIST CSF 2.0 | PR.DS-2 | Protects data in transit, including authenticated email content that may be replayed. |
| NIST CSF 2.0 | DE.CM-1 | Monitoring detects anomalous reuse of trusted messages across channels or time. |
Review message-sending identities, signing keys, and reuse paths for abuse and replay exposure.
