DMARC for UK Financial Services Firms

No. DMARC is not named anywhere in the FCA Handbook, and it is not named in PS21/3 either. We checked the primary material directly — SYSC 6, SYSC 8, SYSC 15A and the operational resilience policy documents — rather than relying on a summary, and the term does not appear.

SPF and DKIM are absent in the same way. No FCA rule obliges a firm to publish any email-authentication record.

We put that on the page because financial services is the sector where "the regulator requires this" is most often used to shorten a sales cycle. Any vendor telling you the FCA mandates DMARC is wrong, and it takes about five minutes in the Handbook to confirm it.

PS21/3 "Building operational resilience" brought rules into force from 31 March 2022, with the transition period ending on 31 March 2025. It is built around identifying important business services, setting impact tolerances and testing the firm's ability to remain within them, including under cyber-attack scenarios.

What it is not is control-prescriptive. It describes outcomes and leaves the method to the firm. It does not mandate specific technical controls, and it names no email-authentication protocol.

Whether email authentication is relevant to a particular firm's important business services is a judgement for that firm. We are not going to make it for you, and we would be suspicious of a supplier who offered to. DMARC AI has no affiliation with the FCA and nothing here is regulatory or compliance advice.

Because the regime is principles-based rather than empty. SYSC 6 and SYSC 8 are written in the language of adequate policies, systems and controls appropriate to the nature and scale of the business — an outcome, with the method left to the firm. That moves the work from satisfying a list to making and being able to justify a judgement.

DMARC is one control a firm may choose in that context, and one it can evidence with dated, continuous records rather than an assertion. It is not an FCA requirement and should never be recorded as one.

There is also a plainer commercial reason. Institutional clients, custodians, platforms and insurers ask about email authentication in due-diligence questionnaires constantly, and that request usually arrives with a deadline attached long before any regulatory conversation does.

It covers exactly one of three attacks that look identical to the recipient, and the distinction matters because it determines what you can honestly write in a control register.

In scope: forgery of your exact domain. An attacker puts your real domain in the From header of a message sent from their own infrastructure. With an enforcing policy published and every legitimate sender aligned, receiving providers reject or quarantine it before delivery.

Out of scope: account compromise. Mail sent from a real account using a stolen credential is genuinely from your domain and authenticates cleanly. That is an identity and access problem — multi-factor authentication, conditional access, session monitoring, detection of new mailbox rules.

Also out of scope: a domain the attacker registered. Because .co.uk is a public suffix, the organisational domain for example.co.uk is that whole name, and a lookalike such as example-wealth.co.uk is a wholly separate domain under their control. Your policy has no reach into it.

So "prevents unauthorised use of the firm's domains in the From header of email, at enforcement" is defensible wording. "Prevents email impersonation of the firm" is not.

The domain count is usually small and the sender count usually is not. That asymmetry is the defining feature of a financial services rollout.

Expect statement and document providers, platforms, custodians, administrators and print-and-post bureaux; marketing and research distribution, often run by an agency; and the operational tail of CRM, e-signature, client portals, complaints handling, HR and recruitment tools. Under SYSC 8 third-party arrangements have to be managed appropriately, and each provider sending as your domain is a separate alignment question rather than one supplier decision.

Publish a monitoring policy with a working reporting address first and let a full cycle of aggregate reports build the list, because one assembled from memory is always incomplete. Then move to p=quarantine and p=reject. DMARCbis removed the percentage tag in RFC 9989, published May 2026, so each step applies to all of your mail or none of it — there is no partial ramp left to absorb a missed sender, and in this sector the visible consequence is a client statement that does not arrive.

Cyber Essentials does not. Its current requirements — v3.3, April 2026, effective from 27 April 2026, administered by IASME — cover firewalls, secure configuration, security update management, user access control and malware protection. There is no DMARC, SPF or DKIM control among the five, so a certificate does not answer the question.

Other assurance schemes vary and we cannot speak for the one your firm holds. The safest approach is to check the control list rather than assume email authentication sits inside a scope statement written for something else.

With something continuous rather than a screenshot. A DNS lookup captured on one afternoon proves a record existed at that moment and says nothing about the twelve months either side, which is normally the period of interest.

A durable record covers every domain the firm holds with its policy position and the date it reached it; the sender inventory with each third party classified and an owner named; authentication pass rates over time; a change history showing what moved, when and who approved it; and a written scope statement that names the two attacks the control does not address.

That last item is the one most often left out, and it is the one that makes the rest credible. Where the question is what your firm is actually obliged to demonstrate, that belongs with your compliance function or your own advisers rather than with us.