How to Detect and Respond to DKIM Replay Attacks
Summary
A practical guide to identifying DKIM replay attacks, distinguishing them from relays and spoofing, and responding with DMARC enforcement, message-level evidence, old-key removal, and Amazon SES monitoring.
Key points
- A replayed, unchanged message can retain a valid DKIM signature, allowing DMARC to pass even when SPF fails.
- An unfamiliar IP and DKIM-passing DMARC report indicate an anomaly, not proof of replay; confirm by matching a message you sent to one received by an unintended recipient.
- Rotating a DKIM key does not invalidate messages signed with the old key. Removing its DNS public key after in-flight mail clears closes that replay window.
- With BYODKIM, the domain owner can remove an old selector’s TXT record; Easy DKIM is managed by Amazon SES and does not offer immediate deletion of a specific key.
- Correlate Amazon SES per-message delivery events with DMARC aggregate reports to identify DKIM-passing volume not accounted for by your sending activity.
- Inventory legitimate senders, align them with SPF and DKIM, and advance DMARC from monitoring to quarantine and then rejection; harden SPF only after the inventory is complete.
Article Details
- Defense Focus
- Detect and confirm DKIM replay, distinguish it from legitimate relaying or ordinary spoofing, and limit the replay window through DMARC enforcement and removal of retired DKIM keys.
- Detection Methods
- Compare DMARC aggregate report volume for DKIM-passing messages from IP addresses outside the SPF record with Amazon SES delivery events for the same From domain and time window.
- Confirm suspected replay with message-level evidence by matching a message sent by the organization to a copy received by someone the organization did not address; rule out legitimate relays and gateways.
- Review DMARC rua reports for unfamiliar source IPs, unusually high DKIM-passing volume, and recipient domains not associated with normal sending.
- Check fresh DKIM-Signature headers to verify that the sender signs only with the current selector.
- Monitor DNS queries for selectors that have been rotated away from; a spike in lookups can indicate attempted use of a retired selector.
- Request full headers from recipient organizations when needed to confirm replay and support an abuse report.
- Data Sources
- DMARC rua aggregate reports, including source IP, message counts, SPF results, and DKIM results
- Amazon SES per-message Send, Delivery, Bounce, and Complaint events, tagged with the From domain
- DNS query logs for DKIM selectors
- Full message headers from recipients
- SPF records and current DKIM-Signature headers
- Rule Types
- Amazon CloudWatch Logs metric filter for DNS queries to rotated DKIM selectors
- Amazon CloudWatch alarm for elevated queries to a retired selector
- Platforms
- Amazon SES
- Amazon Route 53
- Amazon CloudWatch Logs
- Amazon EventBridge
- Amazon Data Firehose
- AWS Lambda
- AWS Identity and Access Management (IAM)
- Defensive Actions
- Inventory legitimate senders, mailing lists, relays, and security gateways; align legitimate senders with SPF and DKIM.
- Enforce DMARC by progressing from p=none to p=quarantine to p=reject, reviewing rua reports at each stage; use pct to ramp enforcement gradually if needed.
- Harden SPF to -all only after completing the sender inventory.
- After in-flight email has cleared, remove the old DKIM public key from DNS; for BYODKIM, delete the old selector's TXT record.
- Set short DNS TTLs on DKIM records and enable DNS query logging for rotated selectors.
- Report the source IP to its hosting provider with DMARC evidence; if the IP belongs to AWS, use the AWS abuse process.
- Investigate possible capture points, including compromised mailboxes, mailing lists, forwarding rules, and newsletter subscriptions.
- Restrict Amazon SES sending authorization to specific IAM principals; scope any automated DNS changes to the required hosted zone and record.
- Gate automated key removal on confirmed-replay criteria, test it on a non-production domain, and prefer alarm-to-human handling when appropriate.
Vendors
Products
Amazon CloudWatch Logson your DKIM records so that changes propagate quickly; and enable DNS query logging with an Amazon CloudWatch Logs metric filter that watches for queries to a selector that you’ve rotated away from.Amazon Data FirehoseSES event publishing) that streams per-message events (Send, Delivery, Bounce, and Complaint) to Amazon Data Firehose or Amazon EventBridge (see Add an event destination), tagged with the From domain.Amazon EventBridgethat streams per-message events (Send, Delivery, Bounce, and Complaint) to Amazon Data Firehose or Amazon EventBridge (see Add an event destination), tagged with the From domain.Amazon Route 53Use Amazon Route 53 to set short DNS time-to-live values (TTLs) (for example, 300 seconds) on your DKIM records so that changes propagate quickly; and enable DNS query logging with an Amazon CloudWatch Logs metricAmazon Simple Email Service (SES)You also learn how you can use Amazon Simple Email Service (Amazon SES) to detect and respond to this activity faster.AWS LambdaYou can automate that removal by using an Amazon CloudWatch alarm that starts an AWS Lambda function to call the Route 53 API and retire an old selector’s record.IAMtheir own, so use identity-level policies to limit sending to specific AWS Identity and Access Management (IAM) principals.