Resources2026-08-26By Securing Your Law Firm

DMARC for Law Firms: Check Your Email Domain Protection

Learn how law firms should verify SPF, DKIM, and DMARC, stage enforcement safely, and request evidence about direct email spoofing risk.

Check public email exposure Review email and Microsoft 365 security

Could Someone Send Email That Appears to Come From Your Firm?

Blog post - By Securing Your Law Firm

Imagine a client receives an email that appears to come from the firm and changes payment instructions. This is an illustrative scenario, not a claim about a particular firm.

The first leadership question is not “Do we have a DMARC record?” It is “What evidence shows that our domain is configured to make direct spoofing harder without disrupting legitimate mail?”

SPF, DKIM, and DMARC in plain English

SPF lists the services allowed to send mail for your domain. It is useful only when the list is accurate and stays within SPF’s technical limits.

DKIM adds a cryptographic signature to outgoing messages. A receiving system can use it to check that an authorized service signed the message and that the signed content was not changed.

DMARC tells receiving systems how to handle messages that fail SPF or DKIM alignment and can send aggregate reports about mail using the domain. A record’s presence does not prove that it is aligned, monitored, or enforced.

These controls work together. A firm can publish all three and still have weak protection if a sender is missing, DKIM is not signing the right domain, reports are ignored, or the policy remains at `p=none`.

Monitoring is not enforcement

Monitoring mode (`p=none`) provides visibility but does not ask receivers to quarantine or reject failing messages. Quarantine and rejection are enforcement choices, not badges of maturity.

Do not switch every domain to rejection immediately. First identify legitimate senders, such as billing systems, case-management notifications, e-signature platforms, client portals, and marketing tools. Confirm whether each service sends as the firm’s domain or uses its own authenticated domain. Then fix alignment and review reports before tightening policy in stages.

A practical sender example

A firm may use Microsoft 365 plus a billing or e-signature service that sends using the firm’s domain. Before tightening DMARC, confirm which services actually use that domain and validate alignment with representative message headers and aggregate reports. Do not assume every platform sends as the firm’s domain, or that every legitimate sender must pass both SPF and DKIM for DMARC to pass.

Owner checklist

Identify legitimate sending services and domains.
Confirm SPF, DKIM, and DMARC authentication and alignment.
Review aggregate reporting and assign someone to act on failures.
Stage enforcement with delivery checks before tightening the policy.
Record ongoing ownership and the next review date.

What DMARC does not solve

DMARC helps with direct domain spoofing: a message that claims to be from `yourfirm.com` but fails the domain’s authentication policy.

It does not stop:

A lookalike domain, such as a substituted letter or extra word.
A compromised legitimate account that sends a real authenticated message.
Display-name tricks, fake reply addresses, malicious attachments, or every form of business-email compromise.

Those risks need separate public exposure checks, mailbox and tenant review, staff readiness, and a payment-verification process.

DMARC protects the firm’s email domain from direct spoofing. It does not verify whether a user’s account is protected at sign-in; for that separate question, see how to verify MFA enforcement and account coverage.

Evidence to request

Item to check	Why it matters	Evidence to request	Visibility
SPF record and authorized senders	Old or missing senders create delivery and spoofing gaps	Current DNS record and sender inventory	Publicly observable, with authorized validation
DKIM selectors and signing	A published selector does not prove messages are signed	Test message headers and provider configuration	Requires authorized testing
DMARC policy and alignment	`p=none` reports but does not enforce	DNS record, aggregate-report destination, and sample reports	Policy is public; reports require access
Legitimate sending services	Billing, case systems, e-signature, and marketing tools may send differently	Written list of services and sending domains	Requires firm/MSP knowledge
Mail-flow changes	Provider changes can make a previously safe policy disruptive	Change history and post-change delivery tests	Requires authorized access/testing
Lookalike and display-name exposure	DMARC does not cover nearby domains or names	Domain findings and sample impersonation scenarios	Public review plus authorized validation

The practical question for each sender is: “Does this service send using our domain, and can we prove its SPF or DKIM alignment?” A vendor’s claim that it “supports DMARC” is not evidence for your specific domain.

A staged verification process

Inventory the firm’s real sending services and domains.
Check SPF syntax, authorized senders, DKIM signing, and DMARC alignment.
Publish or maintain monitoring and review aggregate reports.
Correct legitimate senders and test representative messages.
Move to quarantine or rejection only when the firm can explain the remaining failures.
Record the final policy, evidence, owner, and review date.

Findings need validation when DNS records, vendor routing, or tenant settings disagree. Staging protects legitimate correspondence while turning an assumed control into a defensible one.

We check this for law firms

Our Email & Microsoft 365 Security for Law Firms service can coordinate domain authentication work with an existing MSP or internal administrator. The scope distinguishes:

The Free Zero-Access Exposure Review™, which checks public DNS and other outside-in signals. It does not inspect private mailbox forwarding rules or prove that a Microsoft 365 tenant is secure.
An authorized assessment, which can examine agreed email or mailbox evidence within the firm’s scope.
Scoped implementation, which changes SPF, DKIM, and DMARC for the agreed domain and sending services. It is not a promise to harden every Microsoft 365 setting.

If the firm needs the assessment and one eligible domain implemented together, the catalog’s Baseline + Email Domain Protection bundle is the relevant destination. The Baseline itself is assessment-only; additional remediation is separately scoped.

What should you do next?

If you need a public starting point, request the Free Zero-Access Exposure Review™. If a client, insurer, or leadership team needs evidence about mail controls, discuss the authorized service and the exact domain scope.

Do not ask a marketing form to receive tenant credentials, client files, or confidential evidence. Share only the scope and question first; access and evidence requirements should be agreed before work begins.