When Banks Get Spoofed: Analyzing the DMARC Gaps That Left Millions of Customers Exposed

The scale of the problem

In 2017, a study by the Global Cyber Alliance found that less than 20% of Fortune 500 companies had a DMARC policy stronger than p=none. Among financial institutions — an industry that handles some of the most sensitive personal and financial data in existence — the numbers were similarly alarming.

The irony is stark: banks invest heavily in physical security, fraud detection, and regulatory compliance. Yet the DNS records that determine whether anyone can impersonate their email domain were, in many cases, either missing or configured to do nothing.

How bank email spoofing works in practice

When a bank has no DMARC enforcement, an attacker can send an email with a From address of security@barclays.com, alert@paypal.com, or noreply@chase.com — and it will be delivered to the recipient's inbox.

The recipient sees the bank's domain in the From field. Most email clients display the domain name prominently and the full address is often hidden behind a display name like "PayPal Security Team." There is no visual indicator that authentication failed, because many providers do not surface this to end users.

Documented cases of financial domain spoofing

PayPal

For years, PayPal — one of the most-phished brands in the world — operated without a DMARC policy that blocked spoofing. Researchers documented dozens of campaigns where attackers spoofed @paypal.com addresses to send phishing emails requesting account verification. PayPal eventually moved to p=reject, but phishing campaigns against their users had already been running for years by the time enforcement was in place.

ING Bank

ING, serving tens of millions of customers across Europe, was found with a p=none DMARC policy during a security audit. This meant that phishing campaigns claiming to be from ING could be sent to customers in the Netherlands, Belgium, Germany, and elsewhere with the authentic-looking @ing.com or @ing.nl domain. The configuration was eventually tightened after public disclosure by security researchers.

US Government agencies

The most coordinated response to DMARC gaps in a public institution came in 2017, when the US Department of Homeland Security issued Binding Operational Directive 18-01. The directive found that a significant number of federal agencies — including departments handling sensitive personal data and law enforcement — had no DMARC enforcement. The directive required all federal email domains to reach p=reject within 12 months. By 2019, compliance had significantly improved across the .gov namespace.

Why DMARC remediation takes so long for large organizations

Large organizations are slow to reach p=reject for several interconnected reasons:

• Shadow IT email senders. Marketing platforms, CRM systems, transactional email services, HR platforms, and dozens of SaaS tools all send email on behalf of the organization. Many IT teams do not have a complete list of these senders, and moving to p=reject before they are all added to SPF and DKIM would break legitimate mail.
• Organizational complexity. A bank with dozens of subsidiaries, regional domains, and acquired businesses has a DNS sprawl problem. Each entity may have independent email infrastructure that needs to be audited.
• Risk aversion. Breaking email delivery at a bank is not a minor incident — it is a compliance event. Security teams often cannot get approval to enforce p=reject without an extended monitoring period.

What eventually forced change

Three forces drove organizations to finally enforce DMARC:

1. Regulatory mandates. Government directives (DHS BOD 18-01), PCI DSS guidance, and GDPR enforcement created compliance pressure.
2. Email provider enforcement. Google and Yahoo announced in 2023 that bulk senders must have DMARC in place, with delivery implications for those who do not. This single announcement accelerated DMARC adoption more than a decade of security recommendations had achieved.
3. Public embarrassment. Security researchers regularly publish findings about high-profile domains with weak DMARC policies. No CISO wants their organization featured in a news story about phishing vulnerabilities they could have fixed with a single DNS record.

Checking any organization's DMARC record

You can check any domain's DMARC policy yourself — including your bank, your employer, or any service you use. Look up the _dmarc.domain.com TXT record and look at the p= value. If it says none or is absent entirely, the domain can be spoofed.

Our free DMARC Analyzer makes this check instant and explains exactly what the result means.