DORA Phishing Protection: A Technical Playbook for Financial Entities

The Digital Operational Resilience Act (DORA) has been binding on financial entities across the EU since 17 January 2025. It is a sector-specific framework that layers on top of NIS 2 and GDPR, with tighter timelines and sharper teeth. Chapter II (ICT Risk Management) is where the phishing-protection expectations live.

Unlike NIS 2, DORA does not shy away from naming specific controls. Article 6 requires a sound, comprehensive and well-documented ICT risk management framework. Articles 9 and 10 enumerate protection and detection controls, including explicit mentions of identity authentication, access management, and anomaly-detection mechanisms. Article 12 requires operational resilience testing.

What DORA actually asks for on the email surface

The regulation reads at a fairly high level. The practical controls that auditors have started citing in early-2025 supervisory reviews are:

Inbound mail authentication — can you verify the sender of mail that claims to be from a partner bank, your own finance team, or a regulator? SPF / DKIM / DMARC are the objective baseline.
Outbound mail authentication — have you published the records that let OTHER financial entities verify your mail? Same stack, pointed the other way.
Brand impersonation detection — are you monitoring for lookalike domains that third parties could use to phish your customers, your vendors, or your staff? This is the gap DORA flags most frequently.
Incident classification and reporting — when a phishing campaign targets your institution, can you produce a structured incident record within the mandated windows?

Detection controls that map directly

Outbound authentication

Same stack as every other framework: SPF with -all, DKIM on every sender with RSA-2048 keys, DMARC at p=reject. The DORA-specific nuance is the reporting addresses. DMARC rua= aggregate reports must go to a mailbox that your ICT-risk function can actually read. A reports@ alias that nobody monitors satisfies the publication requirement but fails a supervisory spot-check.

Transport encryption

MTA-STS in enforce mode with a 7-day minimum max_age. Pair it with TLS-RPT so downgrade attacks surface as daily reports. In a recent supervisory review, one bank was asked to produce three months of TLS-RPT reports; "we don't collect them" was not an acceptable answer.

Brand impersonation monitoring

This is the control most often under-implemented. The expectation is documented, continuous monitoring of domains that could be used to impersonate your institution. "We looked once" is insufficient; the control has to be ongoing and produce an incident record on detection.

Minimum scope:

Typosquat variants of your primary brand and each customer-facing subdomain.
TLD swaps against the most common abusive TLDs (.com, .net, .co, .app, .dev, plus any fresh TLDs popular in phishing).
Homoglyph variants (ASCII and IDN/Punycode).
Certificate Transparency log monitoring for newly-issued certificates on similar domains. CT catches phishing infrastructure in the hour between domain registration and first attack, which is the window that matters.

Every hit should become an incident record. The record includes classification (registered lookalike, suspected impersonation, likely phishing, confirmed phishing), the evidence collected (DNS, SSL, HTTP, screenshot if possible), and the disposition (takedown filed, takedown complete, false positive, accepted risk).

Customer awareness

DORA Article 12 requires training for ICT staff. For a financial entity that means making sure customer-facing teams know what customer-targeted phishing looks like. Feed the confirmed-phishing detections from the monitoring control into the awareness program. A real example of a domain your own monitoring caught is worth ten generic training slides.

The incident-reporting piece

This is where phishing protection meets the Major ICT-Related Incident requirements in Article 19 and the Regulatory Technical Standard that operationalises it.

When a phishing campaign against your institution crosses the materiality threshold (there are criteria; consult your compliance function), you have notification windows to hit:

Initial notification: as soon as possible, and at latest within 4 hours of classification.
Intermediate report: 72 hours from the initial notification.
Final report: one month after the intermediate report.

For the phishing-protection program this means: your detection tooling needs to record incidents in a format you can turn into the required report quickly. Unstructured alert logs scraped from email do not scale to the 4-hour window.

The evidence binder for a supervisory review

What a supervisor or the Lead Overseer will ask for, typically:

Policy and framework documentation. Where in your ICT risk management framework is phishing protection addressed? Which role is accountable? Refresh cadence?
Current-state technical evidence. DNS records on the outbound side (SPF, DKIM, DMARC, MTA-STS, TLS-RPT); the domain-monitoring configuration on the detection side.
Operational evidence. 90 days minimum of DMARC aggregate reports, a sampling of TLS-RPT reports, a log of lookalike detections with their disposition.
Incident records. Any confirmed impersonation or phishing incident in the review window, classified per the DORA materiality criteria, with timeline and disposition.
Test evidence. Results of the most recent resilience testing that touched the phishing surface (TLPT, red-team, tabletop).

How PhishFence slots in

PhishFence covers the brand-impersonation monitoring and DMARC aggregate-report ingestion controls end-to-end. The audit-log export on the Business plan produces items 3 and 4 in the evidence binder in the format most financial-services auditors expect (timestamped, signed, per-incident).

The controls we do not cover (policy documentation, training program, incident classification against DORA materiality criteria, resilience-testing exercises) are on the governance side and need your own ICT-risk function to own. What we remove is the data-gathering toil, which is where most control programs drop the ball.