Lookalike Domain Fraud: BEC Defense Playbook
2026-10-13 · 7 min read · By the DomainGuard team
The short version
Business email compromise (BEC) via lookalike domains is the highest-value use of typosquatting: instead of spoofing your exact domain, which your DMARC policy would catch, the attacker registers a domain that merely looks like yours, sets up mail on it, and sends invoice redirections, "updated bank details," and payment approvals that pass every authentication check, because the checks run against the attacker's domain, which is correctly configured. In March 2026, the town of Surfside Beach, South Carolina, lost $545,598.30 to exactly this play. Your SPF, DKIM, and DMARC records do nothing to stop it. What stops it is a verification procedure for payment changes plus monitoring of the lookalike domains themselves.
Anatomy of an invoice-fraud run
What follows is a hypothetical scenario, clearly labeled as such, but every step in it is drawn from real incident patterns, including the verified Surfside Beach case. If you run accounts payable, read it as a drill.
Monday. Your company is mid-project with a contractor, Harborline Construction (fictional). Invoices have been flowing for two months from billing@harborlineconstruct.com. The attacker registers harborlineconstrct.com, one missing "u", for $12, publishes MX records pointing at a cheap mail host, and configures SPF and DKIM correctly on the fake domain. From an authentication standpoint, the fake domain is now a perfectly legitimate sender.
Tuesday. An email arrives at your AP clerk from billing@harborlineconstrct.com. The display name reads "Harborline Construction, Billing." The body references the real project, the real outstanding invoice number (scraped from an earlier thread the attacker obtained or guessed), and explains that Harborline has "migrated to a new operating account", new wire instructions attached. The tone is professional. The logo is right. The reply-to is the fake domain.
Wednesday. Your clerk, busy and trusting the thread context, processes the payment change. Maybe they reply asking for confirmation; the attacker, controlling the fake inbox, confirms cheerfully. The wire goes to the attacker's account.
Two weeks later. The real Harborline asks about their overdue invoice. Your team pulls up the thread, and that's when someone finally looks at the domain character by character and finds the missing "u." The money is gone. In the Surfside Beach case, the forensic investigators concluded the attackers used the lookalike specifically to delay this moment of discovery while the funds moved.
Notice what didn't happen: nobody's account was compromised, no malware was involved, no authentication failed. Every technical control worked as designed, on the wrong domain.
Why your email authentication can't see this
This is the misconception that costs companies the most. SPF, DKIM, and DMARC answer one question: "is this email legitimately from the domain it claims to be from?" For email from harborlineconstrct.com, the answer is yes — the attacker owns that domain and configured it properly. Your DMARC policy on harborlineconstruct.com never enters the picture, because nothing claims to be from your domain.
The same blind spot covers display names. "Harborline Construction, Billing" is just a text label the sender sets; no protocol validates it. And reply-to headers can point anywhere, a message can show one address in the From line while replies route to another. These aren't bugs. They're how email works. The defense was never going to be a protocol; it has to be a procedure.
The defenses that actually work
1. A call-back rule for payment changes. This is the single highest-leverage control: no change to vendor payment instructions is processed without verbal confirmation via a phone number obtained independently, from the vendor's known contact, your contract file, or their official website, never from the email requesting the change. The Surfside Beach fraud, like nearly every BEC case, dies at this step: one phone call to a known number. Write the rule down, make it non-optional, and make sure AP staff know that "but the email looked right" is never an exception.
2. Treat first-time senders from lookalike domains as hostile. Train finance staff on the specific check: when an email concerns money and the sender's domain is one you've never seen, compare it character-by-character against the known-good domain. Better yet, maintain an internal vendor-domain registry, a simple list of the exact domains each vendor uses, and flag anything not on it.
3. Check the reply-to and the headers, not just the From line. In your mail client, expand the sender details. A From address on one domain with a reply-to on another is a standard BEC tell. Mismatched display name and address is another. None of these are conclusive alone, but stacked with a payment request they should stop the process cold.
4. Slow down new-vendor and changed-detail workflows. Attackers exploit urgency, "process today to avoid late fees," "the account closes Friday." Build deliberate friction into payment-detail changes: a mandatory waiting period, a second approver, or both. Legitimate vendors survive a 24-hour verification delay. Fraud doesn't.
5. Monitor the lookalike space. This is the domain-side defense. Generate the typosquat variants of your brand and your key vendors' brands, watch which get registered, and treat "newly registered + has MX records" as a pre-attack indicator. An attacker setting up mail infrastructure on your lookalike is telling you what comes next, if you're watching. Our typosquatting guide walks through the variant generation and the MX check specifically.
Run it as a drill before you need it for real
The controls above only work if people follow them under pressure, and pressure is exactly what the attacker manufactures. Once a quarter, run a fifteen-minute tabletop exercise with your finance team: hand them a printed copy of a fake "updated bank details" email, built on a lookalike of your own domain, so the lesson lands, and watch what happens. Who checks the domain character by character? Who reaches for the phone? Who processes it? The first run is usually sobering. The second run, after you've written the call-back rule into the actual payment procedure and taped the vendor-domain registry next to the AP workstation, looks completely different. Attackers rehearse; defenders should too.
What to do if you suspect you're being targeted right now
If a suspicious payment-change email is sitting in someone's inbox: don't reply, don't click, don't forward it around the office (forwarding can strip headers). Isolate it, pull the full headers, and verify through the independent channel, call the vendor at their known number and ask whether they sent it. If money already moved, contact your bank's fraud department immediately (wire recalls are time-critical), preserve the email with headers intact, file with the FBI IC3 at ic3.gov, and report the lookalike domain through the takedown ladder. Then find every other person in your organization who received mail from that domain, BEC campaigns rarely target just one inbox.
FAQ
Does DMARC protect us against lookalike-domain BEC?
No. DMARC prevents spoofing of your exact domain. A lookalike domain is a different domain that the attacker legitimately owns, so it passes its own SPF, DKIM, and DMARC checks. This is the most dangerous misconception in email security.
What's the one control you'd implement first?
The call-back rule: verify every payment-instruction change by phone using a number you already had, not one from the requesting email. It's free, it needs no software, and it defeats the entire attack class.
Should we register lookalike domains of our vendors too?
You can't defensively register everyone's variants, but you can monitor them. Watching your top vendors' lookalike space for new registrations with MX records gives you early warning that a BEC campaign is being staged — sometimes before the first lure email goes out.
How do attackers get the invoice details that make the lure convincing?
Often from earlier compromise, a vendor's mailbox, a forwarded thread, but sometimes from nothing more than public information: project announcements, social media posts about the engagement, and guessed invoice numbering. The lure doesn't need stolen data to work; it needs a plausible pretext and a trusted-looking domain.