An AWS walkthrough published November 2 is SES-shaped, but the mechanism inside it is protocol-level, and it lands on exactly the operators this site writes for: anyone running their own mail — a community list, a clinic's outbound MX, a co-op listmonk — inherits every property of DKIM, including this one.

The attack, precisely

DKIM verifies one thing: the message body and selected headers didn't change between the signer and the receiver. It says nothing about whether the sender was the signer. That gap is the whole attack:

  1. Your system sends a legitimate message, signed with your DKIM key — a receipt, an invoice, a moderation notice.
  2. An attacker obtains one copy. Public list archives, .forward rules, list digests, a phishing-harvested mailbox — any of them works.
  3. The attacker resends that message, byte-identical, from infrastructure you have no relationship with, to recipients you never sent to.
  4. Every receiving server fetches your public key from DNS and finds a valid signature. SPF fails for the attacker's IP. DMARC requires only one aligned SPF-or-DKIM pass, so DMARC passes, and the mail delivers as authenticated mail from your domain.

Nothing was forged. Every check that fired, fired correctly. What the attacker stole is sender capability — the right to make mail appear to come from you, at volume, into whatever filters trust alignment.

The two defenses people reach for, and why they don't work

Key rotation alone doesn't stop it. A message signed before rotation keeps verifying for as long as the old selector's DNS record stays published. Most rotation guides tell you to publish the new selector and move on; the stale selector records — the sel1._domainkey TXT rows nobody removes — keep validating old-signature replays for exactly as long as they exist. Cleanup is not optional: after rotation propagates and your mail volume confirms the new selector, remove the old ones, and keep an inventory of which selectors are live. The AWS post calls this the DNS cleanup step most rotation guidance leaves out, and it is right to call it out.

P=reject doesn't stop it. Reject fires on authentication failure, which is spoofing. The replay attacker authenticates perfectly well — with your signature. A DMARC policy is a filter against people without your key; it has no opinion about a message you really did sign.

The actually workable part: triage and proof

For a self-hosted operator, the practical work is in the reports you already receive:

  • DMARC aggregate (rua) reports carry source IP, volume, and per-check results. The replay signature: rows where DKIM passes aligned with your d= from IPs you don't own, at volumes above your real sending, to domains you don't correspond with. The ordinary-spoof signature is DKIM fail — if DKIM passes from an unknown IP, you are not looking at classic spoofing.
  • Proof needs message-level matching. Aggregate counts can't prove a replay — a mailing list you forgot about forwards the same way. The confirmation is one specific message you sent matched to one that reached someone you never addressed. If you can't produce that match, treat the traffic as unconfirmed and respond with monitoring, not key surgery.
  • Distinguish relay from replay before touching anything. A signing-valid signature on an unknown IP has three explanations — a documented relay you forgot (signature survives relays by design, which is the protocol working), replay abuse, or (rare) a quirk worth your own logs. Rotating keys, or tearing a selector out, in response to a legitimate relay you simply hadn't inventoried is self-inflicted mail loss.

For a listmonk or Postfix operator the one addition worth having over the SES workflow: you own the outbound logs, so message-level matching is an grep across your own delivery records rather than a support ticket.

Why this belongs in a sovereignty newsletter at all

None of this is an argument for managed email. It is the opposite: the replay class only matters at all because everyone's authentication works the same way, self-hosted or rented, and a self-hosted operator who understands their own rua reports and DNS has materially better tools for the message-level evidence step than a hosted-SES tenant does. The defense in both cases is the same boring inventory — which selectors are live, which relays are documented, what your normal sending volume looks like — and on infrastructure you run, that inventory is a file you control.

Sources: AWS Security Blog: Beyond DKIM key rotation — understanding email replay attacks (published November 2, 2026); DMARC aggregate report fields per RFC 7489; selector mechanics per RFC 6376.