Almost every bank has DMARC. Most still let spoofed email through
New 2026 reports show DMARC adoption is near-universal at banks, but only a minority enforce p=reject — the one setting that actually blocks spoofing.
By Norbelys Chirinos, Co-founder
Founder-reviewed ·How we research and correct articles
A July 2026 sector analysis of DMARC adoption inside financial services lands on an uncomfortable number: the industry that has arguably the most to lose from a spoofed “your account has been locked” email is also, disproportionately, one that published the record but never flipped the switch that actually stops the attack. Adoption of DMARC is nearly universal in finance. Enforcement of it is not.
The gap in one word: policy
A DMARC record isn’t one setting, it’s three, and the distance between them is the whole story:
p=none— publish the record, watch what happens via aggregate reports, block nothing.p=quarantine— send failing mail to spam.p=reject— refuse failing mail outright.
Only the third one actually stops a spoofed message from reaching an inbox. The first two are visibility, not defense — useful steps on the way there, as we’ve written before, but frequently mistaken for the finish line rather than the on-ramp.
PowerDMARC 2026 US and Canada DMARC & MTA-STS Adoption Reports
Even reading the Canadian banking figure on its own terms, it means 58% of banking-sector domains in that sample remain, by the report’s own framing, susceptible to sophisticated spoofing — despite the same sector showing DMARC records on nearly every domain checked. Adoption solved the “did you publish a record” question years ago. It never solved the “does anything actually happen when someone spoofs you” question, and that second question is the one that protects a customer from a fake fraud alert.
What “susceptible to spoofing” looks like from the outside
It’s worth walking through what a domain sitting at p=none or p=quarantine actually hands an attacker, because “susceptible” undersells how mechanical the exploit is. With no enforced policy, an attacker doesn’t need to compromise anything at the bank — they register a similar domain or, in the p=none case, simply send mail claiming to be from: the real one, and the receiving mailbox has no instruction to do anything about the mismatch beyond, at best, logging it in an aggregate report nobody’s reading in real time. p=quarantine at least routes the forgery to spam by default, which is real protection most of the time, but a quarantine policy that isn’t set to 100% enforcement (DMARC lets you ramp enforcement as a percentage of mail, precisely so senders can test safely) leaves a deliberate gap that a receiver may or may not honor consistently. p=reject is the only setting where the receiving mailbox itself refuses the message outright, before a customer ever has the chance to open it, click it, or “verify” a fraudulent transaction inside it.
Where the rest of the stack falls apart too
DMARC enforcement isn’t the only place financial services shows this same adoption-without-follow-through pattern. The same reporting line notes that within the sector, SPF correctness sits around 90.9% — genuinely strong — while MTA-STS adoption, the mechanism that protects the connection itself in transit rather than authenticating the message’s identity, sits at roughly 3.0%. That’s not a rounding gap, it’s a different mechanism nobody finished rolling out.
| Mechanism | What it protects | Reported financial-sector figure |
|---|---|---|
| DMARC record present | Whether a policy exists at all | Adoption reported as near-universal |
| DMARC at p=reject | Whether spoofed mail is actually blocked | Materially lower than record presence — see chart above |
| SPF configured correctly | Which servers may send as your domain | ~90.9% |
| MTA-STS adopted | The delivery channel itself, in transit | ~3.0% |
MTA-STS and its reporting counterpart, TLS-RPT, are a genuinely different layer of protection from DMARC — DMARC says “is this message really from who it claims,” MTA-STS says “was the connection that delivered it actually encrypted the way it should have been.” A sector that’s diligent about the first and has barely touched the second has a real, specific hole, not just a rounding error in an adoption survey.
Why “we have DMARC” keeps meaning less than it sounds like
Part of the reason this gap persists industry-wide, not just in finance, is that moving from p=none to p=reject is genuinely risky if you haven’t done the groundwork first — every legitimate sending source your domain uses (marketing platforms, support tools, billing systems, the outbound sales stack) has to be inventoried and properly authenticated before reject mode goes live, or you start blocking your own mail. That’s real, unglamorous work, and it’s exactly the kind of project that gets published as “in progress” for a lot longer than anyone intends. The fix isn’t a shortcut around that process — it’s tooling that makes the process itself faster to run and safer to verify before you flip the switch.
The realistic path from p=none to p=reject
Publish p=none and let the reports accumulate
This is where most financial-sector domains already are. It's not wasted effort — the aggregate reports it generates are the only reliable inventory of every system currently sending as your domain, including ones nobody remembers setting up.
Inventory every legitimate source the reports surface
Marketing platforms, support ticketing systems, payroll and billing tools, and the outbound sales stack all typically send as your domain and all need SPF and DKIM authentication of their own before you can safely block anything that isn't them.
Move to p=quarantine at a low enforcement percentage first
DMARC lets you enforce on a fraction of mail (pct=) rather than switching all at once. Ramping from 10% to 50% to 100% over weeks, watching reports the whole time, is what prevents a legitimate system you forgot about from getting silently dropped.
Only move to p=reject once quarantine has run clean at 100%
This is the step most organizations stall on indefinitely, because it's the one where a mistake is visible immediately rather than quietly. Sitting at quarantine for months while treating it as 'basically done' is exactly the pattern these adoption figures are describing at scale.
Why this matters beyond the banks themselves
Financial services is the sharpest example in this data, but the underlying failure mode — publish, then stall — is not unique to banks. Any cold-email sender operating in a regulated or trust-sensitive space (fintech, healthcare-adjacent B2B, legal services) is exposed to the same reputational math: your own domain’s authentication posture gets compared, implicitly, against the standard a mailbox provider expects from anyone claiming to be a serious, trustworthy sender. A domain that’s been sitting at p=none for a year doesn’t just risk being spoofed by someone else — it also reads, to an increasingly automated set of mailbox-provider trust signals, as a domain that never finished the basic hygiene work everyone else in its category has been asked to do.
Frequently asked questions
If DMARC adoption is already near-universal, why does enforcement lag so far behind?
Moving to p=reject requires inventorying every legitimate system that sends as your domain first, or you risk blocking your own mail. That inventory work is unglamorous, easy to deprioritize, and easy to declare 'in progress' indefinitely — which is exactly the pattern these 2026 adoption figures describe at industry scale.
Does p=quarantine offer meaningfully less protection than p=reject?
It offers real protection — spoofed mail is routed to spam rather than the inbox — but only if enforcement is set near 100% and the receiving mailbox honors it consistently. p=reject removes that ambiguity: the receiving server refuses the message outright, before it's ever a judgment call.
Is this financial-sector data relevant to a company that isn't a bank?
Yes — the specific numbers are sector data, but the underlying pattern (adoption without enforcement) shows up across industries. Any domain sitting at p=none or an incompletely-enforced p=quarantine has the same exposure, just without a sector report calling it out by name.
Where Norbelys fits
This is precisely the gap Norbelys’s DMARC monitoring is built to close — not just confirming a record exists, but tracking your aggregate reports over time so you can see exactly which sending sources are authenticated, which aren’t, and when it’s actually safe to move from p=none to p=quarantine to p=reject without breaking legitimate mail in the process. If your organization is one of the many sitting on a published-but-unenforced record, that’s the exact project Norbelys is designed to shorten from a multi-quarter initiative to something you can actually finish.
See how DMARC monitoring fits into Norbelys’s plans or read how to read your own aggregate reports as the starting point — then get your domain to p=reject on a platform that’s actually watching the reports with you, not just confirming a DNS record exists once and moving on.