How-to Compliance

DORA Phishing Protection: A Technical Playbook for Financial Entities

The Digital Operational Resilience Act (DORA) expects financial entities to detect and respond to impersonation and phishing attacks. Here is how to map that expectation to a concrete control program.

April 19, 2026 · 9 min read

TL;DR

  • 1 DORA Chapter II requires financial entities to detect and respond to anomalous activity, including third-party impersonation.
  • 2 Two halves: DMARC enforcement (stop direct domain spoofing) + lookalike monitoring (catch impersonation domains).
  • 3 Article 17 incident reporting needs a structured trail — alerts, actions, and dispositions linked to specific assets.

What it does

The Digital Operational Resilience Act (DORA) became applicable to EU financial entities on 17 January 2025. Chapter II requires ICT risk management that covers detection of anomalous activities, including third-party impersonation — which is the regulatory term for phishing-domain impersonation of the financial entity OR of its partners.

DORA is more prescriptive than NIS 2 about controls and evidence. Article 9 (preventive measures), Article 10 (detection), and Article 17 (incident reporting) collectively require: anti-phishing controls at the email layer (DMARC enforcement), anti-impersonation controls at the brand layer (lookalike-domain monitoring), and an incident-reporting trail with structured evidence.

Penalties are real: up to 2% of total annual worldwide turnover for ICT-related incidents that breach DORA. Auditors look for evidence of operating controls, not policy documents — which means continuous DMARC reporting, continuous lookalike monitoring, and a documented incident-response workflow with timestamps.

How it works

  1. 1

    <strong>DMARC at <code>p=reject</code> with daily report ingestion.</strong> Articles 9 + 10 require both prevention (enforcement) and detection (continuous monitoring of authentication failures).

  2. 2

    <strong>SPF + DKIM alignment across every legitimate sender.</strong> The base layer that makes <code>p=reject</code> safe. CNAME-delegated DKIM at each ESP; SPF under the 10-lookup limit.

  3. 3

    <strong>MTA-STS + TLS-RPT.</strong> Forces TLS on inbound mail (prevention) and surfaces failures (detection). Required for Tier 1 institutions; recommended for everyone.

  4. 4

    <strong>Lookalike-domain monitoring with multi-signal scoring.</strong> Anti-impersonation control under Article 10. Continuous, not quarterly. Signal-scored to separate active threats from registered-but-inactive variants.

  5. 5

    <strong>Forensic (RUF) report collection on high-value senders.</strong> When a DMARC failure happens on a sensitive flow (transactional email, customer notifications), forensic reports preserve the full message envelope for incident analysis.

  6. 6

    <strong>Structured incident-reporting workflow.</strong> Article 17's reporting deadlines (early warning + initial + intermediate + final reports) require the workflow to be rehearsed. Build the playbook in advance, including the regulator notification path for your jurisdiction.

  7. 7

    <strong>Continuous audit trail.</strong> Every detection, action, and disposition linked to actor + timestamp + outcome. The trail is the evidence DORA auditors evaluate.

Common pitfalls

  • <strong>Treating DORA as policy.</strong> Articles 9 and 10 are operational. Evidence of running controls is what matters; policy documents alone fail the audit.

  • <strong>Stopping at <code>p=quarantine</code>.</strong> Quarantine is detection; <code>p=reject</code> is enforcement. DORA's prevention requirement implies enforcement.

  • <strong>Ignoring third-party impersonation.</strong> DORA covers impersonation of the financial entity AND its third-party providers. Brand monitoring needs to cover providers (cloud vendors, banking partners, KYC providers) the entity depends on.

  • <strong>Manual incident reporting.</strong> The 24/72/120-hour reporting clocks (depending on incident severity) leave no room for ad-hoc reporting. Build the structured workflow before an incident hits.

  • <strong>No tested recovery plan.</strong> Article 11 requires response and recovery plans tested at least annually. Tabletop exercises are not optional; document them.