SPF checks whether the sending server is authorized, DKIM verifies that the message was signed and not altered, and DMARC combines those signals to enforce alignment with the visible From domain. In a replay attack, a previously valid DKIM signature can remain intact, so the message may pass all three even though the content is malicious and the delivery path is abused.
Why SPF, DKIM, and DMARC can all pass while the email is still unsafe
SPF, DKIM, and DMARC each answer a different question about message legitimacy, but none of them proves the message is trustworthy in context. A replayed email can preserve a valid DKIM signature and still reuse an old, maliciously crafted message body, while SPF and DMARC may remain satisfied because the delivery path and visible domain checks are still consistent.
The practical failure is that these controls validate parts of the message envelope and signing relationship, not whether the content is current, intended, or benign. That means an attacker can abuse a previously legitimate message, forward chain, mailing list, or captured payload and still land a message that looks authenticated at the protocol layer.
Two useful distinctions matter here: SPF is about whether the sending server is authorised for the domain, while DKIM is about whether the message was signed and left intact. DMARC then combines those signals with alignment to the visible From domain, which is why a message can satisfy all three checks and still be malicious if the original signed content is replayed rather than forged.
What replay actually exploits in email authentication
Replay works because email authentication is not the same as freshness or intent verification. If an attacker obtains a message that was once validly signed, that signature can remain cryptographically correct even when the same message is resent later in a different context, to a different recipient, or as part of a social engineering sequence.
This is especially important when defenders treat pass results as a trust decision instead of one signal in a broader assessment. The security issue is not that SPF, DKIM, or DMARC failed, but that they were never designed to prove the sender still controls the content, that the message is timely, or that the recipient should act on it.
For that reason, message authentication should be read alongside delivery patterns, sender reputation, timestamps, reply-to changes, unusual forwarding behaviour, and whether the content references stale but persuasive business context. Authentication tells you the message can be traced to a legitimate path or signature, not that the action requested by the email is safe.
Risk and Threat Considerations
Replayed email creates a trust gap that is easy to miss because the message can appear fully authenticated while still carrying malicious instructions or links. The risk is higher where responders overvalue pass/fail authentication results and ignore whether the content is being reused out of context, especially in phishing, business email compromise, and invoice fraud patterns.
Failure mechanism: An attacker reuses a previously valid message or signed payload, preserving the DKIM signature and satisfying envelope checks, while delivering content that is no longer trustworthy in the current situation.
Impact: Users and mail filters may accept the message as legitimate, allowing fraud, credential theft, or harmful link clicks to proceed under the cover of apparently successful authentication.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication, and Access Control | Message trust depends on authenticated sender relationships and access paths. |
| DE.CM-1 — Monitoring for Anomalies and Events | Replay abuse is exposed by anomalous message timing, routing, and reuse patterns. | |
| Recommendation — Validate sender trust decisions with layered authentication and authorization checks. Monitor mail flow for reused content, unusual forwarding, and sender anomalies. | ||
| CIS Controls v8 | 8.6 — Collect Audit Logs | Email replay and abuse are easier to spot when message flow and authentication events are logged. |
| 9.2 — Use Secure Email and Web Browser Protections | Email replay often becomes harmful when users are delivered malicious content through trusted mail channels. | |
| Recommendation — Log mail authentication outcomes and delivery events for replay investigation. Harden email handling and filtering to reduce trusted-delivery abuse. | ||
| MITRE ATT&CK | T1566 — Phishing | Replayed authenticated mail is a delivery method for phishing and social engineering. |
| T1114 — Email Collection | Replay requires access to previously obtained email content or message streams. | |
| Recommendation — Hunt for phishing messages that reuse legitimate-sounding sender and content patterns. Investigate whether attackers are capturing and reusing legitimate email content. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | The replay problem often intersects with abuse of trusted mail-related credentials or tokens. |
| Recommendation — Rotate and constrain credentials that can be used to access mail workflows or send paths. | ||
Practitioner Guidance
What to verify: Treat “passed SPF, DKIM, and DMARC” as necessary but not sufficient. Verify whether the message is fresh, whether the sender action is plausible for the current business process, and whether any forwarding, mailing list, or archival replay path could have preserved an older message unchanged.
Decision rule: If the email is authenticated but the request is unusual, time-sensitive, or financially consequential, route it through a higher-trust verification path rather than relying on protocol pass results alone. The more the message depends on urgency or authority, the more you should assume replay or reuse is part of the abuse pattern.
Practitioner takeaway: Email authentication proves origin and integrity for a message instance, not legitimacy of intent, so the operational question is whether your review process can detect reused content before the user acts on it.
Related resources from NHI Mgmt Group
- What is the difference between SPF, DKIM, and DMARC in email authentication?
- Why do SPF, DKIM, and DMARC all matter for enterprise email security?
- Why do SPF, DKIM, and DMARC fail against email thread hijacking?
- How should security teams handle authenticated phishing that passes SPF, DKIM, and DMARC?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
