DMARC for title and escrow companies

DMARC for title companies: make forged wire instructions from your domain fail

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

Two days before closing, the buyer gets an email from your escrow officer's address with new wire instructions. If the attacker used your exact domain and you publish p=reject, the buyer's mail provider is told to reject it. If they registered a domain one character off, or got into a real mailbox at the brokerage, DMARC does nothing, and the call-back to a number you already had is the only thing between the down payment and someone else's account.

DMARC handles the first case. The second is why the call-back stays, and the limits section below spells out where the record stops helping.

Check your domain free Several domains? Check them together

The numbers, and what they cover

In 2025 the FBI's Internet Crime Complaint Center received 12,368 real estate fraud complaints with $275,110,419 in reported losses, and 24,768 business email compromise complaints with $3,046,598,558 in losses [IC3 2025, pp. 7 to 8]. Those are complaints people filed, not every incident, and the business email compromise figure covers every industry, not just real estate.

The wire email is the last step of the attack, not the first. Somewhere upstream someone learned the closing date, the parties and the amount. DMARC can't touch that part. What it controls is whether an email claiming to come from your exact domain gets delivered as if it did.

That is worth controlling, because it is the one forgery the buyer has no way to spot. The From line is genuinely yours. The forgeries DMARC can't stop are the reason the verification procedure matters more than any DNS record.

What ALTA's Best Practices ask for

ALTA's Best Practices framework is at version 5.0, dated October 8, 2026 [ALTA Best Practices]. Its wire items sit in Pillar 2, funds and escrow trust accounts. Item G asks for a written wire transfer procedure tested at least annually. Under it, G.1 asks that outgoing wires have documented procedures to verify wire transfer instructions independent of the initial communication, procedures that should include multi-factor authentication [ALTA 5.0, Pillar 2, G and G.1]. G.2 covers incoming wires: a documented procedure to alert consumers to the risk of wire fraud [ALTA 5.0, G.2]. Pillar 3 adds annual cybersecurity awareness training that covers social engineering [ALTA 5.0, Pillar 3, B.4].

The framework doesn't mention email authentication. Read the wire items closely and they assume the email can be forged: verification has to happen outside the channel the instructions arrived on. DMARC doesn't change that requirement. It lowers how often a perfect copy of your domain reaches a buyer at all, and the aggregate reports show you when someone is sending as your domain and failing.

ALTA is a trade framework, not a regulation. Your state's escrow and title rules, and your underwriter's agency agreement, are the texts that bind you.

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.yourtitleco.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 company

Title and escrow offices send more automated mail than most small businesses, and most of it is about money. The list to build before any policy change:

  • Microsoft 365 or Google Workspace. Staff mailboxes, the escrow officers' included, since theirs is the address a fraudster copies. Microsoft 365 doesn't DKIM-sign mail from a custom domain until someone sets it up [Microsoft DKIM guide].
  • Title production software. Commitments, invoices and status emails sent from the production system with your domain in the From line.
  • Closing and status notices. Scheduling confirmations and document-ready notices to buyers, sellers, agents and lenders.
  • Secure email and e-closing platforms. Encrypted-message notices and signing invitations. Some send as you and some send as themselves; the reports tell you which.
  • The wire-instruction delivery tool. If instructions go out through a secure portal, its notice email is the one most worth aligning. It is the message a fraudster most wants to copy.
  • Scanners and copiers. Scan-to-email from the office copier, relayed through an SMTP service with your domain in the From line. These break quietly when the policy tightens.

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 company'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 company: 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 yourtitleco.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.

Run the p=none phase across at least one month-end, so the reports include your busiest closing days and every system that only fires then. Make the move to quarantine early in a month, not in the last week. Brand or county domains you no longer send from get the parked-domain record above.

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. yourtitle-co.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.

Keep the call-back. Before releasing funds on new instructions, or accepting changed payoff details, call a number you got at the start of the transaction, not one in the email. That is the “independent of the initial communication” step ALTA asks you to document for outgoing wires [ALTA 5.0, Pillar 2, G.1], and it covers every case in the list above.

Tell buyers early, in writing, that your wire instructions will not change by email. That is the kind of consumer alert ALTA's G.2 item asks for on incoming wires [ALTA 5.0, G.2], and it gives the buyer a rule to apply when a convincing email arrives anyway.

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 ALTA require title companies to use DMARC?

No. ALTA Best Practices 5.0 never mentions email authentication. Its wire items are procedural: a written wire transfer procedure, verification of outgoing wire instructions independent of the initial communication, a consumer wire-fraud alert for incoming wires, and annual training that covers social engineering. DMARC works toward the same goal from the DNS side by making forgeries of your exact domain fail. It replaces none of those items.

If we publish p=reject, can we skip the call-back?

No. p=reject only covers mail that forges your exact domain, and only at receivers that enforce DMARC. A lookalike domain gets through. So does a fake display name on a free mailbox, and so does an attacker writing from a real mailbox they broke into at the brokerage, the lender or your own office. A call to a number you already had catches every one of them.

The fraudster used a domain that looked like ours. Would DMARC have stopped it?

No. A lookalike domain is a different domain with its own records, and RFC 9989 says outright that DMARC does not address visually similar domain names. Registering the obvious variants and giving each one a parked-domain record removes a few options. It cannot remove them all.

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.

  • [IC3 2025] 2025 IC3 Annual Report, FBI Internet Crime Complaint Center. Cited for: Real estate fraud: 12,368 complaints (p. 7) and $275,110,419 in losses (p. 8). Business email compromise: 24,768 complaints (p. 7) and $3,046,598,558 in losses (p. 8).
  • [ALTA Best Practices] ALTA Best Practices, American Land Title Association. Cited for: Lists the version 5.0 framework, dated 10-08-2026, as current.
  • [ALTA 5.0] ALTA Best Practices: Title Insurance and Settlement Company Best Practices, Version 5.0, American Land Title Association. Cited for: Released October 8, 2026. The ALTA Board approved the proposed revisions on June 23, 2026 and took public comment through July 31, 2026. Pillar 2, G: a written wire transfer procedure tested at least annually; G.1: for outgoing wires, documented procedures to verify wire instructions independent of the initial communication, which should include multi-factor authentication; G.2: for incoming wires, a documented procedure to alert consumers to wire fraud risk. Pillar 3, B.4: annual cybersecurity awareness training that covers social engineering. No mention of email authentication.
  • [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.