DMARC for banks: why financial brands are prime spoofing targets

The consumer-brand vs corporate-domain trap

There's a subtlety specific to large institutions, and it's worth calling out because it hides real exposure. A bank often has a polished, well-protected corporate domain (the one on press releases and investor pages) while the consumer-facing brand domain — the one customers actually receive mail from and would recognize — lags behind at p=none. Security teams point to the protected corporate domain; attackers target the exposed consumer one.

Assessing a bank — or one's own organization — means checking the domain customers see in their inbox, not just the corporate parent. That's the address fraud will impersonate. Our per-domain check pages show the verdict for the exact domain entered, which is what tells the two apart.

Not only customers: staff and counterparties

Spoofing a bank's domain isn't aimed solely at the public. The same forged From: works against the bank itself: a fake message from the fraud team sent to a branch employee, or one from treasury sent to a corporate client asking to update payment details. These targeted attacks are expensive precisely because they borrow the most credible internal identity there is — nobody questions an instruction that appears to come from their own house. p=reject protects those flows too, on one condition that's often overlooked: the bank's own inbound gateway must actually evaluate DMARC. Publishing a strict policy protects the rest of the world against the domain; honoring it on the way in protects the bank's own teams against it. The two moves belong together, and the second one depends on nobody else.

DORA, NIS2 and the regulatory tailwind

For financial entities in the EU, this is no longer only a security question — it's increasingly a compliance one. DORA (the Digital Operational Resilience Act) raises expectations around ICT risk management and protection against intrusion for the financial sector, and NIS2 broadens cybersecurity obligations across critical industries. Neither names "DMARC" explicitly, but email authentication is an obvious, auditable control for the anti-phishing and operational-resilience expectations they set. On top of that, the Gmail and Yahoo sender requirements already make DMARC table stakes for anyone sending at volume — which every bank does. We cover separately what DORA actually demands on the email side, and how NIS2 translates into concrete email obligations.

The direction is unambiguous: enforced DMARC is shifting from "good security hygiene" to "expected control." Banks that get there early turn a looming obligation into a trust advantage. And for an ISO 27001 certified institution, the internal case is half-made already: DMARC fits squarely into the Annex A controls.

How a bank should approach DMARC

The method is the same as any large sender's, executed with extra rigor because the sending estate is big:

1. Inventorying the full sending estate. Every business line, every region, every third-party platform (statements, marketing, fraud alerts, e-signature, surveys). DMARC goes up at p=none and the aggregate reports surface the sources nobody knew about — there are always some.
2. Aligning each legitimate source. SPF and DKIM go right for every platform until each shows an aligned pass. DKIM alignment is the durable target, especially given forwarding.
3. Treating each brand domain separately. The consumer domain deserves the same enforcement as the corporate one — arguably more, since it's the one customers trust.
4. Ramping deliberately. First quarantine, then reject, with the reports watched at each step. (Percentage-based rollout via pct is removed by DMARCbis in favor of the t=y testing mode — see below.) The full sequence is in how to get to p=reject without breaking email.
5. Staying there. Sending estates drift — new vendors appear. Continuous monitoring keeps the domain at enforcement instead of quietly regressing.

DMARCbis and banking subdomains

DMARCbis (RFC 9989, May 2026) lands at the perfect time for banks, which often run dozens of subdomains — alerts., statements., secure., news. — and leave just as many non-existent but spoofable. The new np tag sets the policy for subdomains that don't exist: an np=reject shuts down an attack surface that sp alone never covered, with zero risk to legitimate mail since nothing sends from those subdomains. For a financial brand, that's a near-zero-cost hardening. DMARCbis also replaces the Public Suffix List with a DNS Tree Walk (up to eight queries) to identify the organizational domain — more predictable across the complex domain trees of large groups. Nothing to re-architect: the existing record stays valid; it's simply the moment to add np and drop a now-useless pct.

In practice, a bank's rollout order barely changes: the root domain and its real sending subdomains reach an aligned p=reject first, then np=reject slams the door on the fictitious ones an attacker would otherwise invent. Because the new tags are backward-compatible, they can go up now and receivers that haven't adopted DMARCbis yet will simply ignore what they don't recognize — there's no downside to being early, and a real upside in closing the non-existent-subdomain gap that phishing kits love to probe.

Beyond reject: BIMI and the verified logo

Reaching p=reject unlocks something banks in particular should want: BIMI (Brand Indicators for Message Identification). BIMI displays a verified logo next to the bank's messages in supporting inboxes — a visible trust mark placed exactly where customers decide whether an email is genuine. For a brand whose entire business runs on trust, that placement is valuable real estate.

The crucial detail is that BIMI requires DMARC at enforcement (quarantine or, ideally, reject). No logo shows until the work described in this article is done. That turns the spoofing-prevention project into a brand-visibility win: the same p=reject that stops impersonation also earns the logo that makes legitimate mail instantly recognizable — and makes a logo-less forgery look conspicuously off.

Most inbox providers that honor BIMI also expect a VMC (Verified Mark Certificate), which cryptographically ties the logo to a registered trademark. That's a natural fit for established financial brands, which almost always hold registered marks. The sequence is therefore unambiguous: every sender aligned, p=reject reached, then BIMI published with a VMC.

It is the final rung of the ladder. p=none merely documents the exposure; p=quarantine and p=reject close it; BIMI converts that hard-won enforcement into a customer-facing signal of authenticity that competitors stuck at p=none simply cannot display. It is worth planning the BIMI step from the start of a DMARC program — not because it lights up first, but because knowing the logo is the prize helps justify the enforcement work to stakeholders who care about brand as much as security.

Checking a bank — or one's own domain

Where a given bank stands today is a question our free analyzer answers with an instant verdict, while the Observatory compares a whole market at a glance. Inside a financial institution, the place to start is the domain customers actually receive mail from.

Getting a large, multi-domain estate to p=reject is real work — and it's exactly what Thomas, the virtual CISO, is built to carry. He names every sending source across the estate, generates the precise DNS to publish (DMARCbis tags included), scores readiness per domain on rolling data, and says when each one is safe to enforce.

Analyze a domain free · explore the Observatory · get started with Thomas. For a first approach to the topic, the general introduction to the standard is the place to begin.