Do the companies holding your money secure their email? We scanned 67 banks and fintechs

The companies holding billions of dollars are ruthless about email authentication—but only halfway. We scanned 67 of the world's largest banks, payment networks, brokerages, and crypto exchanges for email security posture, and found a paradox: nearly universal adoption of DMARC and SPF (the frontline defenses against email spoofing), yet zero percent implementation of transport-layer security standards like MTA-STS.

What we measured

On June 24, 2026, we ran live DNS-over-HTTPS lookups (via Cloudflare) against the email domains of 67 major financial institutions. These are the same DNS checks that power the Domain Posture dossier. We looked for four authentication signals:

• SPF (Sender Policy Framework): does the domain list authorized mail servers?
• DMARC (Domain-based Message Authentication, Reporting and Conformance): does the domain specify how receivers should handle authentication failures?
• DKIM (DomainKeys Identified Mail): is there detectable signing at common selector names?
• MTA-STS & TLS-RPT: do they enforce transport security and report delivery failures?

One important caveat: we captured a snapshot. DNS records change; these findings reflect the configuration on the date shown. Custom DKIM selectors beyond common names are undercounted in our DKIM detection.

Banks set the bar on DMARC

The results show an industry that has internalized the threat of email spoofing—and responded decisively:

| Metric | Count | Percentage | |--------|-------|-----------| | Domains with MX records | 66 of 67 | 98.5% | | SPF present | 67 of 67 | 100% | | SPF with hardfail (-all) | 36 of 67 | 53.7% | | SPF with softfail (~all) | 30 of 67 | 44.8% | | DMARC present | 66 of 67 | 98.5% | | DMARC p=reject | 57 of 67 | 86.6% | | DMARC p=quarantine | 8 of 67 | 11.9% | | DMARC p=none | 1 of 67 | 1.5% | | DMARC rua reporting enabled | 65 of 67 | 98.5% | | DKIM detectable | 39 of 67 | 58.2% | | MTA-STS published | 0 of 67 | 0% | | TLS-RPT published | 0 of 67 | 0% |

Every single bank publishes SPF. Nearly all (98.5%) have DMARC, and 98.5% of those enforce it with a strict policy. The strongest setting, p=reject, is in place at 23 major institutions:

Adyen, American Express, Bank of America, Barclays, Capital One, Chase, Citi, Coinbase, Goldman Sachs, HSBC, JPMorgan, Kraken, Mastercard, Morgan Stanley, PayPal, Revolut, Santander, Schwab, Square, Stripe, Visa, Wells Fargo, and Wise.

This is how you stop email spoofing at scale. These institutions recognize that their domain is a target, and they've locked it down.

The one that didn't

There is exactly one exception in our cohort: ICICI Bank, a major retail bank with millions of customers, published no DMARC record at all.

This is a material gap. Without DMARC, a domain is vulnerable to spoofing—an attacker can send emails that appear to come from that domain, and most mail servers will have no directive to reject them. Given the scale of ICICI Bank's customer base and the phishing risk this creates, this is not a small oversight.

The caveat: our scan is a snapshot from June 24, 2026. It is possible (though unlikely) that the record has since been added. But as of that date, ICICI Bank's email domain was unprotected by DMARC. To check whether a domain can be spoofed, use the Domain Posture dossier.

The blind spot: nobody's doing transport security

Here's the paradox. Every bank defends against spoofing at the policy level. But zero of the 67 published MTA-STS records, and zero published TLS-RPT.

MTA-STS forces incoming mail servers to use encrypted TLS connections when delivering to your domain. Without it, an attacker on the network can downgrade to unencrypted SMTP or intercept the connection entirely. TLS-RPT lets you receive reports when delivery fails due to certificate problems.

These are not exotic. They're the standard follow-up once you've locked down spoofing. Yet even banks, which treat email security as mission-critical, have universally skipped them.

This suggests either that MTA-STS adoption remains low industry-wide (plausible), or that it's not yet considered essential enough for mainstream deployment (also plausible). Either way, it's a missed opportunity. If your domain holds customer trust, MTA-STS is a cheap way to defend it.

If you run a fintech domain

The bar is now visible. If you operate a bank, payment network, broker, or crypto exchange:

• Publish SPF with -all (hardfail, not softfail). Every bank in our cohort does.
• Publish DMARC with p=reject. 86.6% of the financial services sector does.
• Set up rua reporting to monitor authentication failures.
• Enable DKIM signing.

Then go further: add MTA-STS to force transport security. None of the incumbents have, but you can. It takes a few DNS records and an MTA-STS.txt file on your domain.

Check your domain's DMARC →

Further reading

• State of Email Authentication 2026—the full research report
• What is DMARC?—policy basics
• SPF softfail vs hardfail—why -all matters
• Do I need MTA-STS?—transport security explained
• Is my domain spoofable?—check your posture