Email authentication for law firms

7 May 2026 · 11 min read

A law firm's domain is one of its most sensitive assets, and email is the channel where most of the damage gets done. The single most expensive fraud a firm faces is not a data breach in the abstract: it is a buyer wiring completion funds to a criminal who impersonated the firm by email, or a partner's name being used to move money or extract confidential documents from a client. Email authentication, meaning SPF, DKIM and DMARC working together, is the control that decides whether an attacker can put your exact domain in the From line of a message that lands in a client's inbox looking genuine.

This guide is written for the realities of legal practice: solicitor-client confidentiality and privilege, the wire-fraud exposure that peaks at completion or closing, e-billing and document portals that send on your behalf, and the regulatory and insurance pressure that follows a successful impersonation. It is not a generic DMARC explainer. If you want the underlying theory first, the glossary and what is DMARC cover the basics, but everything below is about applying authentication to a firm.

Why law firms are a priority target

Conveyancing and corporate completions create a perfect storm for fraud: large sums, a fixed deadline, multiple parties who do not all know each other, and a moment where new bank details are legitimately exchanged. A criminal who can convincingly impersonate the firm, the other side's solicitor, or the client, only needs to insert one set of fraudulent account details at the right moment. The classic attack is payment redirection: an email that appears to come from partner@yourfirm.co.uk tells the buyer that the firm's client account details have changed, and the funds go to a mule account. By the time anyone notices, the money has been layered away.

This is a form of business email compromise (see /glossary/bec), and it does not require breaking into your mailbox. Two cheaper routes exist:

• Exact-domain spoofing. The attacker forges your real domain in the From header. With no DMARC enforcement, many receiving servers will deliver it. This is the route DMARC exists to close.
• Lookalike domains. The attacker registers yourfirm-legal.co.uk or yourfilm.co.uk (a transposed letter) and sends from that. DMARC on your real domain does not stop a different domain, but it does push attackers towards these noisier lookalikes, which are easier for recipients and filters to spot. See /glossary/lookalike-domain and our piece on typosquatting in email.

The professional duty angle sharpens all of this. A solicitor owes a duty of confidentiality to the client, and firms are expected to take reasonable steps to protect client information and client money. If your domain can be trivially spoofed and a client loses their deposit as a result, the firm's failure to deploy a standard, free, well-documented control is a difficult position to defend to the client, to the regulator and to your professional indemnity insurer.

The three records, in legal-practice terms

Email authentication rests on three DNS records. They answer different questions, and a firm needs all three aligned to be protected.

• SPF lists which mail servers are allowed to send for your domain. It authenticates the envelope sender (the return-path), not the address your client actually sees. See /glossary/return-path.
• DKIM attaches a cryptographic signature to each message, tied to your domain via a public key in DNS. If the body or key headers are tampered with, the signature breaks. See DKIM explained.
• DMARC ties the two together and adds the part that matters: alignment. It checks that the domain authenticated by SPF or DKIM matches the domain in the visible From header, and it tells receivers what to do when neither aligns. See DMARC alignment explained and /glossary/dmarc-alignment.

The crucial point for a firm: SPF and DKIM can both pass while the message is still a forgery of your domain, because they can authenticate the attacker's own infrastructure. Only DMARC's alignment requirement, set to enforce, stops a message that puts yourfirm.co.uk in the From line without authority. A policy of p=none collects data but blocks nothing. Treating p=none as protection is a common and dangerous mistake; we cover why in the false security of p=none.

You can see exactly where your domain stands right now with the DMARC checker, the SPF checker and the DKIM checker. Run all three before changing anything so you have a baseline of what is currently passing and aligning.

Map your sending sources first: law firms are messier than they look

The reason firms get this wrong is rarely the DNS syntax. It is that legal practices send mail from far more places than partners realise, and switching on enforcement before you have authorised them all will silently bin legitimate, often client-critical, mail.

A typical firm sends from some combination of:

• The primary mailbox platform: Microsoft 365 or Google Workspace for day-to-day solicitor and staff email. See DMARC for Microsoft 365 and DMARC for Google Workspace.
• A practice/case management system (for example Clio, LEAP, Actionstep, SOS, Osprey, Proclaim) that sends correspondence, attendance notes and updates on your behalf, often from @yourfirm.co.uk.
• E-billing and accounts software that emails invoices and statements to clients.
• A document and client portal that sends secure-message notifications and signing requests.
• An e-signature provider (DocuSign, Adobe Acrobat Sign) for engagement letters and contracts.
• Marketing or client-update tools for newsletters and legal alerts.
• Scan-to-email and dictation/transcription systems from the office multifunction devices.

Each of these is a sending source that must either send through your authenticated mail platform or be individually authorised in SPF and signed with DKIM. The fastest way to discover the full list is not to ask around the office: it is to publish a DMARC record in monitoring mode and read the aggregate reports, which show every IP and service trying to send as your domain. See reading your first DMARC report and /glossary/aggregate-report-rua.

Building the records for a firm

SPF

Your SPF record lists the platforms allowed to send. A firm on Microsoft 365 that also bills through one provider and sends signing requests through another might publish:

v=spf1 include:spf.protection.outlook.com include:_spf.billingvendor.com include:spf.docusign.net -all

Two SPF traps bite firms specifically:

• The ten-lookup limit. SPF allows a maximum of ten DNS lookups; each include for a case management system, billing tool and e-signature provider eats into that budget. Exceed it and SPF returns permerror, which fails alignment for every message. Firms accumulate vendors over years and quietly blow the limit. Check it with the SPF checker and read /glossary/spf-10-lookup-limit. Flattening keeps you under the cap; see /glossary/spf-flattening.
• A soft ~all instead of -all. A soft fail is permissive. Once your senders are confirmed, end the record with -all.

DKIM

Enable DKIM on every platform that supports it, which is essentially all of the mainstream ones. DKIM is what survives forwarding, and law firms forward email constantly: counsel's chambers, the other side, a client's accountant, an assistant's rule. SPF breaks on forwarding because the forwarding server becomes the new envelope sender; a valid DKIM signature travels with the message and keeps DMARC aligned. This is precisely why DKIM matters more than SPF for a firm. See why DKIM fails after forwarding.

Each platform publishes DKIM as one or more CNAME or TXT records using a selector. Confirm signatures are present and verifying with the DKIM checker, and rotate keys periodically (see /glossary/dkim-key-rotation).

DMARC

Start in monitoring mode so you see traffic without affecting delivery. Point the reports at an address or service that will actually parse them:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourfirm.co.uk; fo=1;

You can generate a correct record with the DMARC generator, and decode what each tag means in understanding your DMARC record. The goal of this phase is not protection; it is a complete, evidence-based inventory of who sends as your domain.

The staged path to p=reject without breaking client mail

This is the part that protects the firm. Enforcement means a DMARC policy of quarantine or reject, so that a forged message either goes to junk or is bounced outright. Getting there safely is a sequence, not a switch.

1. Monitor (p=none). Publish the record above and collect aggregate reports for two to four weeks. Long enough to capture month-end billing runs and any quarterly client mailings.
2. Authenticate every legitimate source. Work through the report. For each genuine service, add the SPF include and switch on DKIM until SPF or DKIM aligns. The DMARC report analyzer turns the raw XML into a readable list of sources and their alignment status.
3. Move to p=quarantine, optionally ramped. Once legitimate mail aligns, set p=quarantine. You can roll it out gradually with the percentage tag, for example pct=25, then 50, then 100:

   v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourfirm.co.uk; fo=1;
   

1. Move to p=reject. When quarantine has run clean, set p=reject. Now a message forging your domain is refused at the recipient's server, which is the outcome that actually defends a completion.

   v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourfirm.co.uk; fo=1;
   

The detailed mechanics, including how long to spend at each stage, are in the enforcement journey and how to reach p=reject without breaking email. The discipline is simple: never advance a stage while a legitimate source is still failing alignment, because at reject that source's mail disappears.

Do not forget the subdomain policy and the apex

Two gaps that catch firms specifically.

First, attackers love to spoof subdomains like billing.yourfirm.co.uk or secure.yourfirm.co.uk because they look plausible to a client. Your DMARC record's sp tag sets the policy for subdomains; if you omit it, subdomains inherit p. Set it explicitly to reject once you are confident. See the subdomain policy (sp) tag and /glossary/subdomain-policy-sp.

Second, the parked or non-sending domains. Many firms own several domains: the trading name, a former name after a merger, regional variants, and short redirect domains. Any domain that can receive an MX lookup can be spoofed even if you never send from it. Publish a strict, send-nothing policy on each one:

v=spf1 -all

v=DMARC1; p=reject;

A domain that sends no mail should advertise that it sends no mail. Leaving old or parked firm domains unprotected is one of the most common holes we find.

Confidentiality, privilege and what authentication does and does not do

Be precise with partners about scope, because authentication is sometimes oversold internally.

What SPF, DKIM and DMARC do:

• Stop third parties from sending mail that forges your exact domain in the From header, once you are at enforcement.
• Make tampering with a message in transit detectable, because DKIM signs the content.
• Give you reporting that reveals impersonation attempts and shadow IT sending as your domain.

What they do not do:

• They are not encryption. DKIM signs, it does not conceal. The body of a normal email is not protected from interception by SPF, DKIM or DMARC. Transport-layer encryption is a separate control: enforce TLS between mail servers with MTA-STS, so that messages to and from your domain are not delivered over an unencrypted or downgraded connection that a network attacker could read. See MTA-STS explained, the MTA-STS checker and /glossary/mta-sts. Pair it with TLS-RPT to get reports when a connection cannot be secured (see /glossary/tls-rpt). For genuinely privileged material, a secure client portal or message-level encryption remains the right tool; authentication complements it, it does not replace it.
• They do not stop lookalike-domain fraud on a different domain, and they do not stop display-name spoofing, where the attacker's mailbox shows "Jane Partner, Senior Solicitor" as the friendly name while the underlying address is a free webmail account. Enforcement on your domain pushes attackers towards exactly these noisier methods, which is a win, but staff awareness still matters. See /glossary/display-name-spoofing.

For a fuller picture of how these attacks play out against firms, the deep dives on vendor email compromise, executive impersonation and thread hijacking are directly relevant to conveyancing and litigation correspondence.

BIMI: the partner-friendly upside

There is a positive client-facing reason to finish the journey, not only a defensive one. Once your domain is at p=quarantine or p=reject, you can publish BIMI, which displays your firm's verified logo next to authenticated messages in supporting inboxes. For a firm, that is a recognisable, harder-to-fake trust signal in the client's mailbox, and it is only available to domains that have already reached enforcement. It is genuinely a reward for doing the authentication work properly. See do you need BIMI, the BIMI checker and /glossary/bimi. The strongest form uses a Verified Mark Certificate tied to a registered trade mark, which suits established firm branding.

Monitoring: this is not a set-and-forget control

A firm's sending estate changes: a new case management system is procured, the marketing team trials a newsletter tool, a department starts using a different e-signature provider, a DKIM key expires. Any of these can quietly break alignment and start sending legitimate client mail to junk, or open a gap an attacker can use. Reaching p=reject is the start of the maintenance phase, not the end of the project.

Continuous monitoring with alerting on changes catches a new unauthorised sender, a record that gets edited or deleted, or a key that stops verifying, before a client phones to ask why your invoice went to their spam folder. Our monitoring service watches your DMARC, SPF, DKIM, MTA-STS and BIMI records and emails you when something changes; see monitoring and change alerts. For a firm, the audit trail this produces is also useful evidence that the control is operating, which is exactly what an insurer or regulator will want to see after an incident.

A practical sequence for a firm starting today

1. Run your domain through the DMARC checker, SPF checker and DKIM checker and record the baseline.
2. List every domain the firm owns, including parked, former-name and redirect domains.
3. Publish p=none with reporting on the live domain, and the send-nothing policy on every parked domain.
4. Collect aggregate reports for a few weeks; use the report analyzer to build the complete sender inventory.
5. Authenticate each legitimate source with SPF and DKIM until it aligns.
6. Ramp through p=quarantine to p=reject, setting sp=reject for subdomains.
7. Add MTA-STS for transport encryption and BIMI for the verified logo.
8. Turn on continuous monitoring so the configuration cannot silently drift.

The practical takeaway

For a law firm, email authentication is not an IT housekeeping task: it is a client-money and confidentiality control that directly reduces the risk of a completion being redirected and your name being used to defraud the people who trust you. The work is bounded and well understood. Map your senders, get every legitimate one aligned, climb steadily to p=reject, protect your parked domains, then add MTA-STS and BIMI and keep watching for drift.

Start by seeing exactly how spoofable your domain is today with the DMARC checker. If you would rather not run the staged migration yourself, our managed DMARC service takes a firm's domain from p=none to p=reject without an email outage and monitors it afterwards, which for a busy practice is usually the safer and cheaper option than learning the failure modes on live client mail.