DMARC for UK Accountancy Firms

No. No accountancy body requires DMARC, SPF or DKIM. ICAEW and ACCA publish cyber security guidance that covers phishing and business email compromise, and it is worth reading, but it addresses those risks in general terms and names no email-authentication protocol as a requirement of membership.

HMRC "the standard for agents" sets expectations on data protection compliance and on keeping "online access credentials safe". That is about the security of your access to HMRC systems, not about the DNS records published for your practice domain.

Cyber Essentials does not close the gap either: the current requirements, v3.3 published April 2026 and effective 27 April 2026, cover firewalls, secure configuration, security update management, user access control and malware protection, with no DMARC control among them. The realistic driver for most practices is mailbox providers rather than regulators — Google has required a DMARC policy from bulk senders since 1 February 2024, and Microsoft has comparable requirements for high-volume senders.

No, and this is the distinction worth being careful about, because the word "authentication" is doing two completely different jobs.

HMRC is introducing mandatory multi-factor authentication for agent accounts from 10 June 2026. That protects your firm's sign-in to HMRC systems: a stolen agent password stops being sufficient on its own. It is a real control and worth preparing for.

Email domain authentication is a different thing entirely. DMARC, SPF and DKIM are DNS records published for your own domain that tell receiving mail servers how to treat a message claiming to come from you. An attacker forging your practice domain never touches your HMRC account, so no amount of login security there affects whether that message reaches a client.

Both belong on the plan. Neither substitutes for the other. How the standard for agents applies to your practice is a question for HMRC or your professional body — DMARC AI has no affiliation with either and nothing here is compliance advice.

It stops one of three attacks that arrive looking identical to the client, so it is worth naming all three.

Spoofed domain — covered. Somebody puts your exact practice domain in the From header of a message they sent. With an enforcing policy and your legitimate senders aligned, receiving servers reject or quarantine it before a client sees it.

Compromised mailbox — not covered. An attacker signed in to a genuine account sends genuine mail from your domain, which authenticates perfectly and passes every check. Multi-factor authentication on the mail tenant, conditional access and monitoring for forwarding rules are the controls that matter here.

Lookalike domain — not covered. Because .co.uk is a public suffix, the organisational domain for example.co.uk is that whole name, and a registration such as example-accountants.co.uk is a separate domain the attacker owns and configures. Nothing you publish reaches it.

The practical consequence: do not let a published record become the reason for relaxing a procedure. Confirming a bank detail change by phone, on a number the client already held, defeats all three.

Because the attacker's hardest problem is timing, and the accountancy calendar solves it for them in public. Every practice in the country is busy in the same few weeks, so a spoofed message does not need to guess when a client will be receptive.

In January clients expect chasing messages from their accountant, expect them to be urgent, and are already thinking about a payment. Around year-end and accounts approval, a flurry of documents, signature requests and fee notes is entirely normal traffic. Payroll dates recur monthly and make a request to change bank details look like routine administration.

None of that is a prediction about your practice. It is simply a reason to schedule DNS and enforcement changes away from those weeks, and to have monitoring already running before them rather than starting during them.

Less than a large estate, and the obstacle is rarely the mail platform. It is the sending systems a practice accumulates: practice management and tax software, the client portal, e-signature, payroll bureau mail, a newsletter tool, appointment reminders. Each sends as your domain, each needs its own DKIM key and verified sending domain, and most were switched on by a partner rather than by IT.

The sequence that works is to publish a monitoring policy with a working reporting address, let a full cycle of aggregate reports name the senders instead of assembling the list from memory, then fix alignment one platform at a time. Separately, lock down any domain that should never send mail — an old practice name, a payroll trading name, a defensive registration — since those need no inventory at all.

One change to be aware of: DMARCbis removed the percentage tag in RFC 9989, published May 2026. Each policy step applies to all of your mail or none of it, so there is no partial ramp to absorb a sender you missed. That makes the completeness of the inventory the whole job.

It is a sensible free first check and it is not a substitute for monitoring. Email Security Check is an on-demand lookup: it inspects your published anti-spoofing configuration and your transport security at the moment you run it. Running it costs nothing and is worth doing.

What it does not do is ingest DMARC aggregate reports, so it cannot tell you which sources are sending as your domain, whether your legitimate mail is authenticating, or whether anything changed since the last time somebody looked. That continuous view is exactly what left when the NCSC retired Mail Check and Web Check on 31 March 2026. DMARC AI has no affiliation with the NCSC and is not approved or endorsed by it.