SPF, DKIM, and DMARC: The Email Setting Most Law Firms Get Half Right

If someone asked your IT provider right now "can anyone send an email that looks like it's from our own domain," most would say no, confidently, because SPF is configured. That confidence is usually misplaced.

SPF is one piece of a three-part system. On its own, it does very little to stop a determined attacker from spoofing your firm's domain. The piece that actually matters, the one that decides what happens when a message fails authentication, is the one almost nobody sets up properly. That gap is worth understanding, because for a law firm, it's a direct route to payment diversion fraud.

What SPF actually does, and where it stops

SPF, Sender Policy Framework, is a DNS record listing which mail servers are allowed to send email claiming to be from your domain. When another mail server receives a message, it checks that record to see if the sending server is on the approved list.

That's useful, but it has a real limitation: it breaks the moment a message gets forwarded. If a client forwards your email to a colleague, the forwarding server isn't on your SPF list, so the check can fail even though the message is entirely legitimate. Because of this, most receiving mail systems treat an SPF failure as a signal, not an automatic block. On its own, SPF tells a receiving server who's allowed to send as you. It doesn't tell them what to actually do if someone who isn't allowed tries anyway.

What DKIM adds

DKIM, DomainKeys Identified Mail, works differently. It attaches a cryptographic signature to outbound email, generated using a private key your mail system holds. The receiving server checks that signature against a public key published in your DNS. If the signature matches, the receiving server knows the message wasn't altered in transit and genuinely came from a system holding your private key.

DKIM is more reliable than SPF and survives forwarding better. But it has the same fundamental gap: it confirms authenticity, it doesn't decide what happens when a message fails the check. A receiving server that sees a failed DKIM signature still has to make its own judgement call about what to do next, and by default, that judgement often leans toward delivering the message anyway rather than risk blocking something legitimate.

DMARC is the policy that closes the gap, and it's the one firms skip

DMARC, Domain-based Message Authentication, Reporting and Conformance, sits on top of both. It does two things SPF and DKIM don't. First, it publishes a clear policy: when a message fails SPF and DKIM alignment, should it be delivered anyway, quarantined, or rejected outright. Second, it generates reports showing exactly which servers are sending mail using your domain, including any that shouldn't be.

Here's where most firms fall short. A domain can have a DMARC record and still offer almost no protection, because the policy is set to p=none, meaning "log failures, but deliver the mail regardless." This setting is often left in place from an initial setup, sometimes as a deliberate first step to avoid disrupting legitimate mail, and then never revisited. Years later, the record exists, a checklist gets ticked, and the domain is still functionally wide open to spoofing.

Moving from p=none to p=quarantine or p=reject is the step that actually changes anything. It requires confidence that all your legitimate mail sources, your M365 tenant, any marketing platform, any practice management system that sends email on your behalf, are correctly configured and passing authentication. That's exactly what the DMARC reports are for: they show you every source sending as your domain before you tighten the policy, so you're not accidentally blocking your own legitimate mail.

Why this matters more for a law firm than most businesses

A spoofed domain isn't just a nuisance for a firm handling client money. The most common real-world use of this gap is payment diversion fraud: a message that appears to come directly from a partner's own email address, sent to a client mid-transaction, requesting a change of bank details for a completion payment or invoice settlement. Because the domain matches exactly, not a lookalike, not a slightly misspelled variant, it clears the scrutiny that email security training usually teaches people to apply.

An enforced DMARC policy doesn't eliminate phishing entirely. Attackers can still register lookalike domains or compromise a genuine mailbox. But it closes off the specific, high-trust version of the attack: sending mail that is your exact domain, to people who have every reason to trust it.

What to actually check this week

Start by looking up your domain's current DMARC record, most DNS lookup tools can show this in seconds. If there isn't one, that's the first gap. If there is one, check the policy value. p=none means you have visibility but no enforcement. p=quarantine or p=reject means failing mail actually gets stopped or routed to spam.

If you're at p=none, don't jump straight to reject. Use the reporting period to confirm every legitimate source of outbound mail on your domain is correctly authenticated first, then move the policy up in stages. Rushing straight to reject without checking your own legitimate senders first is how firms end up with their own newsletter or invoicing system silently blocked.

If you're not sure what your current setup looks like, or whether it's safe to tighten, that's a quick, focused conversation, not a big engagement. Happy to take a look at your domain's current records and talk through what moving to an enforced policy would actually involve.