The uncomfortable truth about law firm cybersecurity
Every day, small law firms across Florida process wire transfers, exchange confidential client documents, and communicate sensitive case details over email. Most of them do it without a single layer of email authentication in place.
That makes them extraordinarily attractive to attackers.
Unlike large corporations with dedicated security teams, SOCs, and multi-layered defenses, a two- or five-attorney firm typically relies on whatever security their email host provides by default. In most cases, that means almost nothing stands between an attacker and a perfectly spoofed email that appears to come from the managing partner.
What email spoofing actually is
Email spoofing is not hacking. It does not require breaking into anyone's account. It is much simpler — and much harder to detect.
The email protocol (SMTP) was designed in 1982, long before security was a concern. By default, anyone can send an email claiming to be from any address. There is no built-in verification. When you receive an email from "john@smithlawfirm.com," your email client displays that address because the sender told it to. It did not verify anything.
This means an attacker in another country can send an email that looks exactly like it came from your managing partner — same display name, same email address, same signature block. The recipient has no way to tell the difference by looking at it.
Real attack scenarios targeting law firms
Wire fraud through fake closing instructions
This is the most common and most devastating attack against real estate law firms. The attacker monitors public records or MLS listings to identify upcoming closings. They send the buyer an email — apparently from the attorney handling the closing — with "updated wire instructions." The wire goes to the attacker's account. Average loss: $150,000 to $500,000.
The FBI's Internet Crime Complaint Center reported over $2.9 billion in losses from business email compromise (BEC) in 2023 alone. Real estate transactions are the single largest category.
Client impersonation
An attacker spoofs an email from a client to the attorney, requesting urgent action: "Please wire the settlement funds to this new account" or "I need you to send the signed documents to my accountant at this address." Because the email appears to come from the client's actual address, the attorney complies.
Partner impersonation for internal fraud
A spoofed email from a senior partner to an associate or office manager: "I need you to wire $35,000 to this account for a confidential settlement. Don't discuss this with anyone else — it's under NDA." The urgency and authority make people act without verifying.
Opposing counsel impersonation
A spoofed email appearing to come from opposing counsel with a malicious attachment — "Updated settlement agreement attached for your review." The attachment installs malware that gives the attacker access to the firm's entire case management system.
The ABA technology competence requirement
In 2012, the American Bar Association amended Model Rule 1.6 to add Comment 18, which states that lawyers must "make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client."
The Florida Bar adopted this rule. Florida Bar Rule 4-1.6(e) requires lawyers to make reasonable efforts to prevent unauthorized access to client information.
What constitutes "reasonable efforts" is evolving, but allowing anyone in the world to send emails pretending to be from your firm — when the fix is a single DNS record — is increasingly difficult to defend as reasonable.
The three email authentication protocols that prevent this
SPF (Sender Policy Framework)
SPF is a DNS record that tells the world which mail servers are allowed to send email on behalf of your domain. When a receiving server gets an email from "yourfirm.com," it checks the SPF record to see if the sending server is authorized. If it is not, the email can be flagged or rejected.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to every email you send. The receiving server can verify this signature against a public key published in your DNS. If the signature does not match, the email was tampered with or forged.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC ties SPF and DKIM together and tells receiving servers what to do when an email fails authentication. The three policy levels are:
- p=none — Monitor only. Spoofed emails still get delivered. This is essentially a placeholder.
- p=quarantine — Send suspicious emails to spam. Better, but not bulletproof.
- p=reject — Block all emails that fail authentication. This is the only policy that actually prevents spoofing.
The critical point: having DMARC set to p=none is almost as bad as having no DMARC at all. The emails still get delivered. You just get reports about it.
What you should do right now
Step 1: Check your current status. Run a free scan of your domain at kasperashield.com/security-assessment. In under 30 seconds, you will see whether your firm has SPF, DKIM, and DMARC configured — and whether they are actually enforced.
Step 2: Talk to your DNS provider. If your DMARC policy is "none" or missing entirely, you need to change it. Your IT provider or domain registrar can add a DMARC record in minutes. Start with p=quarantine and move to p=reject once you have confirmed all legitimate email sources are covered.
Step 3: Train your staff. Email authentication prevents spoofing of your domain, but your employees still need to recognize phishing from other domains. Regular phishing simulation — not annual compliance training — is what builds real awareness.
Step 4: Monitor continuously. DMARC is not set-and-forget. Email infrastructure changes. New services get added. SPF records drift. Continuous monitoring catches problems before attackers do.
The fix is not expensive. It is not complicated. But it does require knowing you have a problem in the first place. Most firms do not check until after an incident.
