DMARC for accountants & bookkeepers

If you run an accountancy or bookkeeping firm, your email address is one of the most trusted strings of text your clients ever read. When a message arrives from accounts@yourfirm.co.uk, nobody questions it. That trust is exactly what a fraudster wants to borrow. A criminal who can send mail that genuinely appears to come from your firm can redirect a client's payment, change a supplier's bank details, or request an urgent transfer, all wearing your name. This page explains why accountancy firms are a prime target, how the attack actually works, why a p=none DMARC record does nothing to stop it, and how enforced DMARC closes the door, safely and without any email outage.

Why accountants and bookkeepers are prime targets

Fraudsters do not pick targets at random. They go where money moves and where trust is high, and an accountancy practice sits at the intersection of both. Consider what your firm handles on an ordinary day:

• You instruct payments, or advise on them, for dozens or hundreds of clients.
• You hold bank details, payroll data, VAT numbers, and personal financial records.
• Your clients are conditioned to act on your emails quickly, because deadlines (payroll runs, VAT returns, year-end) are real and unforgiving.
• You correspond regularly with HMRC, banks, and suppliers on your clients' behalf, so a message about a payment or a detail change looks entirely routine.

That combination is rare and valuable to an attacker. One convincing email sent in your firm's name can move a five or six figure sum, and it does not require breaking into anything. It only requires that your domain can be spoofed. For most firms, today, it can.

The specific attack, step by step

This is not a sophisticated technical exploit. It is patient, human, and cheap, which is precisely why it persists. A typical sequence against a bookkeeping firm runs like this:

1. The attacker researches your firm from your website, LinkedIn, and any leaked email lists. They learn your firm's name, who runs the accounts, and ideally the names of a few clients or suppliers.
2. They craft a message that appears to come from your exact domain. Two common framings: the firm writes to a client saying "our remittance details have changed, please use the new account for this month's payment", or the firm writes to a client's finance contact requesting an urgent transfer before a deadline.
3. Because the From address is genuinely accounts@yourfirm.co.uk, the logo and signature are right, and the request fits the rhythm of normal correspondence, it clears the human filter. A thin layer of urgency discourages the recipient from picking up the phone.
4. The money goes to an account the attacker controls. By the time anyone reconciles, it has moved through several accounts and is gone.

The damage runs in both directions. A fraudster can spoof your firm to bill or redirect your clients, or spoof one of your clients to instruct you. The bank-detail-change message is the most common and most expensive variant: a single forged email saying "we've switched banks, here are the new details" can reroute every future payment until someone notices.

Why p=none does not stop any of this

Many firms believe they are covered because they "have DMARC". The question that matters is not whether you publish a DMARC record, but what policy it enforces. There are three policy values, and only two of them block anything:

• p=none tells receiving mail servers to take no action and just send you reports. It blocks nothing. A spoofed invoice under p=none is delivered exactly as if you had no DMARC at all.
• p=quarantine tells receivers to divert failing mail to the spam folder.
• p=reject tells receivers to refuse failing mail outright, before it reaches the inbox.

The overwhelming majority of domains that publish DMARC are sitting at p=none. It feels safe, it reports nicely, and it stops precisely nothing. A firm at p=none is watching its own impersonation in slow motion: the reports will tell you a forged invoice went out in your name, but only after your client has already received it. To actually stop the forgery at the recipient's mail server, the policy has to reach p=quarantine or p=reject. We cover the full mechanics of this on our invoice and CEO fraud page.

How enforced DMARC stops the exact-domain attack

DMARC works by combining three checks, performed at the recipient's mail server before a human ever sees the message:

• SPF checks whether the sending server appears on a list your domain publishes.
• DKIM attaches a cryptographic signature, verified against a public key at selector._domainkey.yourfirm.co.uk, proving the message was authorised by your domain and not altered in transit.
• Alignment is the part that defeats spoofing. DMARC requires that the domain which passed SPF or DKIM matches the domain shown in the visible From address. An attacker can make their own server pass SPF for their own domain, but they cannot make it align with yourfirm.co.uk, because they do not hold your DKIM private key and your domain has not authorised their server.

Once your domain publishes v=DMARC1; p=reject; rua=mailto:reports@yourfirm.co.uk, a forged message claiming to be from your firm fails alignment and is refused by Gmail, Yahoo, Outlook and every other receiver that honours DMARC. The fake bank-detail-change email from accounts@yourfirm.co.uk never lands in your client's inbox. That is the entire mechanism, and at enforcement it runs automatically, on the recipient's side, for every message claiming to be you.

Reaching enforcement without an email outage

The fear that keeps firms stuck at p=none is the worry that tightening the policy will block their own legitimate mail: the payroll provider, the practice management tool, the e-signature platform, the newsletter. It is a fair fear, and it is exactly the problem our process is built to avoid. We never make a blind jump to p=reject. Instead we move in monitored stages:

Because your legitimate mail passes authentication at every stage, tightening the policy is invisible to your clients and your own staff. The only people who notice are the criminals forging your domain, and what they notice is that it stopped working. The whole journey, and why each step is reversible with a single DNS edit, is laid out on our guide to reaching enforcement. If you want to know what we find before we start, the audit shows your current policy and every sender we can see.

The compliance, insurance and due-diligence angle

Beyond stopping fraud, authenticated email is increasingly something your firm is expected to have, and sometimes required to have. The pressure is coming from several directions at once:

• Bulk-sender rules. Google and Yahoo's requirements, in force since 1 February 2024, and Microsoft's equivalent tightening for high-volume senders to Outlook.com, Hotmail and Live, all assume genuine authentication. Firms that send client statements or reminders at volume cannot afford to be on the wrong side of these.
• PCI DSS 4.0. Requirement 5.4.1 made anti-phishing controls mandatory from 31 March 2025. If your firm touches card data or advises clients who do, a monitor-only record does not meet the spirit of it.
• Cyber-insurance. Insurers increasingly ask whether you enforce email authentication. A truthful "yes, at p=reject" is a better answer at renewal than "we publish DMARC but it does nothing".
• Client due diligence. Larger clients run security reviews of their suppliers. An accountant who can demonstrate enforced DMARC, hosted SPF, DKIM and MTA-STS clears that question without a fuss.

The fuller picture of what assessors and insurers look for is on our compliance and cyber-insurance page. The short version: enforced DMARC has moved from a nice-to-have to a baseline expectation, and being able to evidence it is becoming part of winning and keeping work.

If a fraudster can send mail that genuinely appears to come from your firm, and your domain does nothing to stop it, you are handing the attacker your own credibility, the very thing your clients pay you for, free of charge.

What we set up and host for you

This is a done-for-you service, not a dashboard you have to learn. We take your domain from wherever it is today through to enforced p=reject, and we host the underlying records so they stay correct: DMARC, SPF, DKIM, MTA-STS and BIMI. We ingest your aggregate (RUA) reports so the monitoring is continuous rather than a one-off check, and we hold your policy at each stage only until the reports say it is safe to advance. You can see exactly what is included on the products page, and the common questions are answered on the FAQ.

The commercial side is deliberately simple: a flat one-time enforcement fee, currently an introductory £200 (normally £500), plus monitoring at £19/month (normally £39). One fee to get you to enforcement, a small monthly fee to keep you there and watch the reports.

Where to start

Begin by finding out whether your firm's domain can be spoofed right now. Our free tools check whether you publish DMARC, whether it is at p=none or actually enforcing, and whether your SPF and DKIM align. If your record reads p=none, or you have no record at all, a forged invoice or bank-detail-change email from your firm will reach a client's inbox today. From there, the requirements page shows what we need from you, which is usually very little, and the path to enforcement shows how we get you to p=reject without catching your own mail.

When you are ready, you can sign up here. Invoice and payment-redirection fraud succeeds because it abuses trust your firm has spent years building. Enforced DMARC takes your own domain off the table as a weapon against your clients, automatically and at the inbox. It does not solve every form of fraud, but it shuts the cheapest and most damaging door, and for an accountancy practice that door is the one criminals reach for first.