Belmor BranchHow to stop people sending email as your firm
A complete guide to DMARC enforcement for title and escrow companies. Written for the person who owns the business, not the person who owns the server.
The Problem
Your domain is a signature anyone can forge.
When someone sends an email, they choose what appears in the “From” line. There is nothing in email itself that stops a stranger from typing your firm’s address into that field.
That means a criminal can send an email that appears, genuinely, not approximately, to come from your office. Not a lookalike domain with a swapped letter. Your actual domain.
In real estate closings, this has a specific and expensive shape: a message arrives at your buyer with updated wire instructions, apparently from your firm, days before closing. The money moves. It does not come back.
The detail that matters most: that email goes to your client, not to you. Nothing appears in your sent folder. No alert fires. You find out when someone asks where their money went.
The Mechanism
Three records, working together.
Email authentication has three parts. Most explanations start with the acronyms; this one starts with what each part is for.
SPF: the guest list.
A public record listing which mail servers are allowed to send email for your domain. When mail arrives claiming to be from you, the receiving server checks whether it came from a server on that list.
DKIM: the wax seal.
Your mail server cryptographically signs each message. A public key published in your DNS lets the receiving server verify the signature is genuine and the message was not altered in transit.
DMARC: the instruction.
This is the one that does the blocking. It tells receiving mail servers what to do when a message fails the first two checks. Without it, the answer is: deliver it anyway.
There is a fourth concept, and it is the one that trips people up most: alignment. It is not enough for a message to pass SPF or DKIM: the domain that passed must match the domain your recipient sees in the From line. A vendor can authenticate perfectly against their own domain and still fail DMARC on yours, because those two domains do not match. Most enforcement projects stall here.
Policy
Only one of these protects you.
A DMARC record contains a policy tag, written as p=. It has three possible values, and the difference between them is the difference between protection and paperwork.
Setting
What it does
Are you protected?
p=none
Logs failures. Delivers the mail anyway.
No.
p=quarantine
Sends failing mail to the spam folder.
Partly.
p=reject
Refuses failing mail outright. It never arrives.
Yes.
The overwhelming majority of firms that have a DMARC record at all are sitting at p=none. Someone started the work and stopped at the monitoring step, which is the correct first step, but it is not protection. Fewer than one in five domains with a published record ever reach enforcement.
Verify
Ten seconds, on a tool we do not own.
Go to mxtoolbox.com, choose SuperTool, and search:
$ dmarc:yourfirm.comYou will get one of four results.
“No DMARC record found”
Nothing is protecting your domain. Anyone can send as you.
“p=none”
A record exists but blocks nothing. Functionally the same exposure, with logging.
“p=quarantine”
Forged mail is being sent to spam. Partial protection.
“p=reject”
You are protected against exact-domain impersonation. This is the destination.
If you prefer the command line:
$ dig +short TXT _dmarc.yourfirm.comThe Fix
Six steps, and the order matters.
This is the entire process. It is not secret and it is not proprietary. DMARC is a published open standard. What follows is what a competent implementation actually involves, including the time each step honestly takes.
01
Inventory every system that sends as your domain.
~1–2 hours. Tedious, not technical.
Not just Outlook or Gmail. Your closing and title software. E-signature. Invoicing. Marketing and newsletters. Appointment reminders. The contact form on your website. Anything that sends mail with your domain in the From line. Most offices find more than they expected, and the ones they forget are the ones that break later.
02
Turn on DMARC reporting and wait.
15 minutes to configure. Then a 2–4 week wait.
Publish a DMARC record set to p=none with a reporting address in the rua tag. Point it at a reporting service. EasyDMARC, dmarcian, and Postmark all have free tiers. This changes nothing about your mail delivery; it only collects data on who is sending as you.
The waiting is not optional and it cannot be compressed. Infrequent senders - the monthly newsletter, the quarterly statement, the annual renewal notice - will not appear in the reports for weeks. Enforce before they surface and you will silently start bouncing your own mail.
03
Repair SPF.
30 minutes to several hours, depending on how many vendors you use.
Every legitimate sending service needs its include in your SPF record. The total must stay under ten DNS lookups, and that count includes nested lookups inside the includes you have already added. Exceed ten and SPF fails silently: nothing appears broken, it simply stops working. If you are over the limit you will need to flatten or restructure the record.
04
Enable DKIM on every sender.
20–40 minutes per sender. Most offices have between eight and fifteen.
Google Workspace: Admin console → Apps → Google Workspace → Gmail → Authenticate email → generate a 2048-bit key → publish the TXT record → return and click Start authentication. That final click is easy to miss and nothing works without it.
Microsoft 365: Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication → DKIM → select your domain → enable → publish the two CNAME records it generates.
Every third-party sender has its own process, usually found under “authenticate your domain” or “custom sending domain.”
05
Confirm alignment.
This is where most attempts fail.
Check your reports for alignment specifically, not just pass or fail. A sender can pass SPF and DKIM against its own domain and still fail DMARC for you. Senders that cannot be made to align need to be moved to a subdomain or replaced. This step is why the reports in step two matter - without them you are guessing.
06
Raise the policy in stages.
3–4 weeks of monitoring and adjustment.
Move from p=none to p=quarantine. Hold roughly a week and watch the reports. Then move to p=reject and hold again. If a legitimate sender begins failing at any stage, roll back one level, fix that sender, and continue.
Never jump straight to p=reject. That is the single most common way a firm takes down its own closing documents.
Maintenance
Enforcement is not permanent.
Reaching p=reject is not the end of the work, because the configuration degrades on its own:
New senders break it.
Every tool your office adds that sends mail as your domain will either start failing or force someone to loosen the policy to make it work. The person who added the tool usually will not know why the mail stopped.
SPF drifts back over the limit.
Vendors accumulate. At eleven DNS lookups the record fails silently again.
DKIM keys rotate.
Platforms cycle them periodically. If the DNS is not updated, that sender stops authenticating.
The reports keep arriving.
They are raw XML. Nobody reads them by hand, so without someone watching, both impersonation attempts and newly broken senders go unnoticed until something visible fails.
Most firms handle this by assigning a recurring monthly check to whoever owns their DNS.
Scope
One honest limitation.
DMARC enforcement stops impersonation of your exact domain. It does not stop someone registering a lookalike: your firm’s name with a letter swapped, or a different extension, and sending from that.
That is a separate problem requiring separate monitoring. Anyone who tells you enforcement solves both is overstating it.
Realistically, this is ten to twenty hours of work spread across four to eight weeks. Most of the calendar time is the monitoring period in step two, which exists specifically so that nothing breaks.
Plenty of firms run this in-house. If yours would rather not, that is what we do.