Beyond DKIM key rotation: understanding email replay attacks

What it is

An AWS Security Blog post on DKIM replay: an attacker obtains one genuinely signed message and resends it unchanged from their own servers. DKIM passes, so DMARC passes even at p=reject. The post's practical value is the triage logic, the ordering of remediation steps, and an SES-specific detection method.

How it works

The attacker gets a copy through a mailing list subscription, a compromised mailbox, a list archive, or a forwarding rule. SPF fails because the sending IP is not yours. DMARC needs only one of SPF or DKIM to pass with alignment, so the message is delivered as authenticated mail from your domain. The attacker cannot alter content, only reuse your reputation and reach.

Triage of a DMARC rua row such as source IP: 203.0.113.45 | count: 4,200 | SPF: fail | DKIM: pass (d=yourdomain.com):

flowchart TD
    A[DKIM pass, unknown IP] --> B{Source and volume}
    B -->|Known provider, tracks your sending| C[Uninventoried relay]
    B -->|No relationship, high volume, new recipient domains| D[Possible replay]
    B -->|DKIM fail| E[Ordinary spoofing]
    D --> F{Message-level match?}
    F -->|Yes| G[Confirmed replay]
    F -->|No| H[Unconfirmed anomaly: enforce and monitor, keep keys]

Aggregate counts alone do not prove a replay. You need a message you sent matched to a copy that reached recipients you did not address.

Preconditions / Affected

• Any domain whose old DKIM public key is still published after rotation. Every message signed with it stays replayable while the record exists.
• Domains at p=none are the common case and must reach enforcement first.
• BYODKIM senders can delete a selector's TXT record on demand. Easy DKIM senders (CNAMEs to AWS-hosted keys) cannot delete a specific key immediately.

What to do

The page's ordered procedure:

1. Confirm it is a replay with message-level evidence.
2. Reach enforcing DMARC: inventory senders, align them, then move p=none, p=quarantine, p=reject, reviewing rua reports for typically a week or two per stage. Use pct to ramp up.
3. Move SPF to -all from ~all, only after the sender inventory is complete.
4. Check the DKIM-Signature header of a fresh message to confirm only the current selector is used.
5. Report the source IP to its hosting provider with DMARC evidence (AWS abuse process if the IP is AWS).
6. Find the capture point (mailbox, list, forwarding rule, subscription).
7. After in-flight mail clears, remove the old public key. For BYODKIM, delete the old selector's TXT record.

SES detection:

• Create a configuration set with an event destination streaming Send, Delivery, Bounce and Complaint events to Data Firehose or EventBridge, tagged with the From domain.
• Add rua=mailto:dmarc-reports@yourdomain.com to the DMARC TXT record.
• Signal: DKIM-passing volume from IPs outside your SPF record that exceeds the SES delivery events for that From domain in the same window.
• Restrict SES sending authorization to specific IAM principals. It does not stop external replay.
• Set DKIM record TTLs short in Route 53 (for example 300 seconds). Enable DNS query logging with a CloudWatch Logs metric filter on queries to a rotated-away selector, as an early indicator.
• Optional automation: CloudWatch alarm to Lambda to Route 53 API to retire the old record. Scope the role to the one hosted zone and record. The post says alarm-to-human is safer for most teams, and automation should be tested on a non-production domain.

To get message headers for an abuse report, contact top recipient domains from your rua reports (often .gov and .edu) and ask for a sample with full headers. Providers ask for headers that the victim domain does not have.

Caveats

• Easy DKIM has no on-demand key deletion. The post offers early detection, receivers' duplicate-message throttling, and the IETF DKIM2 effort (replay resistance, not yet available) as the defenses.
• Removing the old key only affects mail still in transit. Delivered mail no longer needs the key.
• Key removal is for confirmed replay only. For unconfirmed anomalies, start with enforcement and monitoring.
• An incorrect DNS change can have wide effect, and -all hard-fails any unlisted legitimate source.