DMARC for law firms

DMARC for law firms: make forged email from your own domain fail

By Adam W., founder of DMARCit · Last updated 2026-10

The email that costs a firm a client is rarely clever. It shows the partner's real address, names the right matter, and says the account details for the retainer or the settlement have changed. If your domain publishes no enforced DMARC policy, the client's mail server has no instruction from you to refuse it.

With p=reject, a forgery of your exact domain fails at the receiving server instead of landing next to the real thread. Getting there is mostly a matter of finding the billing, e-signature and portal services that already send as the firm, before you enforce. The ABA never names DMARC; the section on its opinions below quotes what they do ask.

Check your domain free Several domains? Check them together

The email that moves a client's money

Here is the version worth planning for. A client is about to wire a retainer or expects settlement funds. An email arrives from the attorney's address with “updated” instructions, often written to look like a reply in the existing thread. If it was sent on the firm's exact domain and the firm publishes p=none or no DMARC record at all, nothing in the receiving server's rules says to stop it.

Business email compromise drew 24,768 complaints to the FBI's Internet Crime Complaint Center in 2025, with $3,046,598,558 in reported losses [IC3 2025, pp. 7 to 8]. That figure spans every industry. It is not a law-firm number, and I won't pretend to know the law-firm share.

DMARC covers one slice of the problem: mail that uses your exact domain. It is the slice you control with a DNS record, and the hardest one for a client to catch, since nothing in the header looks wrong.

What the ABA asks for, and what it doesn't

No ABA opinion requires DMARC. Formal Opinion 477R (May 2017) doesn't mention SPF, DKIM or DMARC at all. What it says is that a lawyer generally may transmit client information over the internet where the lawyer has undertaken reasonable efforts to prevent inadvertent or unauthorized access [ABA 477R]. It ties that to Model Rule 1.6(c) and treats reasonable efforts as a judgment built on factors: how sensitive the information is, how likely disclosure is without more safeguards, what those safeguards cost, how hard they are to implement, and how much they get in the way of representing clients [ABA 477R].

Two of its practical steps map onto email authentication without naming it: understand how client confidential information is transmitted, and conduct due diligence on the providers of your communication technology [ABA 477R]. For email, a DMARC aggregate report is the most direct answer I know to the first one. It lists every server that sent mail claiming to be your firm, including the ones you didn't know about.

Formal Opinion 483 (October 2018) covers what happens after a breach. It says lawyers must employ reasonable efforts to monitor the technology and office resources connected to the internet, and it sets out a duty to notify current clients when a breach involves, or is substantially likely to involve, material client confidential information [ABA 483]. It doesn't mention email authentication either. Whether a given forged email triggers anything under 483 is a question for your ethics counsel, not for a DNS record.

ABA formal opinions are advisory. What binds you is your state's version of Rule 1.6 and its ethics opinions.

How DMARC decides what happens to a forgery

Every email carries two sender addresses: the From line your client reads, and an envelope address servers use for bounces. SPF lets a domain list the servers allowed to use it in the envelope (the MAIL FROM and HELO identities) and says nothing about the From line [RFC 7208, §1]. DKIM signs the message with a domain's key. DMARC ties both to what the reader sees: a message passes when SPF or DKIM passes for a domain that aligns with the From domain [RFC 9989, §3.2.10] [Microsoft DMARC guide].

The policy you publish at _dmarc.yourfirm.com tells receivers what to do with mail that fails. p=none expresses no preference. p=quarantine says failing mail is suspicious, which at most receivers means the spam or junk folder. p=reject says a failure is a clear sign the use of your domain isn't valid [RFC 9989, §4.7] [Microsoft DMARC guide]. Only the last two change what happens to a forgery. A record stuck at p=none gets you reports and nothing else.

Three details catch small offices. Microsoft's own documentation says no DKIM signing occurs for outbound mail from custom domains until you configure it [Microsoft DKIM guide], so a Microsoft 365 tenant that never turned it on is relying on SPF alone, and SPF alignment breaks when mail is forwarded [Microsoft DMARC guide]. SPF allows at most ten DNS-querying terms, and every service added with an include: spends some of that budget [RFC 7208, §4.6.4]. And ~all at the end of an SPF record is a softfail, which receivers should not reject on by itself [RFC 7208, §8.5]. It was never the enforcement step. DMARC is.

What sends email as your firm

Before any policy change, list everything that puts your domain in a From line. At a law firm the list is usually longer than the managing partner expects:

  • Microsoft 365 or Google Workspace. The attorneys' and staff mailboxes. On Microsoft 365, custom-domain DKIM signing is off until someone configures it [Microsoft DKIM guide], so check it before you read the first report.
  • Practice management and billing. Invoices, statements and payment receipts sent from the platform with your address in the From line.
  • E-signature requests. Engagement letters and settlement documents sent for signature, usually from the provider's servers on your behalf.
  • Client portal notices. "A new document is available" messages, which are exactly what a phishing email imitates.
  • Scanners and copiers. Signed documents scanned to email at the copier, usually relayed through an SMTP service with the firm's domain in the From line. Nobody notices these until a scan bounces.
  • Website forms and the firm newsletter. Contact-form notifications and client alerts, each through its own sending service.

Each one has to pass SPF or DKIM for your domain, aligned, before you enforce. The ones that don't are not attacks. They are the reason the rollout starts in monitoring mode.

What Gmail, Yahoo and Microsoft check now

Since February 1, 2024, Google has required every sender to Gmail to set up SPF or DKIM, and senders of more than 5,000 messages a day to also publish DMARC (a policy of none is enough) with the From domain aligned [Google sender guidelines]. Yahoo asks all senders for SPF or DKIM, and bulk senders for both, plus a passing DMARC policy of at least p=none and an aligned From domain [Yahoo sender best practices]. Yahoo won't say what volume makes you a bulk sender [Yahoo sender FAQ]. Microsoft rejects mail with 550 5.7.515 when a domain that has sent 5,000 or more messages to Outlook.com, Hotmail and Live.com doesn't pass both SPF and DKIM, publish a DMARC record, and align at least one of them [Microsoft 550 5.7.515].

A small firm's own mailboxes rarely get near those numbers, and none of these is a regulation. They matter for two narrower reasons. The receivers holding your clients' inboxes now check authentication on everyone. And Microsoft counts volume by the From domain [Microsoft 550 5.7.515], so a newsletter or billing platform sending as you adds to your count, not its own.

Getting to p=reject without losing real mail

Microsoft's guidance for its own customers is the right shape for any firm: start at p=none, monitor, step up to p=quarantine, then p=reject, and begin with a low-volume domain if you have one [Microsoft DMARC guide].

  1. Publish p=none with a reporting address. Delivery doesn't change. Receivers start sending aggregate reports, typically once a day [Microsoft DMARC guide].
  2. Read two to four weeks of reports. Every source sending as yourfirm.com shows up with its SPF and DKIM results. Mark the ones that are yours. Anything you don't recognize is either a forgotten tool or someone else.
  3. Fix alignment one sender at a time. For each service, turn on its custom-domain DKIM setting (it gives you a DNS record to publish) or an aligned return-path, then check the next day's reports.
  4. Move to p=quarantine. Failing mail goes to spam instead of the inbox. Watch for a legitimate sender you missed.
  5. Move to p=reject once every legitimate source aligns. A forgery of your exact domain now fails at receivers that enforce DMARC.

Domains you own but never send from get v=DMARC1; p=reject; [Microsoft DMARC guide] and an SPF record that authorizes nothing, v=spf1 -all [RFC 7208]. The test-flag mechanics for each step (t=y, and pct=0 for receivers that predate RFC 9989) are on our staged rollout page.

If the firm has changed its name, the old domain is still yours and still spoofable: give it the parked-domain record above, or keep its DMARC record if it still forwards. Pick a quiet stretch for the quarantine step, not the week a large closing or settlement disbursement goes out.

What DMARC won't stop

DMARC protects one thing: your exact domain in the From line. RFC 9989 says so plainly. DMARC can only combat specific forms of exact-domain spoofing directly, and it does not address visually similar domain names or abuse of the From display name [RFC 9989, §2.2].

  • Lookalike domains. yourfirm-llp.com, registered last week, can pass its own SPF, DKIM and DMARC. Your record has no say over it.
  • Display names. A colleague's name in front of a free webmail address passes, because the domain really is the webmail provider's.
  • A real mailbox with a stolen password. Mail sent from inside your own tenant is your mail. It passes everything, because your systems sent it.
  • Everyone else's domains. Your record covers your domain. Your clients, and anyone else copied on the thread, each have their own.

For any change to payment instructions, the procedure that actually stops the loss is a phone call to a number you already have on file (the engagement letter, not the email signature) before anyone moves money. Put that rule in the engagement letter so the client knows it too. DMARC lowers how often a perfect forgery of your domain arrives. It doesn't make the call optional.

What DMARCit does on this job

You publish one DNS record with a reporting address. The aggregate reports from Gmail, Microsoft, Yahoo and the rest route to DMARCit and become a list of named senders, each with its SPF and DKIM alignment. You approve the senders that are yours and deny the rest. Alerts tell you when your pass rate drops, when receivers start quarantining or rejecting mail under your policy, and when reports stop arriving. DMARCit never writes your DNS: every record on your domain is one you placed. The details are on the product page.

What it doesn't do: read your mailboxes or filter the mail coming in to your staff. It won't catch a lookalike domain either. Those belong to your mail filter and your verification procedure, and if you want one tool that does them, this isn't it.

Questions that come up

Does the ABA require law firms to use DMARC?

No. Neither Formal Opinion 477R nor 483 mentions DMARC, SPF or DKIM. 477R asks for reasonable efforts to prevent unauthorized access to client information, weighed on factors like sensitivity and cost, and asks lawyers to understand how that information is transmitted. An enforced DMARC record and its reports are one way to show you weighed the risk of someone emailing clients as the firm. Your state's rules are the binding text.

Will p=reject block our billing or e-signature emails?

It can, if one of those services puts your domain in the From line and neither SPF nor DKIM aligns. That is what the p=none phase is for: the aggregate reports name every service sending as you and show whether it aligns, and you fix each one before enforcing. A service that sends from its own domain isn't touched by your policy.

If we publish p=reject, do we still need to verify wire instructions by phone?

Yes. DMARC handles forgeries of your exact domain at receivers that enforce it. It has nothing to say about a lookalike domain, or a partner's name typed in front of a webmail address. A real mailbox whose password was stolen passes everything. The phone call to a number from the engagement letter covers all three.

Start with what your domain publishes today

The checker reads your SPF, DKIM and DMARC records and names the next fix. No account. If you want the reports read for you after that, the plans are on the pricing page.

Run the free DMARC checkerCheck up to 25 domains at once

Sources

Every claim above links to one of these. None of them is a DMARCit page.

  • [ABA 477R] Formal Opinion 477R: Securing Communication of Protected Client Information, American Bar Association, Standing Committee on Ethics and Professional Responsibility. Cited for: Issued May 11, 2017, revised May 22, 2017. A lawyer generally may transmit client information over the internet where the lawyer has undertaken reasonable efforts to prevent inadvertent or unauthorized access; the Comment [18] factors under Model Rule 1.6(c); step 2 (understand how client confidential information is transmitted and where it is stored) and step 7 (due diligence on vendors providing communication technology). No mention of SPF, DKIM or DMARC.
  • [ABA 483] Formal Opinion 483: Lawyers' Obligations After an Electronic Data Breach or Cyberattack, American Bar Association, Standing Committee on Ethics and Professional Responsibility. Cited for: Issued October 17, 2018. Lawyers must employ reasonable efforts to monitor the technology and office resources connected to the internet; the duty to notify current clients of a breach that involves, or is substantially likely to involve, material client confidential information. No mention of email authentication.
  • [IC3 2025] 2025 IC3 Annual Report, FBI Internet Crime Complaint Center. Cited for: Business email compromise in 2025: 24,768 complaints (p. 7) and $3,046,598,558 in losses (p. 8).
  • [RFC 7208] RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, IETF, via the RFC Editor. Cited for: SPF authorizes the MAIL FROM and HELO identities (§1), the limit of ten DNS-querying terms (§4.6.4), and that receivers should not reject on a softfail alone (§8.5).
  • [RFC 9989] RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), IETF. Cited for: Identifier alignment (§3.2.10), what p=none, p=quarantine and p=reject mean (§4.7), and that DMARC only combats exact-domain spoofing and does not address lookalike domains or display names (§2.2).
  • [Microsoft DMARC guide] Set up DMARC to validate the From address domain for cloud senders, Microsoft Learn. Cited for: A message passes DMARC when SPF or DKIM passes and aligns; how receivers treat quarantine; forwarding breaking SPF alignment; the gradual p=none to p=reject rollout; the parked-domain record.
  • [Microsoft DKIM guide] Set up DKIM to sign mail from your cloud domain, Microsoft Learn. Cited for: No DKIM signing occurs for outbound mail from custom domains in Microsoft 365 until you configure it.
  • [Google sender guidelines] Email sender guidelines, Google. Cited for: From February 1, 2024: SPF or DKIM for all senders to Gmail; SPF, DKIM and DMARC (policy can be none) with From alignment for senders of more than 5,000 messages a day.
  • [Yahoo sender best practices] Sender Best Practices, Yahoo. Cited for: SPF or DKIM for all senders; for bulk senders, both SPF and DKIM, a DMARC policy of at least p=none that passes, and an aligned From domain.
  • [Yahoo sender FAQ] FAQs, Yahoo. Cited for: Yahoo does not specify a bulk-sender volume threshold.
  • [Microsoft 550 5.7.515] Fix NDR error "550 5.7.515" in Outlook.com, Microsoft Support. Cited for: Senders of 5,000 or more messages using the same From domain to Outlook.com, Hotmail and Live.com must pass both SPF and DKIM, publish a DMARC record, and align at least one of them, or get 550 5.7.515. No time period is stated.