# How to spot a spoofed domain in a payment request
A practical field guide to identifying spoofed domains inside payment requests, written for settlement professionals, closing attorneys, brokers, and OTC desks who handle large multi-party transactions.
---
A closing is two days out. The buyer's attorney has been corresponding with the title company for three weeks. The email thread is long, the tone is familiar, the transaction details are accurate down to the property address and the scheduled date. Then a new message arrives: wire instructions have changed. A new account number. A new bank. Please update before 5 p.m.
The domain in the sender's address is off by one character — a hyphen that was never there before, or a Cyrillic "a" standing in for a Latin one. Nobody checks. The wire goes out.
This is not a hypothetical. In real estate alone, the average Business Email Compromise (BEC) incident results in losses of $150,000 to $200,000 USD (approximately $230,000 to $308,000 AUD), and nearly 30% of title companies experienced an attempted BEC attack in a recent year. The attack surface is not limited to real estate: OTC desks, commercial brokers, escrow officers, and settlement agents across every high-value sector face the same threat vector. The mechanism at the center of most of these attacks is a spoofed domain — a domain name engineered to look like a trusted counterpart's while routing replies and wire confirmations to the attacker.
This article breaks down exactly how domain spoofing works, the specific visual and technical tricks attackers use, and a concrete inspection protocol that professionals in multi-party transactions can put into practice today.
## Why payment requests are the prime target
Settlement professionals occupy a uniquely exposed position. Closings involve large, time-sensitive transfers and predictable communication patterns. Attackers study those patterns. They know the sequence of events — offer acceptance, due diligence, wire instruction delivery, confirmation call, transfer — and they time their intervention accordingly.
Last-minute instruction changes are a hallmark of the attack: fraudsters send "updated" wire instructions close to closing, knowing that deal pressure reduces scrutiny. A settlement agent who might normally pause and triple-check a new account number is far less likely to do so at 4:30 p.m. on the day before disbursement.
Business Email Compromise is a form of fraud that involves impersonation of trusted business contacts to induce unauthorized payments, credential disclosure, invoice changes, or data sharing — and BEC scams have evolved with AI-enhanced email spoofing, making them harder to spot. The spoofed domain is the infrastructure underpinning most of those attacks. It is what makes the sender address look plausible, what gives the payment request its surface legitimacy, and what directs reply-to traffic away from the legitimate counterpart.
Analysts have observed a fivefold year-over-year rise in payment fraud attempts, with growth marked by attackers relying on forged financial documents, fabricated business conversations, and behavioral pressure to make fraudulent payments look routine and already approved. Understanding the technical mechanics of how a domain is spoofed is the first step to building a detection habit that holds up under deal pressure.
## The six techniques attackers use to spoof domains
### 1. Character substitution and typosquatting
Typosquatting is a cyberattack technique where attackers register domain names that closely resemble legitimate websites, exploiting typographical errors or misspellings made by users. In the context of a payment request, the attacker is not waiting for a mistype — they are sending the fake domain to the recipient directly, counting on the eye to skip over a single-character discrepancy in a long address.
Character substitution attacks swap similar-looking characters, like replacing "o" with "0" in a domain, to trick recipients into believing they are communicating with the legitimate party. Common substitutions include: replacing the letter "l" with the numeral "1", replacing "o" with "0", replacing "rn" with "m" (which is nearly indistinguishable in most proportional fonts), or swapping "vv" for "w". At reading speed in an email client, these swaps are functionally invisible. When the domain appears inside a long thread with accurate transaction details, the eye pattern-matches rather than reads character by character.
Spoofing frequently involves creating email addresses that closely resemble legitimate ones — for example, replacing an "m" with an "rn" or using a different domain extension such as .biz or .net instead of .com.
### 2. Subdomain manipulation
A subdomain trick is one of the most effective ways to fool a reader who has been trained to check domains. In subdomain spoofing, the attacker places a trusted-looking domain string into the subdomain of the target URL, while the actual registrable domain belongs to the attacker — exploiting the fact that recipients may focus on the beginning of a domain-like string and may not fully inspect the registrable domain that determines the actual destination.
Consider an email sent from: `payments.legitimatetitleco.com.frauddomain.cc`
Most readers will see "legitimatetitleco.com" and stop reading. The actual domain — the one that determines where the message originated — is `frauddomain.cc`, which the attacker controls. Typosquatters add extra subdomains to create seemingly legitimate URLs, such as "signin.paypal-secure.com" instead of the official "paypal.com." The same technique applied to a closing attorney's domain or an OTC desk's payment portal is just as effective, and far less scrutinized because the context is a trusted ongoing transaction.
### 3. TLD swapping
Attackers register the same domain name with a different top-level domain (TLD), such as "example.org" instead of "example.com," to exploit user assumptions about domain endings. In a payment context, this manifests as an email arriving from `titlecompanyname.co` instead of `titlecompanyname.com`, or from `brokeragefirm.net` instead of `brokeragefirm.com`. The name is correct; only the extension has changed.
Examples include changing the suffix of a domain name from ".com" to ".us" or changing a letter "o" to a number "0." With the proliferation of new generic TLDs over the past decade — .io, .co, .biz, .finance, .capital, .legal, and hundreds of others — TLD swapping has become easier to execute convincingly and harder to catch by instinct alone. A recipient who knows the legitimate domain as `.com` may register `.co` as a visual match without consciously noticing the difference.
### 4. Combo-squatting and keyword insertion
Attackers slightly alter a brand name to create a typosquatting domain that looks legitimate, and by adding words such as "support," "login," "secure," or "verify," they create convincing lookalike domains. In a payment request context, the inserted keywords are chosen to reinforce the legitimacy of the message: `securepaymentsettlements.com` in place of `settlementsco.com`, or `titleco-closingdesk.com` in place of `titlecoclosing.com`.
Fraudsters register domains that are one character different from legitimate firm names — for example, "titleco-closings.com" instead of "titlecoclosings.com" — and use them to send convincing emails. The additional word or hyphen not only obscures the discrepancy; it actively adds semantic reassurance. A domain that contains the words "secure," "verified," or "settlement" reads as more official to a tired professional scanning a stack of closing documents.
### 5. Homograph and Punycode attacks
This is the most technically sophisticated variant, and the one most likely to defeat a careful visual inspection of an email address. In a Punycode homograph attack, the URL looks correct even under scrutiny, because Unicode allows the creation of lookalike characters — and attackers exploit this to spoof legitimate domains and trick users into visiting malicious websites.
Because some Roman letters resemble characters in Greek, Cyrillic, and other alphabets, attackers can register domains that swap familiar ASCII characters with similar-looking Unicode symbols. The result is a domain that displays as, say, `settlementco.com` in an email client but actually encodes to an entirely different address. What appears to be a standard Latin "o" may be a Cyrillic character that looks eerily similar.
Punycode-encoded domains often slip through email filters, DNS blocklists, and even experienced cybersecurity eyes. Modern browsers have added defenses — some will display the raw Punycode representation (which begins with `xn--`) rather than the visual Unicode equivalent, which would immediately reveal the spoof. But email clients do not always apply the same treatment — if a homoglyph is sent via email, it will be displayed to the user in the IDN form and could be used for phishing.
While many homograph attacks are recognizable with proper training, those based on international domain names (IDN) can be visually indistinguishable from the legitimate domains they are spoofing.
### 6. Display name spoofing and reply-to hijacking
Not every spoofed payment request requires a lookalike domain in the visible sender address. Display name spoofing allows an attacker to set the visible "From" name — the name that appears in bold in most email clients before the actual address — to anything they choose, while using a completely unrelated sending domain. An email may display as:
`Clearinghouse Settlement Team `
Most email client interfaces, particularly on mobile, show only the display name by default. A recipient who has dealt with "Clearinghouse Settlement Team" for three weeks may not tap through to inspect the actual sending address. Cybercriminals develop spoofed tools that look and feel identical to legitimate ones but are designed to steal data and redirect funds.
Separately, reply-to hijacking sets a legitimate-looking sender address on the message header while routing all replies to an attacker-controlled address. The payment request arrives from a real address; the reply containing confirmation, updated bank details, or any sensitive follow-up goes to the attacker.
## What a spoofed payment request looks like in practice
It helps to walk through two concrete scenarios — the kind that appear in transaction records after the loss has already occurred.
**Scenario A: The closing attorney impersonation**
A commercial real estate deal is three days from closing. The deal involves a buyer entity, a seller, two brokers, a lender, and a closing attorney. The closing attorney's legitimate domain is `harrisonlawgroup.com`. The attacker registers `harr1sonlawgroup.com` — replacing the "i" with the numeral "1". They set up email infrastructure on that domain, pull public information about the transaction from LinkedIn and county records, and compose a message that correctly names the transaction, the parties, the escrow amount — $1.85 million USD (~$2.85 million AUD) — and states that wire instructions have been updated due to a bank consolidation. The message arrives at 4:45 p.m. on a Thursday.
In some cases, criminals intercept legitimate email threads and reply from within them, so the conversation history looks authentic. In this scenario, the attacker has not intercepted the thread — they have studied it through open-source research and reconstructed enough context to make the message credible. The domain discrepancy is a single character. Under deal pressure, at end of day, it is not caught.
**Scenario B: The vendor invoice redirect**
An OTC desk regularly settles multi-party transactions involving a liquidity provider, a broker, and several end counterparties. A monthly settlement invoice arrives from the liquidity provider's email domain — except this month the domain is `lqdprovider-finance.com` instead of `lqdprovider.com`. The combo-squatted domain was registered eleven days earlier. Attackers register domain variants in batches, using low-cost registrars, standing a better chance of tricking automated detection systems. The invoice is formatted identically to every previous invoice. The settlement amount is plausible. The bank details are new, attributed to a currency switching account. The wire goes out before the discrepancy is flagged.
These scenarios share a common structural feature: these attacks may not contain malware or any conventional technical indicator of compromise — organizations should monitor for behavioral and payment indicators, because no single indicator confirms fraud; combinations and deviations from established behavior increase risk.
## A domain inspection protocol for payment professionals
The following protocol is designed to be applied to every payment request that involves new or changed bank details, regardless of how well-known the sender appears to be. It is process, not instinct — because instinct is what attackers engineer against.
### Step 1: Isolate the registrable domain
Do not read the display name. Do not read the subdomain chain. Locate the registrable domain — the string immediately before the final dot and TLD — and that alone. In `payments.harrisonlaw.settlements.com`, the registrable domain is `settlements` under `.com`. In `payments.harr1sonlaw.com`, the registrable domain is `harr1sonlaw`. Once isolated, check it character by character against the domain you have on file from first engagement — not from any document delivered in the current message.
### Step 2: Check the reply-to field explicitly
Most email clients display a warning or secondary address indicator when the reply-to address differs from the sender address. This is a deliberate red flag mechanism. Find the message headers — in desktop clients this is typically accessible through "View Source," "Show Original," or a dropdown on the message — and confirm that the `Reply-To:` field matches the `From:` field exactly. A mismatch is not a curiosity; it is a hard stop.
### Step 3: Verify the phone number independently
Before acting on any wire instruction, call the originating party at a phone number established at engagement — not the number in the email signature, not the number on the wire instruction PDF. Voice cloning makes any number provided in the email worthless; the only safe number is the one captured at engagement and stored in the matter file. This step cannot be shortcut. After a successful email compromise, attackers sometimes follow up with a phone call confirming the wire instructions, with timing deliberate and caller ID spoofed to match the expected party.
### Step 4: Flag the behavioral tripwires
Prioritize requests that combine several signals: a new payee, altered banking details, forged paperwork, executive authority, and time pressure. Any single one of these in a payment request warrants heightened scrutiny. Two or more together should trigger a full verification pause regardless of how convincing the message appears. Compare sender domains and reply-to addresses against known vendor and executive identities, and confirm that an apparent email history exists in your real mail environment — not only inside forwarded content.
### Step 5: Apply the HTTPS skepticism rule
Attackers registering phishing pages frequently use HTTPS to build false trust. A padlock icon and a valid TLS certificate confirm that the connection to a server is encrypted — they say nothing about whether the server on the other end belongs to who it claims to belong to. An attacker operating `harr1sonlawgroup.com` can obtain a valid certificate for that domain just as easily as a legitimate firm obtains one for its own. The padlock is not identity verification.
### Step 6: Watch the registration age
A domain registered within the last 60 days sending a payment instruction attached to a long-term commercial relationship is a strong anomaly signal. WHOIS lookups are free and take thirty seconds. A legitimate title company, law firm, or broker does not change its primary communication domain mid-transaction. Monitor lookalike domains by checking WHOIS data and phishing reports proactively — and apply the same check reactively whenever a new domain appears in transaction correspondence.
## The organizational controls that make individual vigilance sustainable
Individual domain inspection is necessary but insufficient at scale. A settlement agent handling fifteen closings simultaneously, an OTC desk processing dozens of counterparty confirmations per week — these environments need structural controls so that the inspection protocol does not depend entirely on any one person's attention on any given afternoon.
**DMARC enforcement.** DMARC, SPF, and DKIM, properly aligned with a published reject policy, prevent attackers from spoofing emails that appear to come from your firm's own domain. Most firms publish DMARC but leave it at p=none — p=reject is the only setting that actually prevents spoofing. A firm that has enforced DMARC at reject policy has removed the entire class of header-spoofing attacks that make the sending domain appear legitimate. This is the single highest-leverage technical control available.
**Out-of-band confirmation as standing policy.** Wire instructions should never be acted upon on the basis of email alone. This is not a new concept — but it needs to be a written, enforced policy rather than a professional norm that erodes under deadline pressure. The policy should be communicated explicitly to all counterparties at engagement, so that legitimate parties understand the verification call is coming and are not surprised by it.
**Domain monitoring for your own firm.** Services like DNSTwist or Recorded Future can monitor domains resembling a firm's brand in real time, and certificate transparency logs can identify rogue SSL certificates indicating malicious activity. A firm that discovers a lookalike domain targeting its clients can issue a proactive warning before any fraudulent message has reached its intended recipients.
**Pre-established communication channels.** Every multi-party transaction should begin with a documented, verified contact sheet: each party's domain, direct phone number (captured from a source independent of email), and designated point of contact. BEC attackers frequently use social engineering to build trust and urgency, posing as buyers, sellers, realtors, or brokers requesting a change in payment instructions, and leveraging fear, time pressure, or confidentiality to override normal verification processes. A pre-established contact sheet removes the attacker's ability to present alternate contact details as authoritative.
## The structural problem with traditional payment rails in multi-party deals
Domain spoofing in payment requests is a fraud problem — but it is also a visibility problem. The fundamental reason these attacks succeed at scale is that the mechanics of traditional wire settlement create a long window of vulnerability during which payment details are transmitted, confirmed, and re-confirmed through email threads. Every round-trip message in that process is an opportunity for interception or impersonation.
In a typical multi-party closing, there is a 30-to-60-day window of email traffic crossing multiple parties — buyer, seller, both agents, lender, title, closing attorney — with a time-pressured wire instruction arriving near the close. That is weeks of exposed email surface, multiple parties each representing an entry point, and a final high-stakes disbursement moment that concentrates all the pressure into a single instruction exchange.
Operational reversals may be common in ACH or card networks, and even high-value real-time gross settlement systems can unwind transfers under specific legal circumstances. This reversibility, which might seem like a safety feature, is also what gives attackers time to extract funds through secondary hops before the fraud is detected. By the time the incorrect wire is flagged and a reversal is attempted, the funds have moved again.
In traditional payment systems, reversals can be initiated by a central operator, a court order, or a back-office correction — whereas technical finality on blockchains produces an economic guarantee that is stronger than centralized ledgers, because reversal requires supermajority validator control and incurs massive economic penalties. Onchain payment settlement, properly structured, transforms the window of vulnerability. When the disbursement itself is settled through a verified, transparent on-chain transaction, the destination address is not transmitted in a mutable email thread — it is encoded in a pre-agreed, publicly verifiable smart contract structure.
## Where onchain routing changes the risk profile
The specific vulnerability that domain spoofing exploits — the gap between a payment instruction transmitted over email and the actual disbursement of funds — does not exist in the same form when settlement is handled through a properly structured onchain routing mechanism.
This is the context in which shaka.deal is relevant to settlement professionals, closing attorneys, OTC desks, and brokers who are serious about eliminating wire-redirect fraud from their transaction workflows. Shaka.deal is a non-custodial onchain payment router built on Ethereum. It does not hold funds. It routes one incoming payment and distributes it simultaneously to every party at preset, agreed-upon wallet addresses — all in a single transaction, with immediate finality.
The critical structural difference is this: the destination addresses for each party in a multi-party settlement are encoded in the routing configuration before the payment is initiated, not transmitted in a last-minute email thread. There is no "updated wire instruction" to deliver. There is no payment request to spoof. The attacker's primary insertion point — the moment at which a new bank account number is introduced through a spoofed email domain — simply does not exist in the workflow.
With on-chain payments, the transfer, verification, and settlement all happen in one place, making the process near-instant. For a title company, OTC desk, or settlement agent who has established the routing shares with all parties at the outset of a transaction, the disbursement event is not a wire instruction that must be communicated, confirmed, and executed through an email chain. It is a pre-agreed split executed in one atomic transaction, visible on the public ledger, with no mutable step in between.
Blockchain finality is locked in by shared economic incentives and distributed validation, making unauthorized reversals a prohibitively costly act. That permanence is not a limitation — it is the guarantee. When settlement professionals and their clients know that the routing configuration was agreed upon, verified, and encoded before the payment window opened, the entire class of last-minute wire instruction attacks becomes structurally impossible within that workflow.
Shaka.deal does not replace the settlement professional. The attorney still closes the deal. The escrow officer still manages the transaction. The title company still performs its work. Shaka handles the one moment where email-transmitted payment instructions have historically been the single greatest point of fraud exposure: the moment the money moves.
## Integrating domain hygiene into a fraud-resilient workflow
The goal of everything in this article is not to make professionals paranoid — it is to make fraud structurally harder to execute by closing the specific gaps that attackers rely on.
A resilient payment workflowFor a multi-party transaction
At engagementVerify the domain of every counterparty directly, through independent channels. Record it. Record a verified phone number for payment confirmation. Document the share structure for disbursement.
During the transactionApply the domain inspection protocol to every inbound message that touches payment details. Do not read display names alone. Check registrable domains. Verify reply-to fields.
At disbursementConfirm wire instructions through a pre-established phone number only. Issue a standing policy statement to all parties that instructions will not be changed by email. Where the transaction structure permits, use an onchain routing mechanism such as shaka.deal to encode the disbursement configuration before the payment window opens, removing the email instruction step entirely.
After disbursementMaintain transaction records that include the verified contact information for each party and the domain audit trail from the transaction — useful both for internal review and for any future dispute resolution.
The defense has to be process, not detection — the question is not whether a paralegal can spot the fake email; it is whether the process makes the fake email harmless. That is the right framing. Domain spoofing will continue to evolve. AI-generated content has already made fraudulent emails harder to distinguish from legitimate ones by tone and vocabulary alone. Fraud in 2026 may not be more common, but it has become more sophisticated, more accessible, and more personalized at unprecedented scales.
The countermeasure is not sharper eyes alone. It is a workflow in which the attacker's insertion points have been systematically closed — through technical email controls, pre-established verification channels, standing policies that cannot be overridden by urgency, and, wherever possible, payment infrastructure that does not route funds through mutable email instructions at all.
Domain inspection skill is still essential. The six techniques in this article — character substitution, subdomain manipulation, TLD swapping, combo-squatting, homograph attacks, and display name spoofing — will appear in payment requests aimed at professionals who handle large transactions, because those professionals are precisely the targets worth the effort. The inspection protocol matters. The organizational controls matter. And the structural shift toward onchain routing that removes the mutable instruction step from the payment workflow matters most of all.
For settlement professionals who manage multi-party disbursements and want to see how pre-set share routing on Ethereum removes the wire-redirect attack surface entirely, shaka.deal is where that conversation starts.