The authentication gap in California escrow

Over the past month we ran DMARC posture scans against the public DNS of more than 250 California escrow and title businesses, drawn from the state’s licensed independent escrow companies and public business listings.

Every check in this scan reads public DNS records. These are the same records any receiving mail server consults when deciding whether to deliver a message. No systems were accessed and nothing was sent. This is the visible, public layer of email infrastructure, and anyone can check any domain the same way.

What we looked for

A domain’s DMARC record tells receiving mail servers what to do with email that claims to come from that domain but fails authentication. There are three meaningful states. A policy of reject refuses forged mail outright. A policy of quarantine sends it to spam. A policy of none, and this is the common one, logs the forgery and delivers it anyway. A missing record is the fourth state: no instructions at all, so forged mail delivers normally.

What we found

In our most recent fully tabulated batch of 62 domains:

27 percent had no DMARC record at all.
24 percent were at p=none, monitoring without blocking.
24 percent were at p=quarantine.
24 percent were at p=reject.

Which means 52 percent of scanned firms, just over half, cannot currently stop a stranger from sending email that appears to come from their own address. Across the wider set of 250+ domains the proportion holds at roughly half.

What it means in practice

For an escrow or title firm the exposure has one specific shape. A forged message carrying revised wire instructions, sent from the firm’s actual domain, passes authentication and arrives in a buyer’s inbox looking exactly like every legitimate message the firm has ever sent. It goes to the client, not to the firm. Nothing appears in the firm’s inbox or sent folder. The first sign is a wire that went to the wrong account.

The firms in the monitor-only group are in a particular position: someone started this work, published a record, and stopped at the observation step. The record’s presence can read as protection. It is not. It is a log.

Why the number is so high

Three reasons, none of them negligence. The setting lives in DNS, where nothing prompts anyone to look. Neither Google Workspace nor Microsoft 365 publishes a DMARC record on a customer’s behalf, so it exists only if someone adds it deliberately. And the pressure is recent: the major mailbox providers only began tightening sender authentication requirements over the last two years, which is why a setting that sat ignored for a decade is suddenly being checked.

We update these figures as our scanning coverage grows.

Plenty of firms fix this in house once they know it is there. If yours would rather have it handled, that is what we do.