Email Authentication for UK Financial Services: DMARC, SPF, and DKIM

Why financial services firms are prime targets

FCA-regulated firms — wealth managers, brokers, insurance intermediaries, payment firms — are disproportionately targeted by email-based attacks. The combination of high-value clients, wire transfer authority, and trusted brand names makes financial services firms attractive for business email compromise (BEC) and client impersonation fraud.

An attacker who successfully spoofs a wealth manager's email domain can send convincing instructions to clients to move funds to a new account. This is known as authorised push payment (APP) fraud and is the fastest-growing fraud category in the UK.

Regulatory context

The FCA's operational resilience framework and the Cyber Security and Resilience (CSR) Bill both point toward stronger controls over email communications. While neither mandates a specific DMARC policy level, the FCA's expectation that firms manage cyber risk proportionately to their size and complexity means that a DMARC p=none policy (which provides no protection) is increasingly difficult to justify in a regulated firm.

The Bank of England's CBEST framework and the FCA's Operational Resilience Sourcebook (PS21/3) both require firms to map their critical business services and understand their vulnerabilities — email infrastructure is almost always a critical service.

DMARC policy levels and what they mean for financial firms

p=none — monitoring only. Spoofed emails are delivered. The only benefit is the reports you receive. Do not stay here for longer than 4–6 weeks.

p=quarantine — spoofed emails go to spam on receiving servers. A significant improvement but not complete protection — some users check spam folders, some mail systems do not spam-classify reliably.

p=reject — spoofed emails are blocked outright. This is the target for any financial services firm. With p=reject, an attacker cannot send email claiming to be from your domain and have it delivered to a well-configured receiving server.

Challenges specific to financial services

Multiple sending sources: Most financial services firms send email from their primary mail provider (Microsoft 365 or Google Workspace) plus several third-party systems — CRM platforms, client portals, regulatory filing systems, marketing automation, DocuSign for e-signatures. Each must be included in SPF and configured with DKIM before DMARC can be moved to enforcement.

Legacy infrastructure: Older compliance platforms and document management systems often send email via SMTP without supporting modern authentication. These may require vendor updates or workarounds (dedicated sending domains or subdomains) before DMARC enforcement is feasible.

Client-facing subdomains: Client portal domains and dedicated communication subdomains need their own authentication records. A DMARC record on your primary domain with sp=reject covers subdomains — but only for domains where you are not sending legitimate mail. Subdomains that send client emails need their own SPF and DKIM configuration.

The deployment plan for regulated firms

1. Audit all email-sending services and subdomains
2. Configure DKIM on all services that support it
3. Publish a consolidated SPF record covering all legitimate senders
4. Publish a DMARC record at p=none with aggregate reporting
5. Review reports for 4–6 weeks; identify and address alignment failures
6. Move to p=quarantine with pct=25, then 50, then 100
7. Move to p=reject
8. Add sp=reject to cover all subdomains

Check your firm's email posture

VP Shield checks DMARC policy, SPF configuration, DKIM status, and email spoofing exposure for any domain in under two minutes — free, no login required. If your firm's primary domain currently has a p=none policy, clients and counterparties can receive emails appearing to come from your domain right now.