# Why is DMARC Vital for the Banking Industry? > Banks are prime targets for email fraud. See why DMARC matters, how far U.S. banks have adopted it, and how to roll it out to p=reject safely. # Why is DMARC Vital for the Banking Industry? The banking sector has always been a prime target for cybercriminals, and the shift to digital services has amplified the risk. As customers conduct more of their banking online, email-based attacks (phishing, spoofing, and payment scams) have grown into one of the most reliable ways to defraud both institutions and their customers. Email authentication is the control that decides whether a message claiming to come from your bank is allowed to reach an inbox at all. ## What is DMARC and how does it protect banks? DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on [SPF](/tools/spf) and [DKIM](/tools/dkim) to verify that email claiming to come from a bank's domain is actually authorized to use it. When a message fails DMARC checks, the receiving server can quarantine or reject it, which stops fraudsters from impersonating the bank in the From address. You can inspect any domain's published policy with the free [DMARC checker](/tools/dmarc). The DMARC specification was updated in 2026: [RFC 9989 (DMARCbis)](https://datatracker.ietf.org/doc/rfc9989/) replaced the original 2015 standard, along with RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. Records still begin with `v=DMARC1` and existing deployments keep working, so a bank that already publishes DMARC does not need to rebuild it, but the update is a good prompt to confirm your policy and reporting are current. ![Comparison of the three DMARC policies, none, quarantine, and reject, showing what each does and how many banks use it.](/images/figures/why-is-dmarc-vital-for-banking-industry-fig1.webp "1200x488") *Source: Palisade analysis of 1,338 .bank domains that publish DMARC.* - **None (`p=none`):** No action is taken; reports are still generated so you can see who sends on your behalf. - **Quarantine (`p=quarantine`):** Suspicious messages are routed to the spam folder. - **Reject (`p=reject`):** Unauthenticated messages are blocked outright before delivery. ## How widely is DMARC adopted in U.S. banks? Industry estimates have put the average annual cost of cybercrime for financial-services firms at roughly **$18.3 million**, among the highest of any sector. In 2021 there were **4,236 FDIC-insured commercial banks** in the United States. Palisade's analysis of 2,646 `.bank` domains found that only **1,338 (≈50%)** published a [DMARC record](/tools/dmarc) at all. Among those 1,338 banks: - 89 (6.65%) use a `none` policy. - 56 (4.18%) use `quarantine`. - 1,193 (89.1%) use `reject`, but **406 (34%)** of those reject-policy banks do not publish a `rua` tag, meaning they enforce a strong policy while missing the [DMARC reports](/resources-post/how-to-understand-dmarc-reports) that would tell them what is being blocked and why. The takeaway is uncomfortable: half of U.S. banks give attackers a domain they can freely spoof, and a third of the banks that reach enforcement do so blind, with no reporting to catch a misconfiguration that silently drops legitimate mail. ## Why are banks such high-value targets for email fraud? A spoofed bank email is worth more to an attacker than almost any other lure. Three attack patterns dominate: - **Customer phishing.** Fraudsters send "account locked" or "verify your transfer" emails from the bank's real domain, harvesting credentials and one-time codes. - **[Business email compromise](/learning/what-is-the-complete-guide-to-business-email-compromise-bec-attacks-in-2025) (BEC).** Attackers impersonate the bank or its executives to authorize wire transfers, change payment details, or request sensitive records. - **Brand and reputation damage.** Even blocked-but-visible spoofing erodes the trust a bank depends on, and every fraudulent message that lands generates support cost and, potentially, liability. DMARC at enforcement removes the easiest version of all three by ensuring only authorized servers can send mail from the bank's exact domain. ## Which compliance frameworks push banks toward DMARC? Email authentication increasingly shows up where regulators and standards bodies address phishing and payment fraud. The [PCI DSS v4.0 requirements](/learning/does-pci-dss-4-0-require-dmarc) call for anti-phishing controls that DMARC directly supports, and financial-sector guidance on customer protection consistently points to authenticating outbound mail. Treat DMARC less as a checkbox and more as the baseline control auditors now expect to see on a customer-facing sending domain. ## How should a bank roll out DMARC to enforcement? Rushing straight to `p=reject` is the fastest way to block your own statements and alerts. Roll out in stages instead: 1. **Publish `p=none` with reporting.** Add a DMARC record with a `rua` address so aggregate reports start flowing. Palisade's free [DMARC record generator](/tools/dmarc-generator) produces a valid record you can paste into your DNS as a `TXT` record. 2. **Authenticate every legitimate sender.** Use the reports to find every service that sends as your domain (core banking platform, statement provider, marketing tool, help desk) and bring each into [SPF](/tools/spf) and [DKIM](/tools/dkim) alignment. 3. **Move to `p=quarantine`, then `p=reject`.** Once reports show your legitimate mail passing, tighten the policy in steps, watching for any authorized source you missed. ![Four steps to add DMARC: generate the record, copy the string, paste it into DNS as a TXT record, then configure SPF and DKIM.](/images/figures/why-is-dmarc-vital-for-banking-industry-fig2.webp "1200x699") *Source: Palisade.* ## Common issues with a bank DMARC rollout ### Why did legitimate statements stop arriving after I set p=reject? A sending source you did not authenticate is now being rejected. Check your aggregate reports for a passing-by-IP source that fails alignment, often a statement vendor or a marketing platform on a subdomain. Roll back to `p=quarantine`, fix that source's SPF or DKIM alignment, then re-tighten. ### I published DMARC but see no reports. What's wrong? Either the record has no `rua` tag or the mailbox address in it cannot receive mail. Confirm the record with the [DMARC checker](/tools/dmarc), verify the `rua` mailbox exists, and remember that some receivers require a DNS authorization record before they will send reports to an address outside your domain. ### SPF passes but DMARC still fails. Why? DMARC needs *alignment*, not just a pass. If SPF authenticates the envelope (Return-Path) domain rather than the visible From domain, DMARC fails on SPF. Align the visible From domain, or rely on a properly aligned DKIM signature. Compare both against the From domain in your reports. ### We have too many sending sources to track by hand. This is the normal state for a bank with core systems, statements, cards, and marketing all sending mail. Continuous [DMARC reporting](/resources-post/how-to-understand-dmarc-reports) (rather than a one-time audit) is what keeps a new or forgotten sender from silently breaking authentication after you reach enforcement. ## Quick takeaways - Only about half of U.S. banks publish DMARC at all, leaving the rest freely spoofable. - Of banks that use DMARC, 89% choose `reject`, the strongest setting, but a third of those omit `rua` and enforce blind. - DMARC, together with [SPF](/tools/spf) and [DKIM](/tools/dkim), sharply cuts phishing and BEC risk. - Roll out in stages (`none` with reporting, then `quarantine`, then `reject`) to avoid blocking your own mail. - The DMARC standard was refreshed as RFC 9989 in 2026; existing `v=DMARC1` records keep working. - Strong [email authentication](/learning/what-is-email-authentication-and-why-does-it-matter) protects both customers and the bank's brand. ## Frequently asked questions ### What is the difference between SPF, DKIM, and DMARC? SPF checks the sending IP, DKIM adds a cryptographic signature, and DMARC tells receivers how to handle messages that fail SPF or DKIM and whether those results align with the visible From domain. Together they form a layered defense. ### Should a bank publish DMARC on domains it does not send from? Yes. Parked and non-sending domains are a favorite spoofing target. Publish a `p=reject` record with no authorized senders on any domain that should never send mail, so receivers block anything claiming to come from it. ### How often should a bank review DMARC reports? At least monthly, and immediately after any change to policy or sending infrastructure. Reports are how you catch a new vendor, an expired DKIM key, or a misconfiguration before it drops legitimate customer mail. ### Do we need to change our DNS provider to add DMARC? No. DMARC, SPF, and DKIM are ordinary DNS records you add to your existing zone. You can check the result any time with the [Email Security Score](/tools/email-security-score). ### What if we are not ready for a reject policy? Start at `p=none` to gather data with no delivery impact, authenticate every legitimate sender, then step up to `quarantine` and finally `reject` as your reports confirm clean mail flow. Ready to secure your bank's email? [Get started with Palisade](https://app.palisade.email/signup) or [book a demo](https://calendly.com/sam-palisade/30min) to see your domains move toward enforcement.