# DKIM replay investigation — Enterprise Email Protection + TAP

SecOpsNomad | 19 October 2026 | Original operator checklist
Article: /blog/dkim-replay-dmarc-limits/

Scope: Enterprise Email Protection and TAP. No TRAP/CLEAR dependency.
UI labels, fields and retention vary; confirm with your tenant's Help.
This procedure has not been executed in a customer tenant.
Keep completed forms and evidence in restricted incident storage.

## Case scope

- Case ID / owner:
- Approved investigation scope:
- Time zone / start / end:
- Reported recipient / receipt time:
- Message-ID (if available):

## 1. Email Protection — Smart Search / message details

- [ ] Filter by recipient and explicit time interval; use Message-ID if supported.
- [ ] Confirm direction, timestamp, recipient and retries/hops.
- [ ] Record log ID, connecting IP, envelope sender, visible From, route and action.
- [ ] Record applied policy/rule; distinguish accepted, delivered, quarantined, rejected.
- [ ] Preserve the authorized original .eml; if absent, obtain it through the mailbox evidence process.
- [ ] Record trusted Authentication-Results and d=, s=, h=, l=, t=, x= where present.
- [ ] Note unsigned visible/MIME fields and contemporaneous DNS key evidence.
- [ ] Record raw-evidence location and integrity hash; do not attach sensitive evidence to public tickets.
- [ ] Document retention, permission, time-zone or route gaps if no trace appears.

## 2. Related-message scope

- [ ] Bound the From domain, sources, recipients and time interval.
- [ ] Compare signatures/fingerprints only where raw evidence supports it.
- [ ] Account for approved forwarding, mailing lists, retries and legitimate outbound mail.
- [ ] Do not assume bh= is a searchable console field.
- [ ] Do not allowlist a sender or bypass inspection because DMARC passes.

## 3. TAP — Threat Insight Dashboard

- [ ] Match recipient and time; use supported message/threat identifiers.
- [ ] Record matching threat ID, classification, verdict and detection timeline.
- [ ] For URLs, record available click time/action and related threat; do not open the destination.
- [ ] For attachments, record filename, available hash and analysis verdict; do not open the file.
- [ ] Link TAP context to the Email Protection trace.
- [ ] If absent, record "no matching TAP threat in the available view and interval".
- [ ] Treat absence as a coverage limit, not proof of safety; a click is not proof of compromise.

## 4. Signer, containment and change validation

- Actual signing system / vendor / owner:
- Approved change / ticket / expiry / rollback:
- [ ] Review header coverage, supported oversigning, l=/x= and signing-key lifecycle at the actual signer.
- [ ] Review template/input/recipient controls and abuse limits.
- [ ] Apply only evidence-backed, narrowly scoped policy/quarantine changes.
- [ ] Coordinate delivered-mail remediation with mailbox administrators; do not assume TAP is a recall tool.
- [ ] Escalate suspected credential entry through identity response.
- [ ] Send authorized benign test mail to controlled recipients after the change.
- [ ] Verify fresh raw samples, delivery, DKIM coverage, alignment and required forwarding paths.
- [ ] Schedule recurrence review; retain before/after evidence.

## Outcome

- Confirmed facts:
- Forwarding / other plausible explanations:
- Unknowns / missing evidence:
- Containment owner / review time:
- Retest outcome / residual risk:

No live replay, attack payload, credential, tenant identifier or observed IOC is included.