Recent observations show that simply rotating a DKIM key does not eliminate unauthorized email distribution. Attackers can capture a legitimately signed message and resend it unchanged, causing the signature to validate on any downstream server. This matters to AI, cloud, DevOps, and security engineers because it undermines domain reputation, bypasses DMARC reject policies, and can flood recipients with trusted‑looking spam.
How DKIM Replay Attack Works
DKIM guarantees that specific parts of an email remain unaltered between the signer and the receiver. The signer uses a private key; receivers retrieve the matching public key from DNS to verify the signature. Because the verification checks only the byte‑for‑byte integrity of the message, a valid signature remains valid wherever the message travels.
In a replay scenario, an attacker obtains a copy of a legitimate outbound email—perhaps from a mailing‑list subscription, a compromised mailbox, or a forwarding rule. The attacker then resends the exact message from their own infrastructure to new recipients. Each receiving server fetches the public key from DNS, sees the signature intact, and marks DKIM as pass. SPF fails because the sending IP is not authorized, but DMARC passes because it requires only one of SPF or DKIM to succeed with alignment. Consequently, the message is delivered as authenticated mail from the original domain, despite the attacker’s involvement.
Identifying Replay vs Legitimate Relay vs Spoofing
When a DMARC aggregate report shows an unfamiliar source IP with DKIM: pass, three explanations exist:
- Legitimate relay: an undiscovered mailing list, forwarder, or security gateway that preserves the signature. The IP typically resolves to a known provider and the volume matches expected sending patterns.
- Replay abuse: an attacker redistributing a signed message. The IP has no business relationship, often generates unusually high volume, and targets domains the sender has not contacted before.
- Ordinary spoofing: a forged message without a valid signature, which would appear as
DKIM: fail. Therefore, a passing DKIM from an unknown IP is rarely simple spoofing.
Aggregate counts alone cannot prove a replay. Practitioners need message‑level evidence—matching a known outbound email to a received copy sent to unintended recipients. Absent that evidence, the activity should be treated as an unconfirmed anomaly and addressed with broader enforcement steps.
Mitigation Steps Using SES and DNS Cleanup
Before any key changes, verify that the domain’s DMARC policy is set to p=reject. Many organizations remain at p=none, which only monitors without enforcement. Once enforcement is confirmed, consider the following actions:
- Enable Amazon SES publishing of DMARC forensic reports to obtain granular message data that can reveal replayed payloads.
- Rotate the DKIM key and ensure the new selector is live, but also delete the old selector’s DNS TXT record after confirming no legitimate services still rely on it. The source notes that most rotation guidance omits this cleanup step.
- Update monitoring to flag high‑volume
DKIM: passevents from IPs outside the known sending range, especially when recipient domains differ from the usual set. - Maintain an inventory of all third‑party relays that legitimately preserve DKIM signatures, and document their expected traffic patterns.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Key rotation alone does not stop a DKIM replay attack. Engineers must enforce a reject‑mode DMARC policy, clean up obsolete DKIM selectors, and augment monitoring to detect anomalous replay traffic. Leveraging SES‑generated reports can accelerate detection, while a clear inventory of legitimate relays reduces false positives. Continuous validation of DNS records and traffic patterns is essential to protect domain reputation and prevent unintended email distribution.