DKIM replay attacks: how signed mail gets abused

DKIM was designed to prove a message came from your domain and was not altered. It was never designed to prove the message was sent to the person now reading it.

DKIM replay exploits exactly that gap, and it can damage your domain's reputation without anyone ever touching your servers.

How a replay works#

The attack has three steps:

1. Get one signed message. The attacker obtains a single legitimate message signed with your domain's DKIM key. Often they simply sign up for your service, trigger a notification, or send themselves something through a platform that signs as you.
2. Keep the signed parts intact. They do not modify the body or any signed header, so the signature stays valid.
3. Resend it at scale. They deliver the identical message to thousands or millions of recipients through their own infrastructure.

Every copy verifies as authentic DKIM from your domain. DMARC passes, because the DKIM signature aligns with the From domain. Receivers see a large burst of authenticated mail from you, and if recipients mark it as spam, that negative signal attaches to your domain.

Why DKIM allows this#

The envelope recipient (the RCPT TO in SMTP) is not part of the message, so DKIM cannot sign it. The To header can be signed, but nothing requires the To header to match the actual recipient; Bcc delivery and mailing lists send messages to people not listed in To all the time.

The DKIM signature also has no built-in notion of "use once." An optional x= tag sets an expiration time, and the t= tag records when the message was signed, but within the validity window a signature is equally valid on the first delivery and the millionth.

Why attackers bother#

Attackers replay messages for the same reason they forge anything: borrowed reputation. A domain with a strong history gets better inbox placement. If an attacker can make spam look like your mail, it inherits your standing until receivers catch on.

The content that gets replayed is often something the attacker could influence: a signup confirmation that echoes back a user-supplied name field containing a spam message, a shared document notification, or a support ticket auto-reply that quotes the original request. Any feature that lets an outsider put their text into a message your domain signs is a candidate.

Mitigations on the sender side#

None of these fully eliminates replay, but together they shrink the attack surface considerably.

Do not reflect untrusted content#

Review every transactional template that includes user-supplied text: names, company names, ticket subjects, comment previews, invitation messages. Constrain length, strip URLs where they are not needed, and avoid sending such text to addresses that have not been verified. An invite feature that lets anyone send a custom message from your domain to any address is a replay factory.

Sign the headers that pin context#

Sign and oversign To, Cc, Subject, Date and Message-ID. Oversigning To prevents an attacker from adding another To header above the signed one. It does not stop replay to Bcc-style recipients, but it makes the message's intended recipient part of the signed content, which some receivers use as a signal when the visible To does not match the actual recipient.

Use short signature expiration#

Setting x= to a few days limits how long a captured message remains valid. Messages that legitimately take longer than that to verify are rare. This does not stop an attacker who replays quickly, but it caps the window, and it makes old harvested messages useless.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; t=1790000000; x=1790345600; ...

Be careful: RFC 6376 allows verifiers to treat a signature past x= as invalid, so do not set it too short for mail that can sit in retry queues.

Rotate keys#

Rotation does not stop an active replay, but revoking a key (publishing p= empty) invalidates every message signed with it, including those an attacker is still replaying. If you detect an ongoing campaign, rotating to a new selector and revoking the old one shuts it down at the cost of breaking verification for your own recent in-flight mail.

Separate streams by subdomain or selector#

If high-risk features, such as user invitations, sign with a distinct subdomain or selector, a replay campaign damages that stream's reputation rather than your password resets and receipts.