DMARC Analyzer

TL;DR

• A DKIM replay attack captures a legitimately DKIM (RFC 6376)-signed message from a high-reputation sender and re-sends the exact byte-for-byte body and signed headers to a new, attacker-chosen recipient list. The DKIM signature still verifies; DMARC alignment still passes; the message lands in the inbox under the original senders brand.
• RFC 6376 section 8.6 names replay as a known limitation of DKIM: a message signed once can be sent again to any number of recipients and still verifies. DKIM binds a signing identity to a message body and a selected set of headers, not to a particular recipient list.
• DMARC does not stop DKIM replay because the replayed message passes DKIM and IS aligned with the From: header. RFC 7489 sees a pass result and applies no protective policy.
• The 2024 gmail and yahoo bulk-sender requirements (mandatory RFC 8058 one-click List-Unsubscribe, 5000-per-day DKIM / DMARC threshold, 0.3 percent spam-complaint cap) were partly an industry response to DKIM-replay weaponisation at scale - they raise the operational cost of replay-based phishing but do not close the protocol gap.
• The seven canonical defences layer at the sender, the receiver, and the protocol: (1) short DKIM signing-key lifetimes, (2) short DNS TTLs on the DKIM public key, (3) following the DKIM2 drafts of the IETF DKIM working group, which are not yet published or deployed, (4) per-recipient-domain rate limiting at the original sender, (5) outbound-volume anomaly detection, (6) detection of duplicated signatures at the receiver, (7) sender-aligned ESP rate-limit policies.
• The most replay-attractive content classes are high-frequency transactional mail (order confirmations, password resets, account-recovery emails) and high-reputation marketing newsletters, because their content is predictable and their sending domains have established receiver-side trust.
• Detection happens primarily at the original sender, not at the receiver: a sudden volume disparity between your outbound logs and your DMARC RUA aggregate- report counts is the strongest replay signal.

1. Overview: what DKIM replay is and why it matters

DomainKeys Identified Mail (DKIM) authenticates email by attaching a cryptographic signature over the message body and a selected list of headers. The signing operation produces a DKIM-Signature header that includes a body hash (bh=), the list of signed headers (h=), the signing domain (d=), the selector (s=), and the signature itself (b=). The receiver fetches the public key at {selector}._domainkey.{domain}, re-computes the body hash, re-canonicalises the signed headers, and verifies that the signature matches.

The cryptographic guarantee DKIM provides is narrow but well-defined: the message body and the signed headers were produced by a holder of the private key under the named signing domain. The guarantee says nothing about who the message was intended for, when it was sent, how many copies were sent, or what envelope-recipient list it travelled under. DKIM was designed in 2007 (RFC 4871, superseded by RFC 6376 in 2011) to defend against unauthenticated forgery - an attacker who spoofs the From: but cannot sign. It was not designed to defend against authenticated replay - an attacker who inherits a legitimate signature and changes the envelope.

A DKIM replay attack exploits this gap. The attacker captures a legitimately signed message from a high-reputation sender (gmail.com, microsoft.com, paypal.com, a major bank, a major SaaS vendor) and re-submits the exact byte-for-byte message to a new SMTP envelope addressing the attackers desired victim list. Because the message bytes are unchanged, the DKIM signature still verifies at every receiver that respects DKIM. Because the original From: still aligns with the original signing domain, DMARC still passes. The message lands in the inbox under the original senders brand, even though the actual recipients are the attackers victim list rather than the originally-intended ones.

The attack matters because receivers learn over time to trust DMARC-passing mail from high-reputation domains. Mail that consistently authenticates and aligns is treated more leniently by spam filters, by anti-phishing engines, and by the receiver- side warning UI. Replay lets an attacker inherit that trust to deliver phishing, malware, or fraud lures inside the inbox under the umbrella of a trusted brand. The phishing yield per message is materially higher than for unauthenticated forgery because the brand indicator surfaces (BIMI logo, sender-name avatar, anti-phishing warning suppression) treat the message as fully legitimate.

RFC 6376 section 8.6 explicitly acknowledges this:

In this attack, a spammer sends a piece of spam through an MTA that
signs it, banking on the reputation of the signing domain (e.g., a
large popular mailbox provider) rather than its own, and then re-
sends that message to a large number of intended recipients.  The
recipients observe the valid signature from the well-known domain,
elevating their trust in the message and increasing the likelihood of
delivery and presentation to the user.

DKIM itself offers no mechanism against this. In practice, replay defence is a layered combination of sender-side and receiver-side controls; a protocol-level answer is what the IETF DKIM working group is drafting under the name DKIM2. This guide walks the canonical attack mechanics, the industry response, the per-vector taxonomy, the detection signals at the original sender, and the seven canonical defences.

2. The canonical replay attack mechanics

A DKIM replay attack follows a four-step sequence. Every step is mechanically simple; the value comes from the attackers operational discipline at scale.

1. Step 1: Capture a legitimately signed message. The attacker registers with the target signer and causes a high-reputation transactional or marketing message to be sent to an attacker-controlled address. Common capture paths include signing up for a free trial of a SaaS product (yields a welcome email, a verification email, a first-billing email), making a small purchase at a major retailer (yields an order confirmation, a shipping notification), opening an account at a major bank or fintech (yields onboarding mail, account-statement mail), or subscribing to a high-reputation marketing list (yields the recurring newsletter). The attackers goal is a complete copy of the SMTP DATA payload including the DKIM-Signature header, every signed header, the body, and the body boundary.
2. Step 2: Preserve the signed bytes verbatim. The attacker stores the captured message exactly. Every byte of the body, every signed header in the order the h= tag enumerates, every boundary delimiter, every character of whitespace inside signed headers. Any byte change inside the signed surface invalidates the signature, which is why the canonical attack does NOT modify the message body or signed headers - the attacker only manipulates the envelope and the bytes outside the signed surface.
3. Step 3: Construct a new SMTP envelope. The attacker submits the captured DATA payload to an attacker-controlled MTA (a rented VPS, a compromised botnet host, a poorly-secured third-party relay). The MAIL FROM envelope-sender and the RCPT TO envelope- recipient are set independently of the signed headers. Because DKIM does not sign the SMTP envelope, the receiver has no cryptographic record of who the original signer intended to send the message to.
4. Step 4: Fan out to the victim list. The MTA delivers the message to each address on the attackers victim list. Each receiver fetches the original signers public key, re-computes the body hash, verifies the signature, and records a passing DKIM result. DMARC sees DKIM=pass aligned with the From: domain and applies no protective policy. The message lands in each victims inbox carrying the original senders branding, BIMI logo, and accumulated trust.

The economic asymmetry is severe. The attacker pays for one signed message (a free trial, a sub-dollar purchase, a newsletter subscription) and gains the ability to deliver the same high-trust payload to as many victims as their MTA infrastructure can carry. The yield ratio is essentially unlimited; the only practical constraint is the receivers anti-spam volume controls, which the canonical replay attack sidesteps by distributing the outbound load across many attacker-controlled MTAs and obeying per-receiver rate limits.

3. Why DMARC by design does not stop replay

DMARC (RFC 7489) is a policy layer that instructs receivers what to do when SPF and DKIM both fail or are not aligned with the From: header. The threat model DMARC was designed for is unauthenticated From: spoofing: an attacker who sends a message claiming to be From: ceo@example.com but cannot sign with example.coms DKIM key and is not sending from a SPF-authorised IP. DMARC tells the receiver to quarantine or reject such messages based on the published policy.

A DKIM replay attack does not match this threat model. The replayed message:

• Passes DKIM: the signature bytes verify against the original signers public key.
• Passes DKIM alignment: the signing domain (d=) matches the From: domain because both come from the original legitimate message.
• Produces a DMARC pass: per RFC 7489 section 3, a DMARC evaluation passes when either SPF or DKIM passes AND is aligned. DKIM is sufficient on its own.
• SPF result is irrelevant: even though the replayed message arrives from an attacker-controlled MTA whose IP is not SPF-authorised, SPF failure does not gate DMARC when DKIM passes.

DMARCs evaluation logic is correct under its own threat model: a passing aligned DKIM result is exactly the signal DMARC was designed to trust. The mismatch is between DMARCs threat model (unauthenticated forgery) and the replay threat model (authenticated redirection). Closing the gap requires defences at layers DMARC does not address: sender-side rate limits, receiver-side detection of duplicated signatures, and a protocol change that the IETF is still drafting.

ARC (RFC 8617) does not close the gap either. An ARC chain records the authentication results seen at each hop that adds one, but RFC 8617 section 9.5 states that ARC is subject to the same replay attacks as DKIM: a complete, valid chain can be sent again to new recipients just like a signed message. ARC helps receivers with legitimate forwarding and mailing lists; it does not distinguish a replay from an ordinary delivery.

4. Historical disclosures and industry response

DKIM replay was understood as a theoretical attack class from the original RFC 4871 (2007) onward. The specification text in RFC 6376 section 8.6 explicitly names replay as a known limitation. For most of the 2010s the attack remained theoretically interesting but operationally minor: receiver-side anti-phishing engines were still learning to trust DMARC-passing mail, BIMI logo display was not widely deployed, and the receiver-side trust premium for a passing DMARC result was modest.

The risk environment shifted in the years that followed:

• The arrival of BIMI. Large mailbox providers began displaying brand-controlled logos for DMARC-passing mail, increasing the inbox-display payoff of a passing DMARC result.
• Campaigns observed in practice. Mail providers and security researchers began to describe publicly campaigns in which signed messages of well-known senders were sent again at scale.
• The topic returned to the IETF. The DKIM working group was rechartered; its charter lists replay among the problems that the original DKIM does not solve.
• February 2024 gmail and yahoo bulk-sender requirements. The joint announcement introduced three controls partly aimed at the replay attack class: RFC 8058 one-click List-Unsubscribe (so victims of replayed marketing mail can unsubscribe immediately, depriving the attacker of further-reuse value), a 5000-per-day threshold above which DKIM + DMARC are mandatory (so the receiver always has authentication data to attribute outbound replay back to the original signer), and a 0.3 percent spam-complaint cap (so a sender whose signed mail is being replayed at scale will see a measurable complaint rate increase and risk reputation loss).
• DKIM2 work at the IETF. The current drafts of the DKIM working group describe a successor to the present protocol; the charter of the group ties replay to the fact that the signature does not protect the envelope recipient (RCPT TO). Nothing is published or deployed yet.

The industry response is layered: economic pressure (gmail / yahoo policy), receiver-side detection, and protocol evolution (the DKIM2 work at the IETF). No single layer eliminates the attack class. Together they raise the operational cost of replay-based phishing campaigns without rendering them impossible.

5. Attack-vector taxonomy

Not every signed message is equally replay-attractive. Attackers select targets based on a multi-factor scoring function that weights receiver-side trust value, capture cost, content predictability, and the lifetime of the signature. The table below summarises the four canonical attack vectors:

The defence priority for a given sender depends on which vector is most likely to target that sender. High-frequency transactional senders (e-commerce, financial services, account recovery) should prioritise short key lifetimes and per-recipient-domain rate limiting. High- reputation marketing senders should prioritise RFC 8058 List-Unsubscribe compliance and outbound-volume monitoring. Mailing-list operators should prioritise short DNS TTLs and receiver-side replay-cache participation.

6. Detection signals at the original sender

Detection of an in-progress replay attack happens primarily at the original sender, not at the receiver. The receiver has limited visibility into whether a message is original or replayed; the original sender has perfect visibility into their own outbound logs and can compare them against the receiver-side counts reported in DMARC aggregate reports.

The canonical detection signals are:

• DMARC RUA aggregate-report volume disparity. The single strongest replay signal. A DMARC aggregate report from gmail.com reporting 50000 messages from your domain when your outbound logs show 10000 messages sent to gmail.com is a 5x volume disparity that almost certainly indicates replay. DMARC Analyzer surfaces aggregate-report counts per receiving domain in its Reports view; comparing the per-receiver counts against your outbound logs is the canonical detection workflow.
• Abuse@ and feedback-loop reports about messages you did not send. Users complaining about messages your domain did not send to them, or spam-trap addresses receiving messages whose contents you did send to legitimate recipients, both indicate replay.
• DMARC report source-IP entries outside your sending infrastructure. A <source_ip> in a DMARC report that does not match any of your authorised sending infrastructure but reports DKIM=pass is a hint, not proof: ordinary forwarding by a recipient server or a mailing list looks exactly the same. What points to replay is a large number of messages from such addresses. The attackers MTA appears in the source IP field because the receiver records the origin of the SMTP connection, even though DKIM verified successfully against your signing key.
• Inbox-placement degradation anomaly. Your legitimate outbound mail starts landing in spam at receivers where it previously inboxed, because your domain reputation is being eroded by attackers replaying your signed mail to spam-trap addresses.
• Sudden BIMI display loss. Some receivers (gmail.com in particular) will suppress BIMI logo display for domains whose reputation has degraded below a threshold, even if DMARC continues to pass. Loss of BIMI display without an obvious operational cause can indicate replay-driven reputation erosion.
• List-Unsubscribe abuse spikes. Sudden bursts of one-click unsubscribes per RFC 8058 from addresses that are not in your marketing list indicate that replayed marketing mail is reaching recipients you never opted in.

The DMARC RUA aggregate-report stream is the single most valuable forensic source because it includes the receiver-recorded source IP and per-IP message count. Reviewing the per-IP counts in DMARC Analyzers Reports view weekly is the recommended baseline operational practice for replay detection at any sender that produces transactional or marketing mail.

7. The seven canonical defences

Replay defence is a layered combination of sender-side controls, receiver-side controls, and protocol-level controls. No single defence eliminates the attack class; the combination materially raises the operational cost of replay-based phishing.

1. Short DKIM signing-key lifetimes. Rotate the DKIM signing key every 7 days (high-value senders) or every 30 days (standard transactional senders) instead of the conventional annual cadence. Every rotation invalidates every previously- captured signed message that depended on the rotated key, truncating the replay window to the key lifetime. See DKIM key rotation for the canonical dual-selector procedure.
2. Short DNS TTLs on the DKIM public key. Publish the DKIM public-key TXT record with a short DNS TTL (300 seconds rather than the conventional 86400). Short TTLs let you rotate the published key at any time without waiting for receiver caches to expire, supporting emergency rotation in response to a detected replay campaign.
3. Follow the protocol work. Watch the documents of the IETF DKIM working group. The present DKIM has no anti-replay mechanism: RFC 6376 states that the x= tag (signature expiration) is not intended as an anti-replay defence. The DKIM2 drafts aim at the missing protection of the recipient address, but they are not yet published or deployed.
4. Per-recipient-domain rate limiting at the original sender. Cap the outbound rate per recipient domain at levels consistent with your legitimate sending pattern. A transactional sender delivering 1000 messages per hour to gmail.com but suddenly producing 50000 per hour is being abused or has a configuration issue; either way the sender-side rate cap stops the abuse before the receiver sees it.
5. Outbound-volume anomaly detection. Instrument your outbound MTA to detect volume spikes that do not correlate with legitimate business activity. Most replay campaigns produce outbound spikes in the original-sender MTA logs (from the legitimate signing operation that captured the message) or in the DMARC RUA aggregate-report stream (from the replay fan-out at receivers).
6. Detection of duplicated signatures at the receiver. RFC 6376 section 8.6 notes that large receivers can detect an unusually large number of messages carrying the same signature within a short time, and that smaller receivers can gain similar knowledge through collaboration systems. A message recognised as a repetition is treated more sceptically. The sender benefits from this layer but does not control it.
7. Sender-aligned ESP rate-limit policies. If you send via an ESP (Mailgun, SendGrid, Amazon SES, Postmark, SparkPost), enforce ESP-level per- recipient-domain rate limits on your sending account. Most major ESPs offer per-domain throughput caps and abuse triggers; configuring them to match your legitimate sending pattern limits the damage if your ESP account or DKIM signing key is compromised.

Defences 1, 2 and 4 are sender-side and fully under the senders control. The fifth is sender-side instrumentation. The sixth is receiver-side and depends on receiver participation. The seventh is sender-side but delegated to the ESP. The third is observation for now: the protocol change is not available yet. A high-value sender should deploy at least defences 1, 2, 4, 5, and 7 today.

8. IETF work: from RFC 6376 to DKIM2

The IETF DKIM working group is working on a successor to the 2011 specification (RFC 6376). Its charter lists problems that the original DKIM does not solve, replay among them. There is no published "RFC 6376bis" with a finished anti-replay mechanism; the current drafts are called DKIM2.

The charter describes replay as exploiting the fact that the signature in the DKIM-Signature header does not cover the recipient address: an authorised user sends a message signed by a service to a cooperating recipient, who sends it on to addresses outside the original list, that is with different RCPT TO values, and nothing in the message shows it. The direction of the work is to tie the signature to the recipients the message was sent to.

Deploying such a change requires industry-wide coordination: signers must produce the new signatures and verifiers must check them. The documents are working drafts whose details may change before publication; mainstream adoption will take years. Until then, the defences remain the layered sender-side and receiver-side combination documented in section 7.

Operators planning for these changes should follow the mailing list of the IETF DKIM working group and read the current drafts from time to time, for example once a quarter.

9. Best practices

1. Rotate DKIM signing keys aggressively for high-reputation senders. Weekly rotation for domains whose mail carries significant receiver-side trust value (financial services, e-commerce, SaaS verification flows). Monthly rotation for standard transactional senders. The dual-selector procedure documented in DKIM key rotation guarantees zero downtime during rotation.
2. Publish DKIM TXT records with short DNS TTLs. 300 seconds rather than 86400. Short TTLs support emergency rotation if a replay campaign is detected against your domain.
3. Subscribe to all DMARC RUA aggregate reports. Configure rua= in your DMARC record to receive aggregate reports from every DMARC-respecting receiver. DMARC Analyzer ingests, parses, and surfaces the reports in its Reports view; the per-receiver volume comparison is your single best replay-detection signal.
4. Configure outbound-volume anomaly detection. Instrument your MTA or ESP to alert on volume spikes that do not correlate with legitimate business activity. Even a coarse threshold (alert when the hourly outbound rate exceeds 2x the 7-day moving average) catches most replay campaigns at the original sender before the receiver-side trust damage is done.
5. Enforce per-recipient-domain rate limits at the sender or ESP. Cap the outbound rate per recipient domain at levels consistent with your legitimate sending pattern. Major ESPs (Mailgun, SendGrid, Amazon SES) offer per-domain throughput caps; configure them.
6. Adopt RFC 8058 one-click List-Unsubscribe for marketing mail. Required since February 2024 by gmail and yahoo for bulk senders. Beyond compliance, one-click unsubscribe lowers the economic value of replayed marketing mail because victims can unsubscribe immediately when they see the replayed message.
7. Maintain a sub-0.3 percent spam-complaint rate. Required since February 2024 by gmail and yahoo for bulk senders. A sender whose signed mail is being replayed at scale will see a measurable complaint rate increase; watching the rate is a leading indicator of replay-driven reputation erosion.
8. Maintain accurate DMARC RUA aggregate-report retention. DMARC Analyzers Reports view retains aggregate-report data for the lifetime of the account. Long retention windows let you compare current per-receiver volumes against historical baselines to detect slow-burn replay campaigns that fan out over weeks rather than hours.

10. Common mistakes

• Assuming DMARC stops replay. DMARC explicitly passes replayed messages because DKIM passes and is aligned. The DMARC p=reject policy does not affect replay because the policy is never invoked for a passing message. Operators who rely on DMARC as the sole anti-phishing control are blind to the replay attack class.
• Long DKIM key lifetimes. Annual or longer rotation cadences create long replay windows. A 365-day-old signed message captured by an attacker remains replayable for the remainder of the signing keys lifetime.
• Long DKIM DNS TTLs. 86400-second TTLs delay emergency rotation by up to 24 hours, giving an attacker time to fan out the captured message before the new key propagates.
• Not monitoring DMARC RUA volume per receiver. Aggregate reports include per-receiver and per-source-IP message counts. Operators who only review the overall pass/fail rate miss the volume disparity that indicates replay.
• Permissive l= tag usage. The existing DKIM l= tag (body-length limit) lets a signer declare that only the first N bytes of the body are signed. Attackers exploit this by appending arbitrary content after the signed body boundary, producing a partial-body replay that adds phishing content to the original signed message. RFC 6376 section 8.2 explicitly warns against l= usage; production senders SHOULD omit the tag entirely.
• Ignoring the BIMI display loss signal. Loss of BIMI logo display at gmail.com without an obvious operational cause is a strong reputation- erosion indicator. Treat sudden BIMI loss as a replay-investigation trigger.
• Not enforcing per-recipient-domain rate limits at the ESP. Sending via an ESP without per-domain caps lets a compromised ESP account or DKIM key produce unbounded replay volume before the abuse is detected.

11. Troubleshooting suspected replay

• Symptom: spam complaints about messages you did not send. Confirmation that replay is happening against your domain. Capture the message headers from the complaining users, identify the Message-ID, and search your outbound logs for the original send. The time gap between the original send and the complaint is the replay-window duration. Rotate the DKIM signing key immediately to invalidate further replays of messages signed before the rotation.
• Symptom: DMARC RUA volume from a receiver exceeds your outbound logs by 2x or more. Very likely replay. Identify the source IPs in the DMARC report that do not match your authorised sending infrastructure and set aside known forwarders; the remaining ones are candidates for the attackers MTAs. Report the address ranges to their operators and consider rotating the DKIM signing key to truncate the replay window.
• Symptom: inbox-placement degradation without an obvious operational cause. Replay-driven reputation erosion. Review DMARC RUA aggregate reports for the past 30 days for unexpected source IPs. Engage with gmail postmaster tools and outlook smart network data service (SNDS) to gather per-IP reputation data.
• Symptom: BIMI logo no longer displays at gmail. Reputation erosion below the BIMI display threshold. Same investigation path as inbox- placement degradation. BIMI display will recover automatically once reputation recovers; the underlying replay cause must be fixed first.
• Symptom: List-Unsubscribe rate spike from addresses not in your marketing list. Replayed marketing mail reaching recipients you never opted in. Confirm by checking the unsubscribe receiver IPs against your outbound logs; mismatches indicate replay. Adopt aggressive DKIM key rotation for the marketing-sending subdomain.
• Symptom: DMARC reports showing DKIM pass from source IPs outside your sending infrastructure. At low counts this is usually mail forwarding; at high counts it is the typical trace of replay. Document the unexpected source IPs and their volumes and, once replay is confirmed, rotate the DKIM signing key. Consider engaging the operators of those addresses (hosting providers, ISPs) via their abuse contacts.

12. Frequently asked questions

What is a DKIM replay attack?

A DKIM replay attack is the practice of capturing a legitimately DKIM-signed message from a high-reputation sender (gmail.com, microsoft.com, paypal.com, a major bank or SaaS) and re-sending the exact byte-for-byte message body and signed headers to a new, attacker-chosen recipient list. The DKIM signature still verifies because the bytes are unchanged; DMARC alignment still passes because the original From: still aligns with the original d=. The receiver sees a DMARC-pass message from a trusted brand and applies the normal trust treatment, but the actual recipients are the attackers victim list rather than the originally-intended recipients. RFC 6376 section 8.6 names replay as a known limitation of DKIM.

How does a DKIM replay attack actually work?

The attacker captures a signed message from a target signer, preserves the signed bytes exactly, submits the captured DATA payload to an attacker-controlled MTA with a new SMTP envelope, and fans the message out to the attackers victim list. Each receiver verifies the original signers signature and treats the message as legitimate.

Why does DMARC not stop DKIM replay?

DMARC is a policy layer on top of SPF and DKIM. It instructs receivers what to do when SPF and DKIM both fail or are not aligned with the From: header. In a DKIM replay attack, DKIM does not fail and IS aligned with the From: header (because the replayed bytes are unchanged from the original). DMARC therefore sees a pass result and applies no protective policy. DMARC was designed to defend against unauthenticated forgery (the attacker spoofs the From: but cannot sign), not against authenticated replay (the attacker controls the envelope but inherits the signature from a legitimate signer). Closing the replay gap requires defences outside DMARC: sender-side outbound rate limiting, receiver-side detection of duplicated signatures, and a protocol change that the IETF DKIM working group is still drafting (DKIM2).

How can I detect DKIM replay attacks against my domain?

The single best signal is a volume disparity between your outbound logs and your DMARC RUA aggregate-report counts per receiving domain. Other signals include unexpected source IPs in DMARC reports, abuse complaints about messages you did not send, sudden BIMI display loss, and List-Unsubscribe spikes from addresses not in your marketing list.

Does DKIM key rotation prevent DKIM replay?

DKIM key rotation does not prevent replay attacks during the lifetime of any single signing key but it does bound the replay window. As long as a public key is published in DNS, any message signed by the corresponding private key can be replayed. Rotation truncates the replay window to the key lifetime: a key live for 90 days admits 90 days of replay; a key live for 24 hours admits 24 hours of replay. Aggressive rotation (weekly or daily for high-value senders) materially constrains the economic value of any single captured signed message, but it does not eliminate the attack class. Eliminating the class needs a protocol change, which the IETF DKIM working group is drafting as DKIM2; nothing is deployed yet.

What is the IETF doing about DKIM replay?

The IETF DKIM working group is drafting a successor to the 2011 specification (RFC 6376) under the name DKIM2. Its charter describes replay as exploiting the absence of a protected recipient address: a signed message can be sent again to recipients outside the original list and nothing in it shows that. There is no published RFC 6376bis with a finished anti-replay mechanism, and the DKIM2 documents are still working drafts. Until they are published and major receivers implement them, replay defence remains a layered combination of sender-side rate limiting, receiver-side detection, and short signing-key lifetimes.

Did the 2024 gmail and yahoo bulk-sender rules address DKIM replay?

Partly yes. The mandatory RFC 8058 one-click List-Unsubscribe, the 5000-per-day DKIM and DMARC threshold, and the 0.3 percent spam-complaint cap together raise the operational cost of replay-based phishing but do not close the protocol gap. The DKIM2 drafts of the IETF DKIM working group aim at the protocol-level fix.

Is DKIM replay only a problem for large brands?

No. Any domain whose DKIM-signed messages are obtainable by an attacker is replay-attractive, including small businesses that send transactional mail. The receiver-side trust premium attaches to any domain that has accumulated a history of DMARC-passing mail.

13. Related guides

• DKIM explained - the DKIM pillar covering DNS syntax, selectors, canonicalization, signature verification, and the broader DKIM deployment context. Start here if DKIM is new to you.
• DMARC reporting pipeline (RFC 7489 §7) - the END-TO-END-AGGREGATE-REPORT-PIPELINE companion to this DKIM replay-attack threat-model reference. Where THIS page documents the RFC 6376 §6.2.2 DKIM-signature replay attack class (capture-and-rebroadcast of cryptographically-valid signed messages to attacker-chosen recipients, defeating per-receiver DKIM verification at scale until the key rotates or the x= expiry passes), the DMARC-reporting-pipeline spoke is the OBSERVABILITY-LAYER REFERENCE documenting the seven-stage pipeline through which receivers surface per-source-IP DKIM- pass rows that the operator-side replay- detection discipline this page motivates analyses for the replay-attack signature. The REPLAY-ATTACK-VS-PIPELINE-OBSERVABILITY cross-reference establishes FOUR structurally-distinct per-pipeline-stage replay-attack evidence dimensions: (i) Stage 1 per-receiver per-message DKIM evaluation — the receiver-side verifier produces dkim=pass on the byte-identical replayed message because the signature is cryptographically valid; this is the ROOT cause of the replay-attack class — the receiver-side verifier cannot distinguish a legitimate original from a replayed copy; the DMARC-reporting-pipeline spoke documents Stage 1's per-message verdict-emission contract (RFC 7489 §3 receiver-side evaluation, dkim=pass entry in the Authentication-Results header) AND the downstream pipeline stages that aggregate this verdict into the operator- observable evidence stream; (ii) Stage 2-3 per-source-IP per- disposition row aggregation surfaces the replay-attack signature as a per-source-IP dkim=pass row attribution to an IP the operator's egress topology does NOT control — the canonical replay-detection signature is " dkim=pass rows attributed to source IPs OUTSIDE the operator's known egress IP block"; the DMARC- reporting-pipeline spoke documents the Stage 2 per-source-IP aggregation algorithm receivers apply (group by source-IP + disposition + auth-result enum) and the Stage 3 XML rua-payload schema operators consume the per-source-IP attribution through (RFC 7489 §7.2.1.4 <record><row>< source_ip> element); (iii) Stage 6 operator-side per-row analysis surfaces the per-source-IP DKIM-pass divergence pattern this page's threat-model motivates investigating — the operator's per-rua-interval analysis differentiates between forwarder legitimate-pass rows (Google forwarder, Outlook.com forwarder, mailing-list MTA) AND replay-attacker rows (per-source-IP attribution to commodity hosting / VPS / residential proxy infrastructure); the DMARC-reporting-pipeline spoke documents the Stage 6 operator-analysis discipline AND the per-source-IP reputation-lookup cross-reference operators apply (RBL / Spamhaus ZEN / Talos / Sender Score) to differentiate forwarder-legitimate from replay-attacker signature classes; (iv) Stage 7 per-operator feedback-into-receiver- trust-signals closes the replay-detection loop — the operator's confirmed replay- attack source-IP attribution becomes Sender Score / Spamhaus ZEN / cross-receiver-organisation block-list submission, propagating the detection out of the per-operator boundary into the shared receiver-side ecosystem; the DMARC-reporting-pipeline spoke documents the Stage 7 feedback channels operators use to propagate replay-attack evidence AND the per-receiver-organisation reputation-feedback cycle that limits the replay-utility window beyond the per-operator boundary. Pair this page (the DKIM-replay-attack threat-model reference) with the DMARC-reporting- pipeline spoke (the end-to-end observability-layer reference) when designing the per-operator replay- detection runbook — the spoke documents the per-stage payload structure AND the per-source-IP aggregation algorithm receivers apply that surfaces the replay-attack signature in the operator- observable evidence stream.
• DKIM for Google Workspace - the WORKSPACE-TENANT-DEPLOYED-DKIM-SIGNER- x-EXPIRY-DEFAULT-AND-google._domainkey-CNAME- PUBLISHED-PUBLIC-KEY-AS-PER-TENANT-REPLAY- WINDOW-BOUND-AND-SELECTOR-ROTATION- DISCIPLINE-SURFACE companion reference. Where THIS page documents the canonical RFC 6376 §6.2.2 DKIM-signature replay attack class (capture a cryptographically-valid signed message, re-broadcast byte-identical copies to attacker-chosen recipients, defeat per- receiver DKIM verification at scale because the signature remains valid until the key rotates or the x= expiry passes), the DKIM-for-Google-Workspace spoke is the WORKSPACE-TENANT-SIGNER-DEPLOYMENT companion documenting the Google-Workspace-tenant- specific DKIM-signer configuration surface whose four operator-side replay-bound controls structurally determine the replay-utility window any captured-Workspace- signed message offers an attacker: (i) the Workspace Admin Console's Apps > Google Workspace > Gmail > Authenticate email surface controls the Workspace-tenant DKIM signer's x=-expiry default — the per-tenant signer adds a default x= tag with a configurable expiry window the Workspace administrator tunes per tenant based on the operator's threat-model floor; the Workspace spoke documents the configuration surface and the operator-side rotation discipline that bounds the replay-utility window for any captured-and- replayable signature from a Workspace-hosted outbound mail-stream; (ii) the Workspace-tenant google._domainkey .<your-workspace-domain> TXT- record publication topology constrains the receiver-side public-key fetch path — when the operator rotates the Workspace DKIM-signer key via the Admin Console's Generate new record action, the receiver-side cache for the prior key's TTL bounds the maximum replay-window attackers can exploit any captured-and- signed-with-prior-key message instance; the Workspace spoke documents the dual-selector zero-downtime rotation cadence operators coordinate to bound the replay-window to the Workspace-managed key-rotation period plus the maximum receiver-side public-key cache TTL; (iii) the Workspace-tenant deployment supports the M3AAWG-consensus Rule-4-compatible weekly-to-monthly rotation cadence for high-risk senders — Workspace's Admin Console rotation UI accommodates the aggressive rotation cadence this page's threat-model recommends for high-value transactional mail-streams (OTP, MFA, password-reset, financial- authorisation) where the replay-utility window must be measured in days not months; the Workspace spoke documents the operator-side rotation discipline and the per-rotation-cycle Authentication-Results verification steps that confirm the new key is propagating before the prior key is retired; (iv) the Workspace deployment's per-tenant signing identity (anchored at google._domainkey .<workspace-domain>) is the load-bearing prerequisite for the receiver-side DKIM-aligned defense posture this page's threat model assumes — without a Workspace-tenant DKIM signer producing a valid d=<workspace- domain> signature, NO captured- Workspace-signed message instance exists for an attacker to replay; the Workspace spoke documents the Start authentication toggle and the per-tenant signer enablement prerequisite, the structural anchor that determines whether the replay-attack threat model on THIS page is even applicable to a given Workspace-hosted mail-stream. Read the DKIM-for-Google-Workspace spoke alongside this replay-attack threat-model deep dive when designing the production DKIM-signer posture for a Workspace-hosted outbound mail-stream — the Workspace-tenant-specific x=-expiry configuration, the google._domainkey selector- rotation cadence, and the Admin Console- driven rotation discipline the spoke documents are the load-bearing operator-side replay-window-bound controls this page's threat model motivates the operator to operationalise on the Workspace-tenant signing-surface.
• DKIM for Microsoft 365 — the M365-TENANT-SIBLING of the Google- Workspace-tenant-deployed-DKIM-signer replay-bound surface documented above. Where the Google-Workspace entry above documents the per-Workspace-tenant x=-tag default, google._ domainkey selector-publication topology, and Admin-Console-driven rotation discipline, the M365-tenant DKIM-signer surfaces a structurally-distinct replay-window-bound operational discipline at FOUR M365-tenant- specific deployment dimensions: (i) M365-tenant DKIM-signer provider- default vs operator-upgrade-baseline — Exchange Online's DKIM-signer historically ships with an RSA-1024 default that the operator MUST upgrade to RSA-2048 via the Rotate-DkimSigningConfig PowerShell cmdlet or the Exchange admin center "Rotate DKIM keys" UI; the operator-upgrade-baseline decision directly impacts the cryptographic- strength bound that limits an attacker's ability to forge a replayed signature without the private key (RSA-1024 has been factor- able under ~$100K hardware budget since the 2009 768-bit factoring milestone bracketed the gap, so an M365 tenant that never upgrades inherits a structurally-weaker replay-bound than an RSA-2048-upgraded tenant); the M365-DKIM spoke documents the exact PowerShell + Exchange admin center procedure for executing the RSA-1024→2048 upgrade at any time post-tenant-provisioning; (ii) M365 dual-selector rotation cadence vs replay-window bound — the M365 platform publishes the tenant public key at TWO selectors simultaneously (selector1._domainkey.<tenant- domain> AND selector2._ domainkey.<tenant-domain>) and rotates between them on a Microsoft-managed cadence (typically every few months for provider-managed keys), with operator- triggered rotation via the Rotate-DkimSigningConfig cmdlet forcing an immediate selector-swap; the dual-selector publication topology means a captured M365-signed message has its cryptographic-validity-window bounded by the next selector-rotation event, NOT by an x=-tag expiry (the M365 DKIM- signer does not emit an x= tag by default — the operator must manually configure it via Exchange transport rules if they want absolute-time bound); this page's threat-model motivates the M365 operator to either accelerate the rotation cadence below Microsoft's default (via cron-driven Rotate-DkimSigningConfig calls) or supplement the dual-selector rotation with an x=-tag emitted from a transport rule; (iii) M365 Microsoft-CNAME-delegated publication vs replay-detection observability — unlike a customer-controlled DNS zone where the operator can directly query the TXT record to detect rotation-window-pollution attacks (an attacker who publishes a forged p=-tag at the wrong moment), the M365 dual-selector keys live in the Microsoft-controlled <...>. onmicrosoft.com zone delegated from the customer-controlled zone via CNAME — meaning replay-utility-window observability for the M365 operator requires monitoring the CNAME-delegation target (Microsoft's DNS zone) rather than the operator's own zone; the M365-DKIM spoke documents the dig +short selector1._domainkey.< tenant-domain> CNAME diagnostic for validating the delegation chain remains intact; (iv) M365 Exchange Online Protection (EOP) replay-detection integration — Microsoft's EOP spam/malware filter integrates per-tenant replay-detection telemetry (replayed DKIM-aligned messages with anomalous receiver-distribution patterns get flagged at the EOP inbound layer for M365 tenants consuming Microsoft Defender for Office 365), giving the M365 operator a complementary replay-detection observability surface alongside the cryptographic-key- rotation bound documented on this page. Read the DKIM-for-Microsoft-365 spoke alongside this replay-attack threat-model deep dive when designing the production DKIM-signer posture for an M365-hosted outbound mail- stream — the M365-tenant-specific provider-default-vs-operator-upgrade baseline, dual-selector rotation cadence, Microsoft-CNAME-delegated publication topology, and EOP-integrated replay-detection observability that the spoke documents are the load-bearing operator-side replay-window-bound controls this page's threat model motivates the operator to operationalise on the M365-tenant signing-surface.
• DKIM key rotation - the operational mitigation that bounds the replay window. Aggressive rotation (weekly to monthly) is the single most effective sender-side replay defence.
• DKIM failure verdicts explained — the REPLAY-ATTACK-PRODUCES-NO-DKIM- FAIL-VERDICT-AT-RECEIVER-AND-WHY-DKIM- VERDICT-CATALOGUE-IS-NECESSARY-BUT- INSUFFICIENT-FOR-REPLAY-DETECTION companion to this DKIM replay-attack threat-model page. Where THIS page documents the cryptographically-valid- signature-rebroadcast attack class (attacker captures a legitimately DKIM-signed message and re-injects it at scale via different recipient channels, defeating receiver-side reputation while every per-message DKIM verification still emits dkim=pass), the dkim- failures-explained spoke documents the full seven-verdict Authentication-Results dkim=X catalogue with per-verdict semantics that EXPOSE the structural property replay attacks exploit. Four DKIM- VERDICT-VS-REPLAY-ATTACK-DETECTION-AND- DEFENSE axes the dkim-failures-explained spoke documents that converge on this replay-attack threat model: (i) Replay attacks emit dkim=pass verdicts at every receiver — the dkim-failures-explained spoke's dkim=pass semantics confirm that per-message DKIM verification is STRUCTURALLY INCAPABLE of distinguishing a legitimate-original from a replayed- rebroadcast — the spoke documents that dkim=pass means the receiver computed the body hash, verified the cryptographic signature against the published public key in the d= domain's s= selector TXT record, and confirmed the cryptographic bond; the verdict says NOTHING about whether the message has been seen before by other receivers in the same replay window; (ii) The dkim- failures-explained spoke's per-verdict diagnostic ladder is the legitimate- DKIM-fail-pattern-classification reference operators consume to RULE OUT legitimate- mail-misalignment as the cause of an observed RUA aggregate-rate anomaly BEFORE escalating to a per-selector recipient-velocity-baseline-replay- investigation — a per-week per-source-IP dkim=fail aggregate-rate spike on a legitimate- source IP can be a body-hash-mismatch (canonicalisation regression) OR a public-key rotation gap (selector TXT record disconnected) OR a multi-signature ordering collision; without the dkim- failures-explained spoke's per-verdict diagnostic ladder, operators waste investigation budget on every aggregate- rate spike, leaving fewer cycles to investigate genuine per-selector recipient-velocity anomalies that indicate replay; (iii) The dkim- failures-explained spoke documents the dkim=permerror verdict as the receiver-side outcome when an attacker attempts to forge a signature without the private key — but the replay attack class THIS page documents does NOT trigger dkim=permerror because the attacker uses a legitimately-signed message AS-IS, not a forged signature — the spoke's per-verdict semantics expose the gap between the "forge a signature without the private key" attack class (which DKIM blocks via dkim=permerror) and the "rebroadcast a legitimately-signed message at scale" attack class (which DKIM does NOT block) — making the replay-attack class on THIS page a STRUCTURALLY DISTINCT residual attack surface beyond the per-verdict-fail- class catalogue the dkim-failures- explained spoke documents; (iv) The seven sender-side replay-defence techniques THIS page documents (narrow x= signature-expiration windows, per-selector recipient-velocity baselines, aggressive per-selector rotation cadence, body-length-limit l= tag prohibition, per-tenant selector scoping, ARC chain-of-custody preservation, following the IETF DKIM2 drafts) are all STRUCTURALLY ORTHOGONAL to the per-verdict diagnostic ladder the dkim-failures-explained spoke documents — they operate at the per-selector per-tenant per-rotation-cadence-policy layer ABOVE the per-message DKIM verification that emits the dkim=X verdict; the dkim-failures-explained spoke is the reference operators consume to RULE OUT per-message-verification-class regressions before investigating per-selector-class replay anomalies. Pair this DKIM-replay-attack threat- model (the cryptographically-valid- signature-rebroadcast attack class and the seven sender-side defences) with the dkim-failures-explained spoke (the per-verdict diagnostic catalogue for the per-message verification layer) for the complete DKIM-verification-layer- diagnostic-AND-replay-attack-defense posture every DKIM-signing operator needs to bound the residual attack surface DKIM cryptographic verification does NOT close.
• DKIM best practices (the 15 deployment rules) - the operational recommendation catalogue whose Rule 4 + Rule 9 + Rule 11 form the cumulative sender-side replay-defence playbook this threat-model page motivates. Where THIS page is the security-research deep dive on the capture-and-rebroadcast attack class (a cryptographically-valid DKIM signature being re-used to send the same message body to attacker-chosen recipients) and the RFC 6376 x= expiration-tag mitigation, best-practices is the configuration-discipline counterpart. Rule 4 (annual rotation with dual-selector zero-downtime cadence, compressed to weekly/monthly for high-risk senders) bounds the validity window for any captured-and-replayable signature — the single most effective sender-side defence per the M3AAWG consensus this page also documents. Rule 9 (the 24-72h t=y testing-flag burn-in window before flipping to enforcement) exercises the receiver-side verification chain WITHOUT producing replay-eligible signatures during the burn-in — receivers that see t=y emit the verdict but do not propagate the positive result, neutralising any captured-during-burn-in signature. Rule 11 (multi-signature double-signing — RSA + Ed25519 in parallel, or two RSA selectors with overlapping validity windows) compounds the rotation defence: replaying a captured message requires BOTH signatures to remain valid, and the second signature's independent rotation cycle creates a second time-bound constraint the attacker must satisfy. Adjacent supporting rules: Rule 2 (RSA ≥ 2048 or Ed25519 — eliminates the cryptographic-weakness replay variant where forged signatures are possible without capturing a legitimate one), Rule 5 (c=relaxed/relaxed — narrows the canonicalization-window mutation surface the body-tail replay variant documented in section 4 of this page exploits), Rule 8 (NEVER use the l= partial-body-length tag — closes the canonical body-tail-append replay attack: with l= present the attacker can rebroadcast the signed prefix with arbitrary appended content; without l= any post-signing body modification invalidates the signature). Read best-practices alongside this page when designing the production DKIM signing posture: this page documents the THREAT model and the per-receiver replay-detection state machinery, best-practices documents the WHICH configuration knobs to ship and WHY each rule contributes to the cumulative replay-defence posture the threat model requires.
• DKIM cryptography basics - the cryptographic-foundation companion to this threat-model deep dive. The replay attack class on this page works against cryptographically-valid signatures by design — the signature remains valid because the attacker did not modify the signed content. The cryptography-basics page covers the orthogonal threat class where the cryptographic primitives themselves fail: 1024-bit RSA factoring (the projected NIST 2030 deprecation; the 2009 academic 768-bit factoring milestone bracketed the gap), SHA-1 collision attacks (formally deprecated by RFC 8301 since 2018 — SHAttered demonstrated practical collisions), and the migration path to Ed25519 elliptic-curve signing (RFC 8463; ~128-bit security equivalent to 3072-bit RSA with 32-byte keys + faster signing). Read both pages side-by-side: the replay-attacks page documents the threats that survive cryptographic strength; the cryptography- basics page documents the threats that exploit cryptographic weakness. The defensive posture is the same — short rotation cadence, strong algorithms (RSA ≥ 2048 or Ed25519), SHA-256 only, and the RFC 6376 x= expiration tag — but the operator rationale combines both threat models.
• DKIM selectors explained (s= and d= tags) - the tag-by-tag reference for the s= selector and d= signing-domain pair that anchors every replay-detection workflow. The selectors page documents the dual-selector zero- downtime rotation procedure that bounds the replay window (section 8) — the precise operational sequence behind the "aggressive DKIM rotation (weekly to monthly)" guidance on this page — including the publish-new / wait-TTL / cutover-signer / wait-replay- window / retire-old / DNS-purge cadence plus the eight canonical selector-naming patterns (date-based jan2026, sequence-based s2024-q1, hash-based k7d8, purpose-based marketing / transactional) that scale across multi-tenant SaaS deployments. Read the selectors page when designing your rotation cadence: this replay-attacks page documents the THREAT model that motivates rotation, the selectors page documents the DNS / tag / naming MECHANICS that implement it, and the key_rotation page documents the per-cycle operator runbook.
• DKIM canonicalization explained (simple vs relaxed) - the byte-level body-and-header normalisation layer that determines whether body-tail replay variants survive verification. The simple body canonicalization (RFC 6376 section 3.4.3) hashes the body bytes verbatim and rejects ANY trailing-byte modification — strongest against body-tail replay but most fragile against benign whitespace- mangling MTAs and mailing-list footer injection; the relaxed body canonicalization (section 3.4.4) collapses internal whitespace + strips trailing whitespace + ignores trailing empty lines — survives most forwarders but admits a small replay-mutation surface at the body tail. The optional l= partial-body-length tag (section 3.5) is the most replay- dangerous canonicalization-adjacent knob in the spec: it lets attackers APPEND arbitrary content after the signed prefix and the signature still verifies — avoid in production regardless of canonicalization choice. Read alongside this replay-attacks page when reviewing your operator c= tag defaults: the canonicalization page documents the BYTE-LEVEL processing layer the replay threat operates against, this page documents the THREAT MODEL itself, and the two together name the full attack surface from raw bytes to receiver DMARC outcome.
• How attackers bypass weak DMARC - the broader survey of DMARC-bypass vectors including DKIM replay as one of several attack classes (DKIM 1024-bit factoring, l= tag abuse, ARC chain abuse, BIMI exploitation).
• DMARC myths and misconceptions — the DKIM-REPLAY-AS-POST-DMARC-P-REJECT- RESIDUAL-ATTACK-VECTOR-MYTH-REFUTATION companion documenting the operator- facing 18-myth catalogue whose Myth #1 ("DMARC at p=reject stops all phishing") refutation argument is structurally underwritten by the DKIM signature- replay attack class THIS page documents. Where THIS page documents the DKIM signature-replay attack mechanics (the capture-and-rebroadcast technique where an attacker who has received a legitimately-signed-DKIM message from the target organisation captures the message at the recipient or via a compromised relay, re-injects the original signed message bytes verbatim via a different SMTP-egress connection to a different inbound-MX, and the downstream receiver — having no cryptographic mechanism to distinguish the originally-signed message from the rebroadcast copy — issues a dkim=pass verdict and a dmarc=pass-via-DKIM- alignment verdict on the rebroadcasted message; the RFC 6376 x=<timestamp> expiration-tag mitigation that adds an operator-published deadline beyond which the verifier must reject the signature; the per-message-Date-header narrow- window rebroadcast tactic that defeats receivers without strict timestamp enforcement; and the recipient-controlled- infrastructure scenarios where the attacker has root access to a legitimately DKIM-signing-mailbox the target organisation has authorised), the myths-and-misconceptions spoke documents the operator-facing 18-myth catalogue whose Myth #1 refutation maps directly onto the DKIM-replay attack class: an operator who has advanced DMARC to p=reject at 100% has indeed closed the forged-From-header-with-no-cryptographic- signature class of phishing — but the DKIM-signature-replay class documented on THIS page produces a cryptographically-valid signature whose d= signing-domain aligns with the From: header (because the original signed message was legitimately produced by the target organisation themselves), so the rebroadcasted message passes BOTH the DKIM signature verification AND the DMARC alignment check, and the receiver-side p=reject enforcement gives the rebroadcasted attack message the green-light it would give the original. The myth-refutation argument structurally cites THIS page's replay-attack mechanics to demonstrate that p=reject closes a large class of attacks (every spoofed- From-header attack with no legitimate DKIM signature, every SPF-only attack with a forged HELO-domain, every no-cryptographic-evidence cousin-domain attack) but leaves a residual attack- class (DKIM-signature-replay, cousin-domain attacks with their own valid DKIM signatures, internal-account- compromise attacks signing from legitimate infrastructure) the myths page enumerates. Read the myths-and- misconceptions catalogue alongside this DKIM-replay-attack reference when an operator argues that p=reject at 100% is the end of the phishing-defense journey — the catalogue's Myth #1 refutation argument is directly grounded in THIS page's residual-attack-class mechanics. Closes the DKIM-cluster ↔ DMARC-pillar myth-refutation bridge whereby the DKIM signature-replay attack class THIS page documents is the STRUCTURAL RESIDUAL- ATTACK-VECTOR underlying the operator-facing p=reject-completeness myth-refutation in the myths spoke.
• Email spoofing explained — the DKIM-REPLAY-IS-CRYPTOGRAPHICALLY-VALID-SPOOFING-SUBCLASS parent threat-class reference documenting the broader email-spoofing technique taxonomy of which capture-and-replay-of-a- legitimately-signed-message is one cryptographically-valid variant. Where THIS page documents the NARROW DKIM-replay threat model (the M3AAWG-described capture- and-rebroadcast attack class where a cryptographically-valid DKIM signature is re-used to send the same message body to attacker-chosen recipients, the per-receiver volume-comparison detection workflow, the RFC 6376 x= expiration-tag mitigation, and the rotation-cadence-and-canonicalization defensive posture), the email-spoofing pillar is the PARENT-CLASS DEEP DIVE on the seven canonical spoofing techniques DKIM-replay sits alongside as the EIGHTH cryptographically -valid variant — the four-axis comparison exposes WHY DKIM-replay is a structurally- distinct spoofing class no other technique rivals: (i) Direct domain spoofing (RFC 5322 From: forgery) — the attacker forges the From: header outright; cryptographically INVALID (no DKIM signature, or a signature that fails verification); DMARC at p=reject blocks it at the alignment check. DKIM-replay is ORTHOGONAL: the From: is unchanged from the legitimately-signed original, the DKIM signature VERIFIES, DMARC alignment PASSES — the receiver has no protocol-layer signal that anything is wrong; (ii) Envelope MAIL FROM spoofing (RFC 5321 SPF forgery) — the attacker forges the envelope sender to spoof the SPF authorisation domain; DMARC alignment with SPF fails if From: org-domain ≠ envelope domain. DKIM-replay does NOT need SPF because the DKIM-aligned-with-DMARC path already passes — replay is a SPF-INDEPENDENT spoofing class; (iii) Display-name spoofing — the attacker injects "Acme Bank Billing" <billing@unrelated.example> to exploit the From-header structure where alignment evaluates the ADDRESS domain not the DISPLAY-NAME phrase. DKIM-replay preserves the ORIGINAL From: address verbatim — receivers cannot detect replay from the display-name layer; (iv) Lookalike-domain registration + IDN homograph + cousin-domain — the attacker registers a visually-similar domain and publishes valid DMARC + DKIM + SPF for it; the lookalike's alignment passes and downstream brand-recognition fails at the UI layer. DKIM-replay uses the LEGITIMATE original domain — there is no lookalike to detect at the registration-domain layer. Read THIS DKIM-replay page WITH the email- spoofing pillar when scoping the threat model: this page documents the SINGLE cryptographically-valid spoofing variant the seven-technique pillar enumerates as the eighth class, and operators encountering unexpected per-receiver volume anomalies in their aggregate-RUA stream MUST evaluate BOTH the seven traditional spoofing techniques AND the DKIM-replay subclass before assigning a defensive posture — the spoofing pillar lists the SIX defender-side countermeasures (DMARC at p=reject + DKIM rotation + SPF strict + display-name anti-impersonation + BIMI visual indicators + user-awareness training) that close the seven traditional spoofing classes, but DKIM-replay specifically requires the SEVENTH countermeasure documented here — aggressive selector rotation (weekly to monthly) plus the RFC 6376 x= expiration tag — to bound the replay window. The spoofing pillar's defense-in-depth section explicitly cross-references this DKIM-replay page as the canonical reference for the eighth class.
• DMARC alignment explained - the alignment rules that determine whether a passing DKIM result also satisfies DMARC. Replayed messages pass alignment by design because the original From: and the original d= are unchanged.
• MTA-STS policy-file byte syntax — the REPLAY-ATTACKER-DESTINATION-MTA- DELIVERY-CHANNEL-CONSTRAINT-VIA-PUBLISHER- PUBLISHED-MX-ALLOW-LIST-POLICY-FILE-BYTE- FORMAT companion to this DKIM-replay reference. Where THIS page documents the cryptographically-valid-signature- rebroadcast attack class (the original DKIM signature, From: header, and d= identifier are PRESERVED byte-for-byte while the message is REDELIVERED to a different RFC 5321 RCPT-TO destination than the original recipient), the MTA- STS-policy-syntax spoke is the TRANSPORT-LAYER POLICY-FILE BYTE-GRAMMAR REFERENCE documenting the RFC 8461 §3.2 policy-file format whose mx: allow-list lines structurally BOUND the receiver-side set of MX hostnames the replay attacker can deliver the rebroadcast message through. The REPLAY-DELIVERY-CHANNEL-CONSTRAINT-VIA- MTA-STS-MX-ALLOW-LIST cross-reference establishes FIVE structurally-distinct per-byte-grammar-tag relevant constraints: (i) mode: enforce receiver-side commitment to STARTTLS verification at the MX allow-list boundary — receivers that have adopted the publisher's MTA-STS policy in mode: enforce will REJECT a STARTTLS-failing delivery attempt at any MX outside the allow-list; a replay attacker attempting to deliver the rebroadcast via an attacker-controlled relay that the publisher has NOT listed in the policy file will produce a receiver-side TLS-RPT failure-report event but the replay attempt does NOT succeed at delivery; (ii) mx: <hostname-glob> repeated lines establish the closed allow-list of authorised MX hosts — the MTA-STS-policy-syntax spoke documents the canonical byte-format (mx: *.protection.outlook.com, mx: mx.example.com) the publisher uses to enumerate the receiver-side authorised MX-host set; a replay attacker who attempts delivery to a recipient at the publisher's domain is BOUNDED to this set; (iii) max_age: <seconds> policy-file freshness budget — the spoke documents the receiver-side cache-lifetime semantic; replay attackers who rebroadcast a captured message after the publisher's policy-file mx: set has been updated to REMOVE a previously-compromised MX encounter the updated policy at the receiver after the cache TTL expires; (iv) version: STSv1 protocol-version tag — the spoke documents the version-sentinel as the FIRST byte of the policy file; replay attackers cannot fabricate a substitute policy-file because the HTTPS host-verified policy URL is cryptographically anchored to the publisher's authoritative DNS-TXT-record chain; (v) cross-protocol complementarity with TLS-RPT report format — when a replay attempt triggers a STARTTLS failure at an unauthorised MX, the receiver generates a TLS-RPT JSON report the publisher's SOC consumes; the MTA-STS-policy-syntax spoke documents the publisher-side mx: allow-list discipline whose tight maintenance ensures the TLS-RPT stream surfaces every replay- delivery-channel anomaly. Pair this page (the DKIM-replay attack-class reference) with the MTA-STS-policy- syntax spoke (the transport-layer publisher-side policy-file byte-grammar reference) when authoring a defence-in- depth posture review — the spoke documents the publisher-side operational discipline whose tight mx: allow-list maintenance bounds the replay attacker's structural delivery-channel choice at the receiver boundary.
• MTA-STS for Microsoft 365 — the M365-TENANT-PUBLISHED-MTA-STS- POLICY-AT-mta-sts-PERIOD-DOMAIN-AS- RECEIVER-SIDE-MX-ALLOW-LIST-BOUNDS- DKIM-REPLAY-ATTACKER-DELIVERY-CHANNEL companion to this DKIM-replay reference. Where THIS page documents the cryptographically-valid-signature- rebroadcast attack class (the original DKIM signature, From: header, and d= identifier are PRESERVED byte-for-byte while the message is REDELIVERED to a different RFC 5321 RCPT-TO destination than the original recipient) AND the operational- countermeasures stack (per-selector recipient-velocity baselines, narrow signature-expiration x= windows, body-length-limit l= tag prohibition, scheduled selector rotation cadence), the MTA-STS-for-Microsoft-365 spoke is the M365-TENANT-RECEIVER-SIDE TRANSPORT- LAYER-DELIVERY-CHANNEL-BOUNDS companion documenting the M365-tenant MTA-STS publication mechanics whose enforced- mode policy file STRUCTURALLY BOUNDS the receiver-side MX-host set the replay attacker can target when attempting rebroadcast to M365-tenant- hosted recipient domains. Concretely, the spoke documents FOUR M365-MTA-STS-vs-DKIM-replay-interaction dimensions: (i) M365-tenant published MTA-STS mode: enforce policy at https://mta-sts.<tenant- domain>/.well-known/mta-sts.txt with mx: *.mail.protection.outlook.com bounds the receiver-side MX-host set the replay attacker can deliver through — when an M365 tenant publishes the MTA-STS-enforce-mode policy file with the canonical Microsoft-managed *.mail.protection.outlook.com wildcard mx: directive, any replay attacker attempting to rebroadcast a captured DKIM-signed message to a recipient at the M365-tenant-protected domain is BOUNDED to deliver through the Microsoft-managed Exchange Online receive-MX infrastructure — the attacker CANNOT route the rebroadcast through an attacker-controlled relay because the M365 published policy does not authorise such an MX host in the receiver-side TLS-enforcement contract; (ii) M365 receiver- side rebroadcast-acceptance gate operates ORTHOGONALLY to the application-layer DKIM signature verification — the M365 MTA-STS policy enforcement at the SMTP-session-establishment boundary (transport-layer STARTTLS + MX-host allow-list verification) runs STRUCTURALLY BEFORE the M365 receive-side application-layer DKIM signature verification of the replayed message that THIS page documents as dkim=pass at every receiver — so an MTA-STS-policy- compliant replay (rebroadcast delivered THROUGH the *.mail.protection.outlook.com infrastructure) STILL succeeds at the transport layer, producing the cryptographically-valid dkim=pass verdict on the rebroadcast message AT M365 receivers and requiring the application-layer detection primitives THIS page documents (per- selector recipient-velocity baselines, x=-tag expiry windows, monitoring anomaly-detection signals) for replay attribution; (iii) M365-tenant TLS-RPT report-correlation surfaces replay-attempt-via-unauthorised-relay events at the M365-receiver boundary — when a replay attacker attempts rebroadcast through an attacker-controlled relay targeting an M365-tenant recipient, the M365 receive-side MX rejects the delivery (no STARTTLS, invalid certificate, MX hostname not in the M365-published policy's mx: allow-list) AND the M365 receive-side emits a TLS-RPT failure-report payload to the M365-tenant operator's TLS-RPT rua=mailto: endpoint — providing the M365-tenant operator with cross-protocol observability evidence of the replay-attempt-via- unauthorised-relay event class the DKIM-replay threat model THIS page documents motivates investigation of; and (iv) M365-tenant MTA-STS-policy-cache-rollover coordination is part of the replay- attack-window-bound discipline — when the M365 tenant updates the published policy file's mx: directive (during Exchange Online migration, tenant- rename, or coordinated security- incident-response MX-decommission), the receiver-side policy-cache- rollover semantics the spoke documents directly bound the replay-attack-window the operator must coordinate with the application- layer per-selector rotation cadence THIS page documents as the operational-countermeasures stack for the DKIM-replay threat class. Read the MTA-STS-for-Microsoft-365 spoke alongside THIS DKIM-replay reference when the M365-tenant operator is COORDINATING the application-layer DKIM-replay countermeasures THIS page documents with the transport-layer MTA-STS receiver-side delivery-channel bounds the spoke documents — both defence layers operate together at the M365-tenant receiver boundary to constrain the DKIM-replay attacker's structural delivery- channel surface at the M365-tenant recipient boundary.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-PUBLISHED- MTA-STS-POLICY-AS-RECEIVER-SIDE-MX- ALLOW-LIST-BOUNDS-DKIM-REPLAY- ATTACKER-DELIVERY-CHANNEL companion to THIS DKIM-replay threat-model reference. Where THIS page documents the RFC 6376 §8.6 DKIM-replay attack class at the application layer (the cryptographically-valid DKIM signature replayed by an unauthorised relay to an arbitrarily-expanded recipient cohort, the x=<expiry>- tag-bound replay-window, the per- selector key rotation as the application-layer replay-window-bound primitive, the volume-baseline + recipient-pattern correlation as the detection workflow, and the operational-incident-response key- revocation playbook the original sender executes to bound the replay blast radius) — i.e. the APPLICATION-LAYER-CRYPTOGRAPHIC- SIGNATURE-REBROADCAST side of the DKIM-replay threat model — the MTA- STS-for-Google-Workspace spoke is the WORKSPACE-TENANT-SPECIFIC RECEIVER- SIDE-TRANSPORT-LAYER-MX-ALLOW-LIST companion documenting the Workspace- operator-published MTA-STS policy file's mx: directive listing that STRUCTURALLY BOUNDS the receiver-side MX-host inventory a DKIM-replay attacker can use as the delivery-channel for the cryptographic- rebroadcast attack class against Workspace-tenant-hosted recipient domains. Concretely, the spoke documents FOUR Workspace-MTA-STS-vs- DKIM-replay-interaction dimensions: (i) Workspace-tenant mode=enforce policy bounds the receiver-side MX-host set the DKIM- replay attacker can deliver through — the Workspace- published policy file's mx: aspmx.l.google.com + mx: alt1.aspmx.l.google.com + mx: alt2.aspmx.l.google.com + mx: alt3.aspmx.l.google.com + mx: alt4.aspmx.l.google.com 5-host tier'd allow-list bounds the STARTTLS-enforcement-set of MX hosts cooperating MTAs (Gmail, Yahoo, AOL, Apple Mail, Fastmail, Outlook.com) will deliver the cryptographically- valid-DKIM-signed replayed message to — a replay attacker that controls an unauthorised relay STILL must deliver through ONE of the 5 Workspace- published MX targets to reach the Workspace recipient cohort the replay campaign expands the original message to, structurally orthogonal to but complementary with the application- layer-DKIM-signature-rebroadcast attack THIS page documents; (ii) Workspace-tenant receiver-side message-rebroadcast- acceptance gate is structurally ORTHOGONAL to application-layer DKIM verification — the Workspace receive-side mail-pipeline STILL evaluates DKIM-pass at the application layer (the Friendly-From- header alignment verdict driving DMARC enforcement at Workspace inbound), and the MTA-STS transport- layer-STARTTLS-enforcement contract the spoke documents adds the TRANSPORT-LAYER-MX-INVENTORY-BOUND defence layer on top of (not in place of) the application-layer DKIM rebroadcast detection workflow THIS page documents — both contracts cooperate to constrain the replay attacker's delivery-channel surface at the Workspace-tenant receiver boundary; (iii) Workspace- tenant TLS-RPT report correlation surfaces replay-attempt-via- unauthorised-relay events on the receive-side — the Workspace operator's TLS-RPT _smtp._tls.<workspace- domain> TXT record published rua= endpoint receives per-day aggregate TLS- session-result reports from cooperating sending MTAs that attempted to deliver to the Workspace-published MX inventory — anomalous TLS-RPT result-type distributions (e.g. a spike in "starttls-not-supported" or "validation-failure" on a previously-stable per-MX baseline) are corroborating evidence of the replay-attempt-via- unauthorised-relay event class the DKIM-replay threat model THIS page documents motivates investigation of; and (iv) Workspace- tenant MTA-STS-policy-cache-rollover coordination is part of the replay- attack-window-bound discipline — when the Workspace tenant updates the published policy file's mx: directive (during Gmail-tier migration, Workspace- domain-rename, or coordinated security-incident-response MX- decommission), the receiver-side policy-cache-rollover semantics the spoke documents directly bound the replay-attack-window the operator must coordinate with the application- layer per-selector rotation cadence THIS page documents as the operational-countermeasures stack for the DKIM-replay threat class. Read the MTA-STS-for-Google-Workspace spoke alongside THIS DKIM-replay reference when the Workspace-tenant operator is COORDINATING the application-layer DKIM-replay countermeasures THIS page documents with the transport-layer MTA-STS receiver-side delivery-channel bounds the spoke documents — both defence layers operate together at the Workspace-tenant receiver boundary to constrain the DKIM- replay attacker's structural delivery-channel surface at the Workspace-tenant recipient boundary.
• DMARC record tags explained - every tag in the DMARC DNS record. Understanding the policy semantics is prerequisite to understanding why p=reject does not stop replay.
• DMARC monitoring - the operational monitoring guide. The per-receiver volume comparison documented there is the canonical replay-detection workflow.
• DMARC aggregate reports (RUA) - the per-receiver aggregate-report format and parsing. The aggregate-report stream is the single best forensic source for detecting replay at the original sender.
• DMARC for transactional email - the ESP-deployment guide. Transactional mail is the most replay-attractive content class, so transactional senders should adopt aggressive DKIM rotation and per-recipient-domain rate limiting.
• DMARC for SaaS senders - the marketing-automation deployment guide. High-reputation marketing newsletters are the second most replay-attractive content class.
• DMARC for shared hosting (cPanel / Plesk / DirectAdmin / ISPConfig) - the SHARED-IP-POOL-DKIM-REPLAY-AMPLIFICATION-RISK-AT-CPANEL-PLESK-DIRECTADMIN-ISPCONFIG-MULTI-TENANT-EGRESS-WITH-NEIGHBOR-DOMAIN-REPUTATION-CROSS-CONTAMINATION companion documenting the shared-hosting deployment whose multi-tenant shared-IP egress pool is a structurally elevated DKIM-replay amplification surface because (i) a captured legitimate DKIM-signed message from any tenant on the shared pool can be replayed across hundreds of recipient mailboxes via different egress IPs within the same pool while still passing the original tenant's DKIM signature, (ii) the shared-IP-pool's aggregate sending reputation is cross-contaminated by any single tenant's replay-fueled inbox-placement drop (one tenant's compromise degrades all neighboring tenants' deliverability), and (iii) the per-tenant DKIM key rotation cadence on shared hosting is typically provider-controlled rather than tenant-controlled - cPanel's "Email Deliverability" panel auto-generates a single default DKIM key per tenant with no built-in rotation UI, Plesk's "Mail Settings → DKIM" toggle similarly publishes a single non-rotated key, DirectAdmin's "DKIM Selector" wizard defaults to a single static selector, and ISPConfig's "DKIM" tab requires manual key regeneration - so the time-bounded replay window remains open for the full key lifetime (often years). The page documents the per-control-panel DKIM-key- rotation cookbook (cPanel WHM's "Email Deliverability" bulk-regenerate workflow, Plesk's per-domain DKIM-key regeneration CLI, DirectAdmin's CustomBuild DKIM rotation script, ISPConfig's manual selector-rotation procedure), the shared-IP-pool reputation isolation playbook (WHM's per-tenant egress IP binding for high-value tenants, Plesk's "Multiple IP" subscription model, the "use server-wide DKIM" toggle's cross-tenant implications), and the per-tenant abuse-signal monitoring pipeline operators must run to detect replay-amplification at the shared-pool boundary before neighbor-domain reputation contamination propagates.
• DMARC troubleshooting - the operational diagnostic guide covering inbox-placement degradation, BIMI display loss, and the other downstream symptoms of replay.
• DKIM troubleshooting (symptom-driven debugging) — the DKIM-REPLAY-ATTACK-AS-DKIM- TROUBLESHOOTING-EDGE-CASE companion to this DKIM replay-attacks security- research deep dive. Where THIS page documents the DKIM-REPLAY ATTACK CLASS where an attacker captures a legitimately-DKIM-signed message and rebroadcasts the original signed bytes verbatim to attacker-chosen recipients (per RFC 6376 section 8.6 the cryptographically-valid signature from the original sign-time remains cryptographically valid at replay- time because the body-hash and header-hash inputs to the signature verification chain do not include recipient identity or send-time timestamp), the DKIM-troubleshooting spoke documents the SYMPTOM-DRIVEN DEBUGGING PLAYBOOK whose CANONICAL TRIAGE FLOW assumes dkim=fail is the operator's primary signal AND dkim=pass is the steady- state success outcome — but the replay-attack class STRUCTURALLY INVERTS this assumption by producing dkim=pass verdicts on ATTACKER-CONTROLLED messages, creating a TROUBLESHOOTING EDGE CASE the per-symptom playbook must explicitly handle. FOUR structurally- distinct REPLAY-INDUCED DKIM- TROUBLESHOOTING-SYMPTOM dimensions emerge from cross-mapping the replay-attack mechanics against the troubleshooting playbook: (1) Recipient-complaints-of- unsolicited-but-DKIM-signed-mail despite-no-publisher-sending-record symptom at the per-message recipient- complaint vs publisher-egress-log joint-investigation boundary — the troubleshooting-spoke documents the canonical recipient-complaint triage flow where the operator queries the publisher's outbound-egress logs for the Message-ID / From: / To: / Date: combination from the complainant's headers. The DKIM-REPLAY symptom is STRUCTURALLY DISTINCT: the publisher's egress logs SHOW NO OUTBOUND record for the recipient (because the attacker replayed the captured message directly via attacker-controlled infrastructure), but the recipient's headers show dkim=pass with the publisher's d= and selector verbatim. This per-recipient- complaint-with-missing-egress- log is the canonical DKIM-replay symptom signature the troubleshooting playbook must differentiate from the cryptographic-key-compromise symptom (where the publisher's OWN key was exfiltrated and the attacker is signing arbitrary new bytes). THIS page's replay- vs-key-compromise distinction is the security-research primitive the troubleshooting playbook must encode at the per-recipient- complaint triage decision point. (2) Unfamiliar-source_ip- emitting-dkim-pass-aligned-rows in-aggregate-report-RUA-stream symptom at the per-source_ip- cohort vs publisher-authorised- sender-inventory joint- reconciliation boundary — the troubleshooting-spoke documents the per-RUA-row triage flow where unfamiliar source_ips emitting dkim=fail verdicts indicate a per-source_ip DKIM-record-misconfiguration or attacker-impersonation attempt. The DKIM-REPLAY symptom signature is STRUCTURALLY DISTINCT: the unfamiliar source_ip emits dkim=pass verdicts with the publisher's verbatim d= and selector. The troubleshooting playbook must explicitly handle this edge case by cross-referencing per-source_ip rows against the publisher's authorised-sender- inventory AND adding the unfamiliar-source_ip-with- dkim-pass row signature as a REPLAY-CAMPAIGN signal at the per-message-Date-header narrow- window timing-correlation boundary. THIS page's per- source_ip replay-detection approach is the security- research primitive the troubleshooting playbook must encode at the per-RUA-row decision point. (3) Recipient-complaint-about- message-content-mismatch-with- legitimate-original symptom at the per-message Date-header- vs-receive-time joint-window boundary — the troubleshooting-spoke documents the content-mismatch triage flow where recipients report receiving messages whose content does not match the publisher's intent (e.g. attacker rebroadcasts a legitimate "your 2FA code is 123456" message to attacker- chosen recipients during a coordinated credential-theft campaign). The publisher's DKIM signature is cryptographically valid at rebroadcast time because the replay attack does not modify the body; the troubleshooting-symptom is the per-recipient-complaint about contextual-illegitimacy despite cryptographic- legitimacy. THIS page's Date- header-narrow-window timing- correlation mitigation (RFC 6376 x= expiration tag) is the security-research primitive the troubleshooting playbook must surface as a mitigation recommendation when this symptom-signature appears. (4) Per-day- per-source_ip volume-spike- without-corresponding-publisher- send-cadence-uplift symptom at the time-series RUA-stream baseline-deviation boundary — the troubleshooting-spoke documents the per-day-per- source_ip volume-anomaly triage flow. The DKIM-REPLAY- symptom signature is the per-source_ip volume-spike with high dkim=pass rate WHILE the publisher's own send-cadence is flat or declining over the same window. The troubleshooting playbook must explicitly encode the publisher-send- cadence-vs-RUA-row-count divergence as a REPLAY-CAMPAIGN signal — the RUA-row count exceeds the publisher's egress- log count, with the delta attributable to replayed messages. THIS page's aggressive key-rotation recommendation (replay-window bounded by per-selector cryptographic-validity duration) is the security- research primitive the troubleshooting playbook must surface as a per-symptom mitigation. Read the troubleshooting-spoke alongside THIS page when the operator's DKIM-debugging playbook is being extended to handle replay-attack edge cases: this page tells you WHY THE DKIM-PASS VERDICT can be legitimate-by-cryptography but illegitimate-by-context, the troubleshooting-spoke tells you WHAT SYMPTOM SIGNATURES surface this cryptographic-context divergence AND WHY the per-symptom playbook must encode replay as a structurally-distinct edge-case branch.
• Email authentication glossary - definitions of replay, body hash, signed headers, l= tag, selector, and the other vocabulary used on this page.
• Email security glossary — the threat-actor, attack-taxonomy, and incident-response context - the broader security-context glossary cataloguing the threat-actor taxonomies (nation-state APTs, ransomware crews, access brokers, business-email-compromise crews), the MITRE ATT&CK and STRIDE classification frameworks, the 7-stage cyber kill chain, the NIST SP 800-61 incident-response cycle, and the defense-in-depth control stack within which DKIM-replay sits as a specific authentication-bypass technique. Where this page is the protocol-mechanism deep dive on the DKIM-replay attack pattern (signature-survives-forwarding exploitation, l= tag abuse, selector-fixed-window replay, body-hash-coverage gaps), the security_glossary spoke is the broader threat-modelling and incident-response context: replay maps to MITRE ATT&CK T1078 (Valid Accounts) and T1656 (Impersonation) within the broader Initial-Access / Defence-Evasion tactic categories; replay-driven phishing campaigns map to the kill-chain Weaponisation + Delivery stages; replay events that succeed past the DMARC layer feed downstream into the SOC / SIEM / SOAR / EDR detection-and-response stack. Read the security_glossary spoke when an operator asks "where does the DKIM-replay attack pattern sit in the broader threat landscape" — the glossary is the canonical cross-walk between protocol-level attack mechanics (this page) and the threat-actor, kill-chain, and incident-response vocabularies operators encounter in SOC / blue-team / red-team contexts.
• DKIM-Signature header tag anatomy — the DKIM-REPLAY-EXPLOITATION-OF- SIGNATURE-FIELD-IMMUTABILITY companion reference. Where this page documents the REPLAY THREAT MODEL itself (M3AAWG-described capture-and- rebroadcast attack class, per-receiver volume comparison detection workflow, RFC 6376 x= expiration- tag mitigation, aggressive selector rotation defensive posture), the signatures-explained spoke is the FIELD-LEVEL CANONICAL REFERENCE for the DKIM-Signature header tags whose cryptographic immutability is the precise property replay exploits: the b= base64-signature bytes commit the signer's private key to the h+bh composite (the cryptographic anchor replay rebroadcasts unchanged), the bh= body hash is what the receiver recomputes and matches against the signed value (the immutability the c= body canonicalization layer protects), the s= selector is bound to the specific signing key (the rotation-target replay defenders attack with aggressive cadence), the h= signed-header-list binds From:/Subject:/Date:/Message-ID: into the hash (the headers replay must preserve verbatim), and the a= algorithm pins the hash + signing functions whose composite produces b=. Read the signatures-explained spoke alongside this page when correlating a replay forensic capture to specific tag-level defensive controls — the spoke gives the per-tag canonical anatomy, this page gives the threat model exploiting each tag's immutability, and the x= expiration-tag mitigation (RFC 6376) is the ONE signature-field property that deliberately BREAKS immutability by bounding the signature validity window — documented in syntax on the signatures spoke, documented in defensive deployment posture here.
• Business Email Compromise (BEC) — the DKIM-REPLAY-AS-BEC-ENABLER-PATTERN companion to this replay-attack reference — the DKIM-REPLAY-AS-BEC-ENABLER-PATTERN companion documenting how the DKIM replay attack class THIS page documents intersects with the Business Email Compromise (BEC) threat class as an enabling technique rather than a substitute for the canonical identity-spoofing sub-techniques. Where THIS page documents the DKIM replay MECHANICS in protocol-precise terms (RFC 6376 §3.5 acknowledged limitation, RFC 6376 §8.6 known security consideration, replay-via-relay infrastructure exploiting the immutable signed-message-bytes invariant, receiver-side body-hash recomputation that cannot distinguish a legitimate first delivery from an attacker- relayed replay), the BEC spoke documents the BROADER financial-fraud attack campaign in which a DKIM-replay subroutine becomes one technique among the four BEC sub- techniques. When an attacker compromises a vendor mailbox (VEC sub-class) and intercepts an authenticated DKIM-signed invoice request, the attacker can REPLAY that captured DKIM-signed message verbatim to additional victims with the body-hash unchanged — the receiver sees a cryptographically-valid DKIM signature on an attacker-distributed copy, no spoofing involved. Where exact-domain spoofing requires forging signatures and is closed by p=reject DMARC policy, replay requires NO forgery and is only narrowed by short x= expiration windows (RFC 6376 section 3.5) and the aggressive DKIM-key- rotation defenses THIS page catalogues. Read THIS replay-mechanics page WITH the BEC reference when threat-modelling a BEC + DKIM-replay composite attack — the BEC spoke names the four sub-techniques whose financial-fraud campaign-level success the DKIM-replay subroutine accelerates by producing receiver-side cryptographically- valid mail at attacker-controlled distribution scale.
• DKIM DNS-record syntax - the DKIM-PUBLIC-KEY-PUBLICATION-BYTE- GRAMMAR-AS-LOAD-BEARING-PUBLICATION- DISCIPLINE-PRECONDITION-TO-EVERY-DKIM- REPLAY-ATTACK-WINDOW-ANALYSIS companion to this DKIM-replay threat-model reference. Where THIS page documents the RFC 6376 §6.2.2 DKIM-signature replay attack class (capture-and-rebroadcast of cryptographically-valid signed messages to attacker-chosen recipients, defeating per-receiver DKIM verification at scale until the key rotates or the x= expiry passes), the DKIM-DNS-record- syntax spoke is the PUBLICATION- DISCIPLINE byte-grammar reference documenting the per-publisher per- selector TXT-record-byte-grammar whose publication choices DIRECTLY determine how long a captured signature remains replay-utility-viable at FOUR per-DKIM- DNS-tag-to-replay-window-bound dimensions: (i) the p= public-key publication-byte choice as the per-selector replay-window CEILING — every captured signature remains replay-utility-viable until the publisher republishes the selector with a DIFFERENT p= public-key value (or sets p= to the empty-string revocation primitive); the DKIM-DNS-record-syntax spoke documents the byte-grammar for the base64-encoded RSA / Ed25519 public-key bytes AND the 2048-bit RSA / Ed25519 modulus-strength-deployment-discipline whose per-selector rotation cadence bounds the replay-utility window receivers must tolerate; (ii) the t= flags tag publication choice as the per-selector replay-detection-strictness governor — the t=y testing-mode flag signals receivers MAY decline to enforce strict downstream actions on signed messages from this selector (relaxing the receiver-side replay- detection logic), whereas the t=s strict-d= flag signals the publisher REQUIRES the DKIM d= tag to exactly match the i=<identity> tag (tightening per-signature attribution and shrinking the per-receiver replay ambiguity window); the DKIM- DNS-record-syntax spoke documents both flag values and their per-receiver-side replay-detection-logic consequences; (iii) the per-selector publication-cadence as the per-tenant replay-window-rotation floor — the publisher's per-selector rotation cadence (90 days / 6 months / 12 months) is the per-selector replay- window-rotation discipline that determines the maximum interval between a captured signature's validity-window START and its forced-retirement END through DNS publication; the DKIM-DNS-record-syntax spoke documents the per-selector rotation byte-grammar (publish NEW selector at <new-selector>._domainkey.<d>, wait for DNS TTL propagation, switch signer to NEW selector, retire OLD selector via empty-p=) AND the per-selector rotation-cadence discipline whose floor directly compresses the replay-utility window this page's threat-model motivates the operator to shrink; (iv) the empty-p= revocation primitive as the per-selector replay- attack kill-switch publication- discipline — when a per-tenant signature is detected being replayed at scale, the publisher's emergency response is the immediate publication of an empty-p= revocation TXT-record at the affected selector FQDN, which (after DNS TTL propagation) instructs every receiver-side validator to FAIL every signature claiming that selector; the DKIM-DNS-record- syntax spoke documents the empty- p= revocation primitive's byte-grammar AND the per-selector kill-switch propagation-discipline whose deployment is the canonical operator response to an in-flight replay-attack campaign this page's threat-model motivates the operator to prepare for. Read the DKIM-DNS-record- syntax spoke alongside this DKIM- replay-attack threat-model reference when designing the per-tenant replay- window-bounding runbook — the spoke documents the per-publisher per- selector publication-discipline whose every byte-grammar choice (p= public-key bytes, t= flags, selector-rotation cadence, empty-p= revocation primitive) directly bounds the replay- utility window the operator-side detection-and-response discipline this page architectures must compress.
• Phishing protection — the MULTI-LAYER-ANTI-PHISHING-DEFENCE- STACK-AS-DKIM-REPLAY-COMPRESSION-CONTROL- SET companion to this DKIM-replay threat- model reference. Where THIS page documents the RFC 6376 §6.2.2 DKIM-signature replay attack class (capture-and-rebroadcast of cryptographically-valid signed messages to attacker-chosen recipients, defeating per-receiver DKIM verification at scale until the publisher rotates the selector key or the x= expiry passes), the phishing-protection spoke is the ANTI-PHISHING-DEFENCE-STACK CATALOGUE documenting how the receiver-side and publisher-side controls compress the per-recipient utility of every replayed signature at FOUR per-anti-phishing- control-to-DKIM-replay-coupling dimensions: (i) publisher p=reject DMARC enforcement as receiver-side replay-distribution-attribution-to- legitimate-d=-sender rejection control — when the replay-attacker re-broadcasts a captured signature whose d= attributes to a publisher with p=reject but the replayed envelope MAIL-FROM and per-source-IP topology do NOT align with the publisher's egress posture, the receiver-side DMARC evaluator rejects on the alignment-failure path even though the cryptographic dkim=pass verdict is technically satisfied; the phishing-protection spoke documents this receiver-side enforcement primitive AS the canonical anti-phishing CONTROL the per-publisher-side DKIM-replay-bounding discipline this page motivates structurally complements; (ii) ARC-chain inspection as receiver-side legitimate- forwarder-versus-replay-attacker differentiation control — the receiver-side ARC-Authentication-Results chain inspection differentiates a legitimate forwarder hop (cv=pass with a recognised intermediary sealer) from a replay-attacker hop (cv=fail or a sealer identifier the receiver's anti-phishing reputation system does NOT trust); the phishing-protection spoke catalogues this ARC-chain-inspection control AS the canonical receiver-side anti-phishing signal whose deployment differentiates the forwarder-class from the replay- attacker-class this page's threat-model architectures; (iii) per-selector x= signature-expiry tag as publisher-side message-layer anti-phishing primitive bounding the per-captured- signature replay-utility window — the publisher's per-message x= expiry-timestamp publication is the message-layer anti-phishing control whose enforcement by receiver-side validators forces every replayed signature past its expiry-timestamp to FAIL the dkim=pass verdict, directly compressing the per-captured-signature replay-utility window the phishing defence-stack depends on the publisher bounding; (iv) BIMI-display- suppression on replayed-attacker-mail as recipient-side anti-phishing visual signal — when the replay-attacker re-broadcasts a captured brand signature from an IP topology that does NOT match the publisher's BIMI-aware mailbox- provider's egress-reputation expectation, the receiver-side BIMI-display gate suppresses the authenticated brand-logo render at the recipient inbox-list surface, converting the per-message DKIM- replay event into a recipient-perceivable visual-authenticity-absence signal; the phishing-protection spoke catalogues this receiver-side BIMI-suppression control AS the load-bearing recipient-side anti- phishing signal the publisher-side DKIM- replay-bounding discipline this page motivates structurally complements. Read the phishing-protection spoke alongside this DKIM-replay threat-model reference when designing the receiver-side-and- publisher-side multi-layer defence-stack whose deployment directly compresses the per-recipient utility of every captured- signature replay campaign.
• SPF for Microsoft 365 — the PER-M365-TENANT-SPF-INCLUDE- CASCADE-AS-RECEIVER-SIDE-ENVELOPE-MAIL- FROM-AUTHORIZED-SOURCE-IP-ALLOW-LIST- BOUND-ON-DKIM-REPLAY-ATTACKER-EGRESS-IP- TOPOLOGY companion to this DKIM-replay threat-model reference. Where THIS page documents the RFC 6376 §6.2.2 DKIM- signature replay attack class (capture- and-rebroadcast of cryptographically- valid signed messages from per-attacker- chosen source-IP topology to attacker- chosen recipients, defeating per-receiver DKIM verification at scale until the publisher rotates the selector key or the x= expiry passes), the spf_for_microsoft_365 spoke documents the per-M365-tenant SPF-include-cascade publication mechanics at FOUR per-M365- SPF-vs-DKIM-replay-interaction dimensions: (i) per-M365-tenant include:spf.protection.outlook.com SPF-include-cascade as RECEIVER-SIDE- ENVELOPE-MAIL-FROM-AUTHORIZED-SOURCE-IP- ALLOW-LIST-BOUND on DKIM-REPLAY-ATTACKER- EGRESS-IP-TOPOLOGY-AT-M365-TENANT- ATTRIBUTED-ENVELOPE-DOMAINS — when the replay-attacker captures a DKIM-signed message whose d= attributes to an M365-tenant-hosted publisher and attempts to re-broadcast from an attacker-controlled source-IP outside the per-M365-tenant SPF-allow- listed Microsoft Outlook outbound /14 + /16 prefix range published by the include:spf.protection.outlook.com cascade, the receiver-side SPF evaluator emits spf=fail on the envelope MAIL-FROM lookup, and the receiver-side DMARC alignment-evaluator rejects on the SPF-alignment-failure path even though the cryptographic dkim=pass verdict is technically satisfied; the spf_for_ microsoft_365 spoke documents this envelope-domain authorization primitive AS the canonical receiver-side per- source-IP control the per-publisher- side DKIM-replay-bounding discipline this page motivates structurally complements at M365-tenant-attributed- envelope boundaries; (ii) per- M365-tenant SPF-include-cascade lookup- budget consumption AS publisher-side per-tenant SPF-publication-byte-budget discipline complementary to the per- tenant DKIM-selector-rotation discipline this page documents — M365's per-tenant include:spf.protection.outlook.com cascade itself consumes 5+ of the RFC 7208 §4.6.4 ten-DNS-lookup ceiling budget; the spf_for_microsoft_365 spoke documents the per-tenant SPF- publication-byte-budget discipline whose preservation parallels the per- tenant DKIM-selector-rotation publication-byte-budget discipline the per-publisher-side DKIM-replay- bounding discipline THIS page motivates depends on at the M365- tenant-publication-discipline boundary; (iii) per-M365- tenant SPF-record per-source-IP AUTHORIZATION-FAILURE-EVIDENCE-EMITTED- IN-RUA-AGGREGATE-REPORTS as receiver- side-emitted DKIM-replay-detection observability signal — when the per-M365-tenant SPF evaluator emits spf=fail on a replayed message's envelope-MAIL- FROM, the receiver-side aggregate- report emitter records the per-source- IP-per-disposition row attributing the SPF-failure to the attacker-controlled rebroadcast IP topology; the spf_for_ microsoft_365 spoke documents this per-row evidence-emission discipline AS the load-bearing observability signal the per-publisher-side operator-detection-and-response discipline this page documents consumes to detect replay-attack campaigns at the per-source-IP topology level; (iv) per- M365-tenant primary-domain-and- alias-domain SPF-publication coordination as load-bearing publisher-side per-tenant multi- envelope-domain coverage discipline complementary to the per-tenant DKIM-key-rotation coordination discipline THIS page documents — M365 tenants frequently host primary + alias domains (e.g., primary tenant + acquired-company domains + brand- alias domains) each requiring per- envelope-domain SPF-include-cascade publication coordination; the spf_for_ microsoft_365 spoke documents this per-tenant multi-envelope-domain SPF-publication-coordination discipline whose preservation parallels the per-tenant DKIM-key- rotation coordination discipline the per-publisher-side DKIM-replay- bounding playbook THIS page documents depends on at the M365-tenant-multi- envelope-domain boundary. Read the spf_for_microsoft_365 spoke alongside this DKIM-replay threat-model reference whenever the publisher scopes a per-M365-tenant SPF-include- cascade-vs-DKIM-replay-attacker- source-IP-topology-bound coverage plan — the per-M365-tenant SPF- include-cascade documentation the spoke catalogues IS the load-bearing envelope-MAIL-FROM-authorized-source- IP-allow-list control bounding the per-source-IP egress topology every captured-signature replay campaign can use against M365-tenant-attributed envelope-domains.
• BIMI Verified Mark Certificates (VMC and CMC) - the PER-PUBLISHER-PER-DOMAIN-VMC-VS- DKIM-CRYPTOGRAPHIC-KEY-CUSTODY-PARALLEL companion to this DKIM-replay-attack threat-model reference. Where THIS page documents the RFC 6376 §8.6 DKIM-replay- attack-vector whose per-publisher per-domain DKIM private-key-custody + per-selector rotation cadence + per-public-key-DNS-publication discipline bounds the per-key-lifetime per-message replay attack surface, the BIMI VMC certificates spoke documents the STRUCTURALLY-PARALLEL per-publisher per- domain VMC X.509 cert private-key-custody discipline at FOUR per-publisher per- domain BIMI-VMC-vs-DKIM-private-key- custody parallel dimensions: (i) per-publisher per-domain VMC X.509-cert private-key custody discipline as PUBLIC-CA-ROOTED parallel to per- publisher per-domain DKIM RSA/Ed25519 keypair custody at selector._domainkey.<domain> — both crypto-primitives are per- publisher per-domain trust anchors, but DKIM's RSA/Ed25519 keypair is self-published in DNS without external validation while the VMC's X.509 cert is chained to a public-CA root (DigiCert or Entrust at present) validated against the receiver's trust-store at the per-receiver per- message BIMI evaluation moment; (ii) per-publisher per-domain VMC SVG-hash-binding SubjectAltName cryptographic-integrity-evidence as BIMI-EVALUATOR-CONSUMED PER-MESSAGE- EVALUATION-MOMENT EVIDENCE parallel to per-publisher per-domain DKIM body- hash + headers-hash signature evidence the receiver-side DKIM verifier consumes per-message — Gmail / Apple Mail / Yahoo / Fastmail BIMI evaluators compute the served-SVG SHA-256 and match it against the SubjectAltName-embedded hash in the VMC cert per-message at the receiver evaluation moment (a cryptographic binding directly parallel to the DKIM receiver computing the body-hash and matching against the bh= tag in the DKIM- Signature header per-message); (iii) per-publisher per-domain VMC 1-year renewal cadence as per- publisher per-domain per-key-lifetime cryptographic-key-replay-window-bound parallel to per-publisher per-domain per-selector DKIM rotation cadence the replay-attack mitigation discipline THIS page presupposes - VMC certificates issue with a 1-year validity window structurally paralleling the 6-month per-publisher DKIM key-rotation cadence (typically managed at selector._domainkey.<domain>); both cadences bound the per-key- lifetime cryptographic-replay window an attacker exploiting captured public-credential material can operate within; and (iv) per- publisher per-domain VMC revocation- event-driven re-issuance discipline as per-publisher per-domain cryptographic-compromise-mitigation parallel to per-publisher per-domain DKIM selector._domainkey empty-p= revocation discipline the replay-attack cryptographic-key-rotation playbook THIS page documents - when a per-publisher VMC X.509 cert private key is compromised the per- publisher per-domain operator must revoke the cert via the public-CA's OCSP/CRL infrastructure AND re-issue a fresh VMC AND re-publish the per-domain default._bimi.<domain> TXT-record a= endpoint, paralleling the per- publisher per-domain selector._domainkey empty-p= revocation protocol-level mechanism THIS page documents as the per-selector DKIM-private-key-compromise mitigation primitive. Pair THIS DKIM-replay threat-model reference with the BIMI VMC certificates spoke when designing the per-publisher per- domain dual-cryptographic-primitive- custody-and-rotation discipline that bounds the per-publisher per-domain per-key-lifetime replay-attack surface across BOTH the DKIM-private- key custody surface AND the VMC- private-key custody surface that together compose the per-publisher per-domain cryptographic-anti- spoofing-and-anti-replay posture's full attack-surface bound.
• CAA records explained - the PER-PUBLISHER-PER-DOMAIN-CAA-DNS- PROPERTY-TAG-PUBLICATION-AS-UPSTREAM- CA-AUTHORITY-BINDING-GATING-X.509-CERT- ISSUANCE-THE-CRYPTOGRAPHIC-KEY-CUSTODY- DISCIPLINE-DEPENDS-ON companion to this DKIM-replay-attack threat-model reference. Where THIS page documents the per-publisher per-domain DKIM private-key-custody + per-selector rotation cadence + per-public-key-DNS- publication discipline that bounds the per-key-lifetime per-message replay attack surface, the CAA-records explained spoke documents the UPSTREAM-DNS-LAYER-CA-AUTHORITY-BINDING publication discipline that GATES the X.509-cert issuance pipeline the BIMI VMC entry above (and the MTA-STS Web- PKI two-leaf cert chain peer-pair beneath) depend on, at FOUR per- publisher per-domain CAA-vs-DKIM- replay-cryptographic-key-custody coupling dimensions: (i) per- publisher per-domain CAA-RR issue "<ca-domain>" property-tag publication discipline as UPSTREAM-CA-AUTHORITY-BINDING DNS-LAYER PARALLEL to per-publisher per-domain DKIM <selector>._domainkey TXT-RR p= public-key publication discipline at the APPLICATION-LAYER — both are per-publisher per-domain DNS-published trust-anchor declarations the receiver- side cryptographic evaluator consults at issuance / verification time, but DKIM's p= public-key TXT- RR is the application-layer per-message signature-verification anchor while CAA's issue property tag is the upstream DNS-layer CA-authority- binding that GATES whether ANY public CA may issue an X.509 cert binding the publisher's domain (DKIM controls per-message verifier behavior; CAA controls per-CA issuance behavior); (ii) per-publisher per-domain CAA-RR mis-publication / absence as STRUCTURAL-ENABLER of attacker-driven rogue-CA misissuance of BIMI VMC X.509 certs and MTA-STS Web-PKI two-leaf X.509 certs PARALLEL to per-publisher per- selector DKIM p= publication- cadence drift enabling captured-signature replay — a per-publisher per- domain that publishes no CAA-RR at all (or publishes a permissive 0 issue ";" ALLOW-ANY) allows ANY public CA to issue a VMC X.509 cert against attacker-controlled CSR material, which the BIMI-evaluator at Gmail / Apple / Yahoo subsequently chains-to-trust and renders as the publisher's brand indicator beside attacker-replayed messages — STRUCTURALLY PARALLEL to the per-publisher per-selector DKIM publication-cadence drift the replay-attack class on THIS page depends on as a per-key-lifetime cryptographic-attack-surface bound; (iii) per-publisher per-domain CAA-RR iodef property-tag per-CA misissuance-attempt incident- report stream as RECEIVER-SIDE OBSERVABILITY PARALLEL to per-publisher per-receiver DMARC RUA XML-aggregate- report per-source-IP per-disposition DKIM-pass-verdict aggregation observability the replay-detection playbook THIS page documents depends on — both observability streams emit per-event evidence to the per-publisher operations team (CAA-iodef: per-failed- CA-issuance-attempt incident report from the rejected CA; DMARC-RUA: per- source-IP per-disposition DKIM-pass- verdict row aggregation from the receiver) but at different layers of the cryptographic-key-custody-vs- replay-detection-evidence stack, and the operator-side incident-response team must correlate both streams to build the full per-publisher per-domain cryptographic-attack-surface picture; and (iv) per-publisher per- domain CAA-RR republish-cadence + TTL- bounded cache-eviction overlap-window as PER-DOMAIN UPSTREAM-DNS-AUTHORITY- BINDING TIMING-DISCIPLINE PARALLEL to per-publisher per-selector DKIM- rotation overlap-window + TTL-bounded cache-eviction timing-discipline the per-publisher-side DKIM-replay-bounding playbook THIS page presupposes - just as the DKIM-key-rotation cadence must coordinate the per-selector public- key publication / un-publication window with the receiver-side TTL-bounded cache-eviction discipline (else replay attackers exploit cached-but-rotated-out public keys at the receiver), the CAA- RR publication cadence must coordinate the per-domain CA-authority binding with the public-CA-side CAA-validation TTL discipline (RFC 8659 §4 mandates a ≤24-hour CAA-RR cache window at the validating CA) — both per-publisher per-domain timing-disciplines are load-bearing inputs to the per- publisher per-domain cross-layer cryptographic-attack-surface bound the per-publisher per-domain DKIM-replay + per-publisher per-domain BIMI-VMC- forgery + per-publisher per-domain MTA-STS Web-PKI-forgery joint defence posture depends on. Pair THIS DKIM- replay threat-model reference with the CAA records explained spoke when designing the per-publisher per-domain cross-layer cryptographic-key-custody- and-CA-authority-binding-publication discipline that bounds the per- publisher per-domain per-key-lifetime replay-attack-and-misissuance-attack surface across the DKIM private-key custody surface, the VMC X.509 cert private-key custody surface, AND the upstream CAA-RR CA-authority-binding publication surface that together compose the per-publisher per-domain cryptographic-anti-spoofing-anti- replay-and-anti-misissuance posture's full attack-surface bound.
• Domain Security Checker - live DNS lookups for SPF, DKIM, DMARC. Verifies the current DKIM public key under any selector and reports the DNS TTL.
• Email Header Analyzer - paste a suspected replayed messages headers and inspect the DKIM-Signature details: selector, signed-header list, body-hash algorithm, signature timestamp.
• BIMI SVG Tiny PS logo requirements - the PER-PUBLISHER-PER-DOMAIN-BIMI- SVG-BYTE-CANONICAL-VS-DKIM-BODY-BYTE- CANONICAL-FORM-PARALLEL companion to this DKIM-replay-attack threat-model reference. Where THIS page documents the RFC 6376 §3.5 DKIM body-hash bh= computation discipline — the per-message body byte-stream canonicalised under the per-publisher c=relaxed/relaxed or c=simple/simple selection and hashed into the per-message DKIM- Signature header where attacker captured-message replay preserves the signed body's exact byte sequence — the BIMI SVG requirements spoke documents the STRUCTURALLY-PARALLEL per-publisher per-domain BIMI-SVG-asset byte- canonical-form discipline at FOUR per- publisher per-domain BIMI-SVG-vs-DKIM- cryptographic-hash-binding parallel dimensions: (i) per-publisher per-domain BIMI SVG-asset byte-level canonical form as PUBLIC-CA-PINNED per-VMC SHA-256 hash-binding subject parallel to per-publisher per-domain DKIM body-hash bh= canonical-form-bound binding subject - the per-publisher SVG-asset's per-byte canonical form is the literal byte-stream the per-VMC SubjectAltName-embedded SHA-256 hash signs, structurally paralleling the per-message DKIM body's per-byte canonical form which is the literal byte-stream the per-message DKIM- Signature bh= hash signs; in both cases any per-byte mutation between the publisher-side hash- computation moment and the receiver-side hash-verification moment INVALIDATES the receiver-side hash match; (ii) per-publisher per-domain SVG- asset Tiny PS profile compliance as BIMI-EVALUATOR-PARSER-ACCEPTANCE precondition parallel to per-publisher per-domain DKIM canonical form c= tag value as DKIM- VERIFIER-PARSER-ACCEPTANCE precondition - the BIMI evaluator's SVG parser refuses validation of SVG bytes containing any forbidden element-class (<script>, <foreignObject>, <animate>, <image>), structurally paralleling the DKIM verifier's canonical-form parser refusing validation when the per-publisher c= tag selection conflicts with the per-message body byte- composition; (iii) per-publisher per-domain SVG-asset 32 KiB file-size cap as BIMI-evaluator-acceptance upper-bound parallel to per-publisher per-domain DKIM l=-tag body-length-limit partial-body-coverage attack class THIS page documents in §6 - the BIMI Tiny PS profile imposes a per-asset 32 KiB upper-bound that bounds the per-publisher per-domain SVG-asset attack-surface against oversize-SVG denial-of-service attempts, structurally paralleling the per-publisher per-domain DKIM l=-tag body-length-limit partial-body-coverage class THIS page's threat-model documents as a per-publisher per-domain attacker- controlled-body-extension exposure; and (iv) per-publisher per- domain BIMI SVG-asset svg_validator CI- integration as per-publisher per- domain pre-publication compliance gate parallel to per-publisher per- domain pre-rotation DKIM opendkim-testkey CI- integration the per-publisher per- selector key-rotation discipline THIS page documents depends on - the BIMI Group's reference svg_validator integrates into the per-publisher per-domain CI pipeline to gate pre-publication SVG-asset acceptance, structurally paralleling the per-publisher per- selector opendkim-testkey CI integration the per-publisher per- selector rotation discipline THIS page documents depends on for pre- publication DKIM-key-rotation gate acceptance. Pair THIS DKIM-replay threat-model reference with the BIMI SVG requirements spoke when designing the per-publisher per-domain dual- cryptographic-hash-binding-asset- custody-and-publication discipline that bounds the per-publisher per- domain per-asset-lifetime byte- canonical-form mutation surface across BOTH the DKIM body-hash- binding-asset custody surface AND the BIMI SVG-hash-binding-asset custody surface that together compose the per-publisher per-domain cryptographic-hash-bound-asset publication-discipline posture's full per-byte-canonical-form attack-surface bound.
• Reverse DNS / PTR records for mail servers
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures — the normative source; section 8.6 describes replay explicitly.
• IETF DKIM working group documents — the current DKIM2 drafts, the protocol-level work in progress.
• RFC 8058 - One-Click List-Unsubscribe - mandatory since February 2024 for gmail and yahoo bulk senders. Lowers the economic value of replayed marketing mail by letting victims unsubscribe immediately.
• RFC 8617 - Authenticated Received Chain (ARC) - the receiver-side mechanism for recording each hop a message traversed. ARC chain inspection is one of the few receiver-side signals that distinguishes a replay from a legitimate delivery.
• DMARC forensic reports (RUF / AFRF) — the DKIM-REPLAY-ATTACK-AS-PER-AFRF- EVIDENCE-STREAM companion to this DKIM replay-attack threat-model reference. Where THIS page documents the RFC 6376 §6.2.2 DKIM-replay attack class (capture-and-rebroadcast of cryptographically- valid signed messages to attacker-chosen recipients, defeating per-receiver DKIM verification at scale until the key rotates or the x= expiry passes), the DMARC-forensic-reports spoke is the per- message AFRF / IODEF evidence-stream reference documenting the RFC 7489 §B.2 / RFC 6591 forensic-report channel whose per-message message/rfc822 embedded-part preservation is the FORENSIC-GRAIN artefact the operator's incident-response team needs to reconstruct a replay incident's per-message provenance chain. The DKIM-REPLAY-ATTACK-VS-AFRF- EVIDENCE-STREAM cross-reference establishes FOUR structurally-distinct per-replay- attack-stage-vs-AFRF-evidence-row dimensions: (i) per-message capture-stage AFRF evidence — the per-message message/rfc822 embedded part preserves the byte-exact ORIGINAL DKIM-Signature header the attacker captured from a single legitimately-signed message before rebroadcast — the per-AFRF embedded-part byte-fidelity invariant is the ONLY forensic-grain artefact that lets the SIRT confirm the attacker's input was a legitimate publisher-signed message (vs a forged signature) by replaying the byte- exact b= tag through the publisher's per-selector public-key TXT record; the DMARC-forensic-reports spoke documents this RFC 7489 §B.2 byte-preservation contract THIS page's replay-attack threat- model identifies as the operator's only per-incident-byte-fidelity evidence anchor; (ii) per-message rebroadcast-stage AFRF evidence — the per-AFRF envelope's Source-IP: + Reported- Domain: + Original-Recipient: AFRF-header fields per-RFC 6591 §3.1 attribute the per-message replay-rebroadcast to the attacker-controlled egress IP outside the publisher's authorized SPF range — the per-AFRF per-message Source-IP-vs- publisher-SPF-range divergence is the canonical replay-detection signature THIS page documents the receiver-side operator watches the per-rua aggregate stream for; the DMARC-forensic-reports spoke documents the per-AFRF per-source-IP attribution granularity that complements the per-rua aggregate Stage 2 per-source-IP row- aggregation surface; (iii) per- message envelope-vs-header rewrite divergence AFRF evidence — the per-AFRF embedded message/rfc822 part preserves the byte-exact To: / Cc: / Bcc: header set the attacker rewrote during rebroadcast, which canonical replay attacks expand from a few legitimate recipients to thousands of attacker-chosen recipients — the per-AFRF per-message header-set-vs-envelope- RCPT-TO divergence is the structural signature of the per-message replay-attack class THIS page documents the operator differentiates legitimate-forwarding-with-list-expansion from per-message replay-attack rebroadcast; the DMARC-forensic-reports spoke documents the per-AFRF embedded-part byte-fidelity invariant that lets the SIRT extract the full attacker-rewritten recipient set per replay incident; (iv) per-message x= expiry-window-boundary AFRF evidence — the per-AFRF embedded part preserves the byte-exact DKIM-Signature header containing the x=<timestamp> RFC 6376 expiry tag the attacker's rebroadcast is bounded by — the per-AFRF per- message x= tag value is the per-message replay-window-bound evidence the SIRT correlates with the per-rotation- cycle DKIM key-rotation discipline to attribute the replay-attack rebroadcast to a specific per-publisher per-selector cryptographic-trust-anchor window; the DMARC-forensic-reports spoke documents the per-AFRF embedded-part DKIM-Signature byte- preservation that surfaces this per-message per-rotation-cycle replay-window-boundary evidence. Read the DMARC-forensic-reports spoke alongside THIS DKIM-replay-attack threat-model reference whenever the operator authors the per-replay-incident SIRT playbook — the per-message AFRF / IODEF evidence stream is the SOLE per-message- byte-fidelity per-source-IP-attribution per-recipient-set-rewrite per-x=-window- boundary forensic-grain artefact the receiver-side aggregate-row observability THIS page documents at the Stage 2 per- source-IP per-disposition row-aggregation granularity does NOT preserve.
• ARC (Authenticated Received Chain) — the PER-FORWARDER-HOP-CRYPTOGRAPHIC- CHAIN-OF-CUSTODY-MECHANISM companion to this DKIM-replay-attack threat-model reference. Where THIS page documents the DKIM-replay-attack threat-model (rebroadcast of a legitimately-signed per-message DKIM-Signature to an attacker-controlled recipient set within the x=-window- boundary, per-source-IP rebroadcast- attribution observability at Stage 2 receiver-side aggregate-row granularity, per-publisher per- selector rotation-cadence as the canonical replay-window-shrinkage defence), the ARC-explained spoke is the per-forwarder-hop tamper- evident chain-of-custody companion documenting FOUR ARC-replay-defence coordination dimensions whose per-publisher per-domain satisfaction provides the per-message provenance evidence-grain the DKIM-replay- attack threat model THIS page documents tracks at the aggregate- row granularity: (i) per- forwarder-hop ARC-Seal tamper- evidence at the RFC 8617 §5 ARC- chain-validation boundary preserves per-message provenance through legitimate forwarder hops — the ARC-Seal authoring discipline at each forwarder hop cryptographically seals the prior-hop ARC-Set against tampering, producing a per-message per-hop provenance chain that distinguishes legitimate forwarder rebroadcast (ARC-chain extends with verifiable per-hop attribution) from attacker rebroadcast (no ARC-chain authoring authority, leaving the per-message ARC-chain unmodified at the original-publisher boundary); the ARC spoke documents the per-forwarder-hop ARC-Seal authoring discipline whose per- message tamper-evidence materially complements the per- publisher per-selector rotation- cadence replay-window-shrinkage defence THIS page documents; (ii) per-receiver ARC-chain- validation-vs-DKIM-replay-evidence cross-reference at the receiver- side per-message authentication layer surfaces per-rebroadcast- attribution finer than aggregate- row granularity — when a per-receiver ARC-validator consumes the ARC-chain alongside the original per-message DKIM-Signature, the per-receiver per-message verdict can distinguish "original publisher signature + extended ARC chain through legitimate forwarder" from "original publisher signature + rebroadcast to attacker-controlled recipient set with NO ARC-chain extension"; the ARC spoke documents the per-receiver per-message ARC- chain-vs-DKIM-Signature cross- reference observability that surfaces per-rebroadcast attribution evidence finer than the aggregate- row Stage 2 granularity this page documents; (iii) per-publisher per-domain ARC-signer trust-anchor publication discipline at the per- publisher per-domain DNS-publication- boundary determines whether the per-publisher per-domain forwarder path's ARC-Sets can be validated at the receiver-side — the per-publisher per-domain decision about which forwarders' ARC-signers are included in the per-publisher per-domain trust-anchor catalogue determines the per-publisher per- domain forwarder-path ARC-rescue baseline; the ARC spoke documents the per-publisher per-domain ARC- signer trust-anchor publication discipline operationally consumed at the per-receiver per-message ARC-chain-validation boundary; (iv) per-message ARC-chain- vs-DKIM-Signature x=-window-boundary coordination at the per-publisher per-domain replay-defence boundary materially shrinks the attacker's rebroadcast-window-of-opportunity — the per-message ARC-chain timestamps (t= tag in each ARC-Seal) provide per-hop chronological evidence that narrows the per-message rebroadcast- window-of-opportunity within the per-publisher per-selector x=-window-boundary this page documents; the ARC spoke documents the per-message ARC- chain-timestamp evidence that materially shrinks the per-message rebroadcast-window-of-opportunity within the per-publisher per- selector x=-window- boundary the canonical replay- defence relies on. Read the ARC spoke ALONGSIDE this DKIM-replay- attack threat-model reference whenever the per-publisher per- domain operator scopes a per- publisher per-domain replay-attack defence baseline — the DKIM-replay- attack threat model THIS page documents IS the per-message per- recipient-set per-rebroadcast attack-surface primitive whose per-forwarder-path-vs-attacker- path distinction the per-message ARC-chain preservation mechanism the ARC spoke documents encodes the per-message tamper-evident provenance defence for.
• DKIM alignment with DMARC - the PER-MESSAGE-DKIM-d-TAG-VS-RFC-5322- FROM-DOMAIN-ALIGNMENT-VERDICT-AS-LOAD-BEARING- DMARC-LEG-PRECONDITION-THE-REPLAY-ATTACKER- INHERITS-FROM-THE-ORIGINAL-MESSAGE companion to this DKIM replay-attack threat model. Where THIS page documents the RFC 6376 §6.2.2 capture-and-rebroadcast attack class (replaying a cryptographically-valid signed message to attacker-chosen recipients), the DKIM-alignment-with-DMARC spoke is the RECEIVER-SIDE DMARC-LEG-PRECONDITION reference documenting how the DKIM d=-tag's organizational domain must align with the RFC 5322 From header's organizational domain (per the Public Suffix List boundary) for the DKIM leg of the DMARC OR-conjunction to contribute a dmarc=pass verdict at all. The REPLAY-ATTACK-VS-DKIM-ALIGNMENT- VERDICT cross-reference establishes FOUR structurally-distinct per-replay-message DMARC-disposition inheritance dimensions: (i) the DKIM d=-tag and the RFC 5322 From header are both members of the DKIM-signed-headers set; replaying the byte-identical signed message preserves both fields verbatim — so the per-message DKIM- alignment verdict the replay attacker inherits is IDENTICAL to the original message's verdict; the DKIM-alignment-with- DMARC spoke documents why the alignment verdict is byte-deterministic in the canonicalized signed-headers set; (ii) when the original message DKIM-aligns (d=-org-domain == From-org-domain) the replay attack inherits dkim=pass AND DKIM-alignment-pass at the receiver, which means the replay also inherits dmarc=pass regardless of the replay's source IP — the SPF leg fails for the attacker-controlled relay but the DKIM-aligned- leg satisfies the RFC 7489 §6.6.2 OR- conjunction on its own; the DKIM- alignment-with-DMARC spoke documents this OR- conjunction semantics and why a DKIM-aligned- replay defeats DMARC enforcement without needing SPF authorization; (iii) the replay-attack class is therefore EXCLUSIVELY a DKIM-alignment-mediated abuse — a message whose original DKIM verdict was DKIM- cryptographic-pass-but-DKIM-alignment-fail (e.g. third-party-sender re-signing with a non-publisher d=-tag) cannot be weaponized via replay because the inherited verdict was already a DMARC-fail; the DKIM-alignment-with-DMARC spoke documents the relaxed-vs-strict alignment modes whose publisher-configured choice determines which original-message DKIM-pass-but-DKIM-alignment- fail edge cases the replay attacker can or cannot exploit; (iv) the replay- attack defence per Stage-6 operator-side per-source-IP DKIM-pass-divergence detection requires the operator to FIRST confirm the per-domain DKIM-aligned baseline this DKIM- alignment-with-DMARC spoke documents — without a stable per-publisher DKIM-alignment-pass floor, the per-source-IP divergence signal the replay-detection discipline this page motivates cannot distinguish replay-attack rows from legitimate-third-party-DKIM-realignment rows; the DKIM-alignment-with-DMARC spoke documents the publisher-side DKIM- alignment-coverage baseline the replay- detection discipline must reference. Read the DKIM-alignment-with-DMARC spoke alongside this page when designing a replay-attack detection pipeline so the operator can distinguish per-source-IP DKIM-aligned-pass rows attributable to replay (attacker-relay source-IPs) from those attributable to legitimate-third-party-DKIM-realignment (SaaS-sender egress source-IPs).
• MTA-STS vs DANE — the PER-PUBLISHER-PER-DOMAIN- TRANSPORT-LAYER-AUTHENTICATION- PUBLICATION-DISCIPLINE-CHOICE-AS-LOAD- BEARING-PEER-CRYPTOGRAPHIC-DEFENCE-LAYER companion to this DKIM-replay-attacks reference. Where THIS page documents the per-message DKIM-replay-attack mitigation discipline at the application layer (per-message DKIM signature expiration via t= / x= timestamp tags, per-publisher per- selector key-rotation cadence as replay- window-shortening discipline, per- receiver per-message replay-detection windowing as receiver-side defence), the MTA-STS-vs-DANE spoke is the peer per-publisher per-domain transport-layer authentication-publication-discipline choice whose Web-PKI-anchored MTA-STS or DNSSEC-anchored DANE approach is the peer cryptographic-defence-layer choice complementing the per-message replay- mitigation discipline THIS page documents at FOUR per-cryptographic- defence-layer coupling dimensions: (i) per-cryptographic-defence-layer coverage parallelism — application- layer per-message replay-mitigation vs transport-layer per-session peer- authentication — the per-message DKIM-replay-attack mitigation discipline THIS page documents prevents per-message-content replay at the application-layer signature-verification boundary, transport-layer MTA-STS or DANE peer- authentication-publication-discipline the MTA-STS-vs-DANE spoke documents prevents per-receiver per-session per-MX hop man-in-the-middle replay- injection at the transport-layer peer- authentication boundary, and the per- publisher per-domain complete cryptographic-defence-layer posture requires BOTH layers' cryptographic- defence to compose at per-message-and- per-session replay-attack boundary; (ii) per-publisher per-domain cryptographic-trust-anchor-publication- layer cross-layer replay-defence coordination — the per- publisher per-selector DKIM cryptographic- trust-anchor publication (per-selector public-key at <selector>._domainkey.<domain>) is the per-publisher per-domain application-layer trust-root the per- message replay-mitigation discipline THIS page documents binds against, the per- publisher per-domain MTA-STS Web-PKI certificate-validation trust-root and DANE DNSSEC TLSA-RR trust-root the MTA- STS-vs-DANE spoke documents are the per- publisher per-domain transport-layer trust-roots the per-session peer- authentication-replay-defence binds against, and the per-publisher per- domain operator-side per-layer cryptographic-trust-anchor-publication coordination is the load-bearing per- layer replay-defence rhythm BOTH layers share; (iii) per-publisher per- domain replay-window-discipline operational-cadence parallelism — the per-publisher per-selector DKIM key-rotation cadence THIS page documents as the per-publisher per- domain application-layer replay-window- shortening discipline pairs operationally with the per-publisher per-domain MTA- STS max_age: cache-window- discipline OR DANE TLSA-RR TTL- discipline the MTA-STS-vs-DANE spoke documents the per-protocol-choice rationales of as the per-publisher per- domain transport-layer policy-cache- window-shortening discipline, and the per-publisher per-domain operator-side per-layer per-cache-window-cadence coordination is the load-bearing per- layer replay-window-discipline rhythm BOTH protocols share; (iv) per- publisher per-domain cross-layer cryptographic-defence-layer-coverage as load-bearing per-publisher per-domain operator-side complete replay-attack- defence posture — the per-publisher per-domain operator-side cross-layer cryptographic-defence- layer-coverage that composes the per- message DKIM-replay-attack mitigation discipline THIS page documents at the application layer with the per-publisher per-domain MTA-STS-or-DANE transport- layer peer-authentication-publication- discipline choice the MTA-STS-vs-DANE spoke documents is the per-publisher per-domain complete replay-attack- defence cryptographic-defence-layer coverage every per-publisher per-domain DMARC-deployment programme requires for complete cross-layer cryptographic- defence-posture coverage. Read THIS page when DESIGNING per-message DKIM- replay-attack mitigation discipline; read the MTA-STS-vs-DANE spoke when COMPLEMENTING the per-publisher per- domain peer transport-layer authentication-publication-discipline choice (Web-PKI-anchored MTA-STS or DNSSEC-anchored DANE) whose per- publisher per-domain transport-layer peer-authentication-publication- discipline is the load-bearing peer cryptographic-defence-layer of the per- publisher per-domain complete cross- layer replay-attack-defence posture THIS page documents the application- layer half of.
• TLS-RPT report format — the per-publisher per-domain RFC 8460 TLS-RPT JSON-aggregate report as peer transport-layer downgrade-attack observability primitive companion to this per-message DKIM-replay-attack mitigation discipline. Where THIS page documents the per-message DKIM-replay-attack mitigation application-layer half of the complete cross-layer cryptographic-defence-posture, the TLS-RPT-report-format spoke documents the RFC 8460 JSON-aggregate report schema that is the LOAD-BEARING transport-layer downgrade-attack observability primitive operators MUST co-ingest to detect the transport-layer downgrade attacks that precede DKIM-replay-attack opportunities. Four DKIM-REPLAY-ATTACK-MITIGATION-VS-TLS- RPT-JSON-AGGREGATE-REPORT cross-correlation axes the TLS-RPT-report-format spoke documents: (i) the per-publisher per-domain transport-layer downgrade attack (the active in-flight STARTTLS-stripping adversary) surfaces in the per-day TLS- RPT JSON-aggregate as a recurring failure-details.result-type=starttls-not-supported attribution row class — the per-message DKIM-replay-attack mitigation discipline STRUCTURALLY DEPENDS on STARTTLS-encrypted envelope-transport to deny adversaries the opportunity to capture-and-replay DKIM- signed message bodies, so the per-day JSON-aggregate's downgrade-attack attribution rows are the LOAD-BEARING transport-layer precursor evidence operators read alongside the application-layer DKIM-replay-attack attribution evidence; (ii) the per-publisher per-domain transport-layer certificate-substitution attack (the active in-flight man-in-the-middle adversary presenting a different X.509 leaf) surfaces in the per-day TLS-RPT JSON-aggregate as failure-details.result-type=certificate-host-mismatch or certificate-not-trusted attribution rows — the cross-layer cryptographic-defence-posture investigation discipline requires operators to co-ingest these transport-layer attribution rows with the application-layer DKIM-replay- attack attribution evidence to attribute the complete adversary capability chain; (iii) the per-publisher per-domain per-MX-host successful-STARTTLS-session- count aggregation (the summary.total- successful-session-count per-day per-MX aggregate) is the LOAD-BEARING baseline operators read to detect deviation- from-baseline as a transport-layer downgrade- attack signal — a per-day per-MX successful- session-count cliff against a stable historical baseline is the canonical transport-layer downgrade-attack detection KPI; (iv) the per-publisher per-domain cross-layer cryptographic-defence-posture investigation discipline requires the per- publisher per-day TLS-RPT JSON-aggregate co-ingested with the per-publisher per- day DMARC RUA aggregate AND the per-message DKIM-replay-attack forensic attribution stream — the JSON-aggregate's per-failure failure-details rows attribute transport-layer downgrade-attack opportunities, the RUA aggregate's policy_evaluated rows attribute application-layer authentication verdicts, and the per-message DKIM-replay- attack forensic attribution stream attributes the application-layer capture-and-replay attack execution — together they form the complete cross-layer cryptographic-defence- posture observability stream. Read THIS page when DESIGNING per-message DKIM- replay-attack mitigation discipline; read the TLS-RPT-report-format spoke when DECODING the per-day RFC 8460 JSON- aggregate that completes the cross-layer cryptographic-defence-posture observability stream alongside the application-layer DKIM-replay-attack mitigation evidence stream.
• DANE explained — the per-publisher per-MX DANE TLSA- record transport-layer cryptographic-trust- anchor publication-discipline companion to this DKIM-replay-attacks reference. Where THIS page documents the per-message DKIM- cryptographic-signature capture-and-replay attack-class catalogue (the application- layer per-message signature-capture attack pattern, the per-publisher per-selector key- rotation-as-mitigation discipline, the per- message t= / x= timestamp-window mitigation discipline, the per-publisher per-selector single-use- nonce-binding mitigation discipline), the DANE-explained spoke is the PER-PUBLISHER- PER-MX-RFC-7672-TLSA-RECORD-AS-DNSSEC- ANCHORED-TRANSPORT-LAYER-CRYPTOGRAPHIC- TRUST-ANCHOR-PUBLICATION reference documenting the per-publisher per-MX TLSA- record byte-grammar (certificate usage / selector / matching type / certificate association data), the per-MX-host _25._tcp.<mx-host> TLSA publication, the DNSSEC zone-signing prerequisite, and the per-MX cryptographic- trust-anchor binding gate that authenticates the receiving-side STARTTLS cert at the transport layer. Four CROSS-LAYER- CRYPTOGRAPHIC-PUBLICATION-VS-CRYPTOGRAPHIC- ATTACK-MITIGATION-COUPLING dimensions the DANE-explained spoke documents: (i) per-message application-layer DKIM-signature attack-surface vs per-MX transport-layer TLSA cryptographic-trust- anchor coverage parallel — the per-message DKIM-replay attack-class this page catalogues operates at the application layer, while the per-MX DANE TLSA-record publication operates at the transport layer — together they form the cross-layer cryptographic-trust-anchor publication defence-posture every per-publisher per- domain authentication discipline composes; (ii) per-message DKIM-signature- replay-window vs per-MX TLSA-record cryptographic-trust-anchor-rotation-window coupling — the per-publisher per- selector key-rotation overlap-window discipline this page documents (publish new DKIM selector, overlap, retire old) parallels the per-publisher per-MX TLSA-record cryptographic-anchor-rotation discipline (publish new TLSA value with overlap, retire old) — both are per-publisher per-domain cryptographic-anchor-rotation-window publication-discipline primitives; (iii) per-message DKIM-replay- attribution forensic-evidence vs per-MX TLSA- failure transport-layer forensic-evidence coupling — the per-message DKIM- replay-attack forensic-attribution evidence this page documents (per-message DKIM- Signature header capture, per-publisher per-selector replay-evidence stream) is cross-correlated with the per-MX TLSA- failure forensic-evidence (TLS-RPT JSON- aggregate per-day per-receiver-MX certificate-host-mismatch / tlsa-invalid attribution) to produce the complete cross-layer cryptographic-defence-posture observability stream; (iv) per-publisher per- domain DNSSEC-zone-signing-discipline coupling — DANE TLSA-record verification requires DNSSEC-signed zones, so the per-publisher per-domain DNSSEC publication-discipline is the load-bearing upstream prerequisite for the per-MX transport-layer cryptographic-trust-anchor mitigation that complements the per-message DKIM-replay-attack mitigation this page documents. Read the DANE-explained spoke alongside this DKIM-replay-attacks reference when DESIGNING the per-publisher per-domain cross-layer cryptographic-trust-anchor- publication defence-posture that pairs the application-layer per-message DKIM-replay- attack mitigation discipline with the transport-layer per-MX DANE TLSA-record cryptographic-trust-anchor publication discipline.
• Why SPF alone is insufficient — the per-publisher per-domain SPF-ONLY- PUBLISHER-AS-DKIM-REPLAY-IRRELEVANT companion to this DKIM-replay-attack threat-model reference. Where THIS page documents the per- message DKIM-replay attack class (per-message capture-and-rebroadcast of a legitimately DKIM-signed message, post-signature-validation per-message verdict reuse, per-publisher per- selector replay-window-bounding via per- selector DKIM-key rotation, per-receiver per- message replay-cache defence), the why-SPF- alone-is-insufficient spoke documents the per- publisher per-domain SPF-only THREAT-MODEL coverage gap that makes the per-message DKIM- replay threat-model THIS page documents OPERATIONALLY-IRRELEVANT for SPF-only publishers (and conversely, operationally- relevant only for per-publisher per-domain DKIM-and-DMARC publishers). Three per-DKIM- replay per-publisher per-domain publication-discipline-relevance dimensions the why-SPF-alone-is-insufficient spoke supplies the per-publisher per-domain operator MUST UNDERSTAND at the per-publisher per- domain authentication-stack-coverage rationale tier: (i) per-publisher per-domain SPF-only-publication-discipline- as-DKIM-replay-irrelevant at the per-message message-authenticity-publication-discipline- absence tier — the per-message DKIM- replay threat-class THIS page documents depends on the per-publisher per-domain publication of per-selector DKIM-Signature cryptographic-message-authenticity primitives; a per-publisher per-domain SPF-only operator has no per-message DKIM-Signature to replay and the per-message DKIM-replay threat-class is structurally inapplicable, BUT this operationally means the per-publisher per- domain SPF-only operator is INSTEAD exposed to the per-message body-and-headers-post- SPF-pass-mutability attack class (which the why-SPF-alone-is-insufficient spoke catalogues as the per-publisher per-domain SPF-only message-integrity-coverage gap); the per- publisher per-domain operator transitioning from SPF-only to SPF+DKIM TRADES the per- message post-SPF-pass mutability attack surface for the per-message DKIM-replay attack surface THIS page documents — and the why-SPF-alone-is-insufficient spoke documents the per-publisher per-domain trade-off rationale; (ii) per-publisher per- domain DMARC-alignment-publication-discipline- as-DKIM-replay-enforcement-bypass-amplifier at the per-publisher per-domain DMARC-pass- with-DKIM-valid-and-aligned tier — the per-message DKIM-replay attack THIS page documents is OPERATIONALLY DANGEROUS SPECIFICALLY because per-message DKIM-pass- and-aligned yields per-message DMARC-pass which bypasses per-publisher per-domain DMARC p=reject enforcement; the why- SPF-alone-is-insufficient spoke documents the per-publisher per-domain alignment-mode- publication-discipline rationale that creates the per-message DMARC-pass-with-DKIM-valid- and-aligned per-publisher per-domain enforcement-bypass-amplifier in the first place (per-publisher per-domain SPF-only operators have no DMARC, and per-publisher per-domain SPF+DKIM-without-DMARC operators have no enforcement to bypass — the per- message DKIM-replay attack is RELEVANT only at the per-publisher per-domain SPF+DKIM+ DMARC publication discipline tier); (iii) per-publisher per-domain SPF-only- publication-discipline-as-replay-equivalent at the per-message envelope-MAIL-FROM- controlled-replay tier — the per- publisher per-domain SPF-only publication discipline EXHIBITS a STRUCTURALLY- ANALOGOUS per-message replay equivalent attack class: a per-publisher per-domain SPF-only operator's per-message SPF-pass verdict is REPLAYABLE by any sender controlling the per-publisher per-domain envelope MAIL FROM (per-message envelope- layer replay), and the per-publisher per- selector DKIM-key-rotation cadence the replay-defence discipline THIS page recommends has NO per-publisher per-domain SPF-only equivalent (per-publisher per- domain SPF TXT-RR is per-domain-static, not per-message-bounded). Read the why-SPF- alone-is-insufficient spoke ALONGSIDE this DKIM-replay-attack threat-model reference whenever the per-publisher per-domain operator AUDITS the per-publisher per- domain DKIM-replay-relevance-as-DKIM- adoption-rationale at the per-publisher per-domain authentication-stack-coverage decision tier.
• Email deliverability — the per-publisher per-domain DELIVERABILITY-ENGINEERING-OPERATIONAL companion to this per-message DKIM- replay-attack threat-model reference. Where THIS page documents the per- message DKIM-replay attack class (per- message capture-and-rebroadcast of a legitimately DKIM-signed message that passes per-receiver per-message DKIM- signature validation despite being a replayed-not-originated message, per- publisher per-selector replay-window- bounding via per-selector DKIM-key rotation, per-receiver per-message replay-cache defence), the email- deliverability spoke documents the per- publisher per-domain deliverability- engineering operational discipline whose per-recipient mailbox-provider sender- reputation scoring surface the per- message DKIM-replay attack class materially degrades. The composition operates through the per-recipient sender-reputation-degradation cascade: a per-message DKIM-replay attack successfully rebroadcasts a per- publisher-signed message to per- recipient mailbox-providers with the original per-message DKIM-valid-and- aligned verdict still intact, causing per-recipient mailbox-providers to attribute the replayed per-message spam-or-phishing payload to the per- publisher per-domain sender-reputation scoring surface — the per-publisher per-domain operator observes a per- recipient mailbox-provider sender- reputation regression that DEGRADES the per-publisher per-domain deliverability- engineering operational baseline the email-deliverability spoke catalogues. The per-publisher per-domain DKIM-key- rotation cadence THIS page recommends as the load-bearing per-message replay- window-bounding defence is therefore ALSO a per-publisher per-domain deliverability-engineering preventive discipline — a per-selector DKIM-key rotated on a tight cadence bounds the per-message replay-window narrowly, which bounds the per-recipient mailbox- provider sender-reputation-degradation exposure narrowly. Read THIS page when AUTHORING the per-publisher per-domain per-message DKIM-replay-defence discipline; read the email-deliverability spoke when UNDERSTANDING the per- publisher per-domain deliverability- engineering operational baseline whose per-recipient mailbox-provider sender- reputation scoring surface the per- message DKIM-replay attack class THIS page documents materially degrades at the per-recipient per-publisher reputation-attribution-boundary tier.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the per-publisher per-domain DMARC policy-tier publication-discipline canonical reference (the p=none monitoring-mode tier, the p=quarantine spam-folder- disposition tier, the p=reject SMTP-time- rejection tier; the per-organisational- domain vs per-subdomain sp=-tag override discipline; the pct=-tag percentage- gradual-enforcement ramp discipline) whose per-publisher per-domain DMARC- policy-mode publication CEILING is the per-message DKIM-replay-attack mitigation upper-bound the per-message DKIM-replay-attack threat-model THIS page documents materially DOES NOT breach. The composition operates through FOUR per-published-policy-mode- vs-DKIM-replay-attack-mitigation- ceiling coupling dimensions every per- publisher per-domain operator must reason about: (i) p=none-tier publication- ceiling — per-publisher per-domain p=none monitoring-mode provides ZERO per-message DKIM-replay- attack mitigation at the per-recipient mailbox-provider per-message disposition boundary because the per- published policy explicitly instructs the receiver to apply NO enforcement regardless of DMARC composite-verdict outcome; the per-message DKIM-replay attack — which by construction produces per-recipient per-message DMARC composite-PASS via captured- DKIM-signature reuse — would be delivered to per-recipient inbox even if DMARC's published policy somehow could discriminate replay from legitimate (which it cannot); (ii) p=quarantine-tier publication-ceiling — per-publisher per-domain p=quarantine spam-folder-disposition tier still provides ZERO per-message DKIM-replay- attack mitigation because per-message DKIM-replay attacks BY-CONSTRUCTION produce per-recipient per-message DMARC composite-PASS at the receiver- side evaluation — the per-recipient per-message disposition signal the per-published p=quarantine tier instructs the receiver to apply ONLY ACTIVATES on DMARC composite- fail rows; replay messages are NOT quarantined regardless of per- publisher per-domain policy-mode choice; (iii) p=reject- tier publication-ceiling — even the most aggressive per-publisher per- domain p=reject SMTP- time-rejection tier provides ZERO per-message DKIM-replay-attack mitigation because per-message DKIM- replay attacks BY-CONSTRUCTION produce per-recipient per-message DMARC composite-PASS — the per-recipient per-message disposition signal the per-published p=reject tier instructs the receiver to apply ONLY ACTIVATES on DMARC composite- fail rows; the per-message DKIM- replay attack class THIS page documents is the canonical threat- model class that BYPASSES the per- publisher per-domain DMARC-policy- tier publication-discipline ceiling at the per-recipient per-message disposition boundary regardless of which tier the per-publisher per- domain operator publishes; (iv) per- publisher per-domain DKIM-replay- attack mitigation requires COMPLEMENTARY per-publisher per- domain controls DISTINCT FROM the per-publisher per-domain DMARC- policy-tier publication-discipline ceiling — including per-message DKIM- Signature x=-tag signature-expiration timestamp publication discipline (bounding the replay window narrowly), per- publisher per-domain per-selector tight-cadence key-rotation discipline (bounding the per-selector-bound replay-window narrowly), per-message RFC 8058 List-Unsubscribe header publication discipline (limiting the per-message replay-amplification reach narrowly), AND per-publisher per-domain per-recipient-feedback- stream ingestion (detecting per- recipient mailbox-provider reputation regression rapidly); the per-publisher per-domain operator- side per-message DKIM-replay-defence discipline THIS page documents operates IN ADDITION TO — not WITHIN — the per-publisher per- domain DMARC-policy-tier publication-discipline ceiling the DMARC-policy-modes spoke documents. Read THIS page when AUTHORING the per-publisher per-domain per- message DKIM-replay-defence discipline; read the DMARC-policy- modes spoke when SELECTING the per- publisher per-domain DMARC-policy- tier publication discipline AND UNDERSTANDING the publication- discipline-ceiling DKIM-replay attacks STRUCTURALLY BYPASS at the per-recipient per-message disposition boundary.
• BIMI explained — the PER-PUBLISHER-PER-DOMAIN-BIMI-BRAND- INDICATOR-RENDERING-AS-RECEIVER-SIDE- COMPLEMENT-TO-PUBLISHER-SIDE-DKIM-REPLAY- MITIGATION companion to THIS DKIM-replay- attack threat-model reference. Where THIS page documents the RFC 6376 §6.2.2 DKIM- signature replay-attack class (per-attacker capture-and-rebroadcast of cryptographically- valid signed messages to attacker-chosen recipients, defeating the per-publisher per- selector DKIM-aligned-pass authentication- evidence floor at the per-receiver per- message authentication boundary) and the per-publisher per-selector mitigation control set (per-publisher per-selector RFC 6376 x= tag short-validity-window publication, per-publisher per-selector key- rotation cadence floor, per-publisher per- selector replay-resistant body-coverage canonicalization choice), the BIMI explained spoke documents the per-recipient per-message inbox-list-display layer visual brand- authenticity signal at FOUR per-BIMI- indicator-vs-DKIM-replay coupling dimensions: (i) per-publisher per-domain BIMI brand-indicator rendering AS per-recipient per-message visual brand-authenticity- confirmation signal compressing per-attacker DKIM-replay amplification surface — per-attacker DKIM-replay campaigns weaponise per-publisher legitimate-but- captured cryptographically-valid signed messages to deliver attacker-chosen payload content to attacker-chosen recipient sets under the per-publisher per-domain legitimate-sender identity; the per-publisher per-domain BIMI brand-indicator rendering eligibility cascade (per-publisher DMARC p=quarantine or p=reject floor + per-publisher per-VMC X.509-certificate chain-of-trust binding + per-publisher per-domain BIMI selector TXT-RR publication) IS the per- recipient per-message visual brand- authenticity signal at the per-recipient inbox-list display layer that per-recipient anti-phishing visual-evaluation pattern recognition consumes to discriminate per-publisher legitimate-brand mail-stream from per-attacker per-message brand- impersonation campaigns even when the per- attacker per-message envelope passes per- publisher per-selector DKIM cryptographic validation via per-attacker capture-and- replay; (ii) per-publisher per-VMC chain-of-trust X.509 cryptographic-binding AS publisher-side identity-floor complementing per-selector DKIM-replay bounded-validity-window discipline — the per-publisher per-VMC X.509- certificate chain-of-trust binding to the per-publisher per-domain BIMI selector TXT- RR's a= tag is the per-publisher per-domain trademark-authority-issued cryptographic-identity-assurance primitive that anchors per-publisher per-domain brand- identity at the per-recipient inbox-list display layer; this anchors a per-publisher per-domain identity-floor distinct from the per-publisher per-selector RSA-2048-or- Ed25519 cryptographic-key-based authentication floor THIS page documents the DKIM-replay bounded-validity-window discipline for; per- publisher per-VMC chain-of-trust binding cannot be replayed by per-attacker capture- and-rebroadcast because the per-publisher per-VMC X.509-chain-of-trust validation happens at per-receiver per-message rendering-time independently of per-message per-selector DKIM-signature cryptographic validation; (iii) per-publisher per- domain BIMI rendering eligibility cascade AS per-receiver-side DMARC-enforcement-floor observability primitive complementing per- publisher per-selector DKIM-replay observability discipline — the per- receiver per-message BIMI indicator- rendering decision is structurally observable to the per-publisher per-domain operator via per-receiver per-message inbox-list-display- layer rendering surveys; this provides per- publisher per-domain operator-side DMARC- enforcement-floor observability that complements the per-publisher per-selector DKIM-aligned-pass-rate-floor observability THIS page documents as the per-publisher per-selector replay-resistance evidence stream; (iv) per-publisher per- domain BIMI publication discipline AS multi- layer trust-signal coordination at the per- publisher per-domain brand-protection- authority publication boundary — per-publisher per-domain BIMI publication coordinates per-publisher per-VMC issuance + per-publisher per-domain BIMI selector TXT- RR publication + per-publisher per-domain DMARC enforcement-floor maintenance + per- publisher per-domain SPF + DKIM composite-authentication baseline publication into a per-publisher per-domain brand-protection unified trust-signal coordination posture; the per-publisher per-selector DKIM-replay mitigation discipline THIS page documents IS the per- publisher per-selector input to the per- publisher per-domain composite-authentication baseline that the per-publisher per-domain BIMI publication discipline rests on top of. Read THIS page when BOUNDING per-publisher per-selector DKIM-replay attack surface; read the BIMI explained spoke when UNDERSTANDING how the per-publisher per- domain BIMI brand-indicator-rendering eligibility cascade STRUCTURALLY COMPLEMENTS the per-publisher per-selector DKIM-replay mitigation discipline THIS page documents at the per-recipient per-message inbox-list-display layer brand-authenticity verification boundary.
• SPF forwarding issues
• DMARC deployment checklist
• DMARC for Office 365 hybrid — per-publisher per-selector DKIM replay-attack mitigation discipline THIS page documents (per-selector RSA-2048+ key- strength floor / per-message x= expiry-tag short-window publication / per- publisher per-stream-segregation selector- naming discipline) IS the load-bearing per-publisher per-selector application- layer authentication-integrity pre- condition the per-publisher per-domain hybrid M365 DKIM dual-selector publication discipline THIS hybrid-deployment spoke documents materially depends on — hybrid M365 tenants with on-prem-Exchange-plus- Exchange-Online dual-egress topology must baseline both egress legs' per-selector replay-mitigation discipline (per-leg independent key-strength floor + per-leg independent selector-rotation cadence) to preserve per-publisher per-domain DMARC- aligned-pass-rate floor against per- attacker per-message DKIM-replay-driven mail-stream contamination at the per- publisher per-domain composite hybrid- M365-deployment-and-DKIM-replay-mitigation coordination boundary.
• DMARC for Microsoft 365 — the PER-M365-TENANT-PER-ACCEPTED-DOMAIN-DMARC-COMPOSITE-VERDICT-DETECTION-DISCIPLINE-AS-LOAD-BEARING-DOWNSTREAM-CONSUMER-OF-PER-PUBLISHER-PER-SELECTOR-DKIM-REPLAY-MITIGATION-DISCIPLINE companion at four per-M365-tenant per-accepted-domain DMARC-vs-DKIM-replay-mitigation coupling dimensions: (i) per-M365-tenant per-accepted-domain DMARC RUA aggregate-report per-day per-source-IP per-row attribution-stream IS the load-bearing per-tenant per-accepted-domain detection-evidence stream surfacing per-attacker per-message DKIM-replay emission stream as anomalous per-source-IP per-day DMARC-aligned-pass-rate-distribution distortion within the per-M365-tenant own-egress source-IP set the DKIM-replay diagnostic THIS page documents the per-publisher per-selector mitigation-discipline of materially depends on for incident-detection visibility; (ii) per-M365-tenant per-accepted-domain DMARC fo=1/fo=d/fo=s failure-reporting-options publication-discipline per RFC 7489 §6.3 IS the load-bearing per-tenant per-accepted-domain forensic-report opt-in publication-discipline surfacing per-attacker per-message DKIM-replay incident-evidence to the per-publisher per-selector replay-mitigation operational discipline THIS page documents; (iii) per-M365-tenant per-accepted-domain DMARC adkim=s/adkim=r alignment-mode publication-decision IS the load-bearing per-tenant per-accepted-domain identifier-alignment publication-discipline whose per-receiver per-message strict-vs-relaxed alignment-evaluation determines whether per-attacker per-message DKIM-replay with mis-aligned header-From: domain is rejected at the receiver-side DMARC composite-verdict layer; (iv) per-M365-tenant per-accepted-domain DMARC p=reject terminal-stage publication-discipline IS the load-bearing per-tenant per-accepted-domain composite-verdict-enforced terminal-action publication-decision whose per-receiver per-message reject-action against per-attacker per-message DKIM-replay-with-broken-alignment closes the per-tenant per-accepted-domain anti-replay defense-in-depth floor the per-publisher per-selector DKIM replay-mitigation discipline THIS page documents the application-layer leg of.
• MTA-STS explained
• DMARC for cPanel — the shared-hosting DKIM-deployment context where the replay threat this page documents must still be reasoned about. cPanel's Email Deliverability tool auto-generates a single DKIM keypair under the default selector for each domain, and shared-hosting operators rarely rotate it or set a short x= expiry — exactly the conditions that widen the per-message replay window this page warns about. The cPanel guide documents where the auto-generated DKIM record lives, how to verify the default._domainkey TXT-RR, and the limits of cPanel's tooling (no built-in dual-selector overlap rotation), so a cPanel operator can recognise when the default DKIM posture leaves replay exposure that needs a manual selector-rotation or per-message expiry workaround. Read the cPanel spoke when assessing replay risk on a cPanel-hosted domain.
• Microsoft SNDS + JMRP monitoring — a valid DKIM signature does not outrank a bad IP reputation at Outlook.com: SNDS shows how Microsoft's consumer network actually graded each sending IP (GREEN/YELLOW/RED) and JMRP surfaces the Junk clicks behind a degraded verdict.

14. Audit your domain for DKIM replay exposure now

DMARC Analyzer's Domain Security Checker performs a live recursive lookup of any published DKIM public key under a given selector (via includes/DnsChecker.php), reporting the key algorithm, key size, canonical selector name, and the DNS TTL of the published TXT record. Short TTLs (300 seconds) and current key ages bounded by a short rotation cadence (weekly or monthly) are the single most effective sender-side replay defences. The Email Header Analyzer parses the DKIM-Signature header from any captured message (via includes/EmailHeaderParser.php) and surfaces the signer's selector, algorithm, signed-header list, and signature timestamp - the data you need to confirm whether a suspected replayed message originally came from your signing infrastructure or another high-reputation sender.

Check my DKIM public key Sign up — Free plan