One Hyphen From Trusted: A Lookalike-Domain Vendor Impersonation That Beat the Eye and the Authentication Stack

TL;DR An attacker registered a lookalike of a known supplier's domain, used the exact display name of a contact the recipient knew, and sent a routine-sounding sales pitch. SPF, DKIM, and DMARC all passed because the message was genuinely sent from the lookalike domain through a Gmail-API sales tool. DMARC was set to p=none, so there was no enforcement. The displayed link text mimicked the lookalike string while the href pointed elsewhere, and scanning flagged it malicious. Only behavioral and relationship analysis caught the one-character gap that human recognition missed.
Severity: High Vendor Email Compromise Impersonation Phishing MITRE: T1656 MITRE: T1583.001

A manufacturing engineering staffer opened an email from a supplier contact they already knew. The display name was exact. The pitch was routine: lower your beveling costs, can we grab a short call. The signature carried a title, a phone number, a street address, and a company website. Nothing about it raised a hand.

The sender's domain was one hyphen off the real one.

That single character is the entire attack. This is vendor email compromise (VEC), a targeted impersonation in which an attacker exploits the trust between an organization and one of its suppliers. What makes this case worth a teardown is not the lure, which was unremarkable, but how cleanly it slipped past every control built to stop it: authentication passed, the policy that should have enforced was disarmed, and the only thing standing between the recipient and a foothold was analysis of the relationship itself.

The contact was real, the domain was not

The legitimate supplier exists. It has a real, established domain registered back in 2016, a real business address, and a contact the recipient had corresponded with before. The attacker did not compromise any of that. They rebuilt it.

In a single registration batch, the attacker stood up two lookalike domains: one hyphenated near-miss of the supplier's name used as the sending and reply-to address, and a second non-hyphenated variant used to mirror the known contact's identity. Both were registered the same day through GoDaddy with WHOIS privacy, both on one-year terms, both with unsigned DNSSEC. They were nine years younger than the domain they imitated.

The message then borrowed the contact's exact display name and pointed everything back toward the supplier's real website, so a recipient who clicked through landed on a genuine-looking page. The deception lived entirely in the From line. The eye reads a familiar name and a familiar-looking domain and stops there. It does not diff strings.

How the message was built and sent

The headers show this was not a one-off. Embedded campaign, sequence, step, and outbox identifiers reveal the message was generated by a cold-email sales-engagement platform and delivered through the Gmail API over an authenticated HTTP request. The attacker was running the lookalike domain through commodity outreach tooling, the same automation a legitimate sales team would use.

That tooling is why the authentication came back clean. Because the attacker actually owned the lookalike sending domain and had published valid records for it, the message earned legitimate signatures.

This maps to two MITRE ATT&CK techniques. Acquire Infrastructure: Domains covers the deliberate registration of the lookalike domains ahead of the campaign. Impersonation covers the exact display-name match used to borrow the supplier contact's identity. The same playbook drives the broader vendor email compromise category, where the trust being abused belongs to a third party the victim already does business with.

Authentication passed, enforcement was switched off

Here is the uncomfortable part. SPF (Sender Policy Framework, which checks whether the sending server is authorized) passed. DKIM (DomainKeys Identified Mail, which cryptographically signs the message) passed, signed by the lookalike domain itself. DMARC (Domain-based Message Authentication, Reporting and Conformance, which ties the two together and tells receivers what to do on failure) passed as well, with composite authentication scoring a perfect result.

None of that means the message was safe. Authentication answers one question: was this sent from infrastructure authorized for the From domain. When the attacker controls the From domain, the answer is yes. The checks never compare the lookalike against the supplier's real domain, so the one-character gap is invisible to them.

The lookalike's DMARC policy was set to p=none, monitor-only. Even in a world where alignment had failed, p=none instructs receivers to take no enforcement action. The attacker chose a policy that guarantees delivery. Proper DMARC management and monitoring hardens your own domain against being spoofed, but it cannot reach into an attacker-owned lookalike and turn enforcement back on.

The link did not go where it said

The body carried a link whose displayed text mimicked the lookalike domain string, while the actual destination resolved elsewhere. Link scanning flagged the elements malicious on exactly that displayed-versus-destination mismatch. A recipient reading the visible text would never see the divergence; scanning compared the two and caught it.

This is the practical lesson for business email compromise protection: when the sender is unblockable because authentication is genuine, the defensible layers are the link destination and the relationship history.

Indicators of compromise

TypeIndicatorContext
Domainhxxps://precision-bevelus[.]comAttacker lookalike, sending and reply-to domain, registered 2025-08-21
Domainprecisionbevelinc[.]comSecond attacker lookalike registered the same day, used to mirror the known contact identity
Emailiantonow@precision-bevelus[.]comSpoofed-display-name sender on the lookalike domain
BehaviorExact display-name match from a new domainKnown contact name arriving from a domain the contact never used
BehaviorDisplayed link text vs href mismatchLink elements flagged malicious by scanning
AuthSPF pass, DKIM pass, DMARC pass (p=none)Genuine authentication on attacker-owned domain, no enforcement

What actually caught it

Authentication cleared the message. The recipient's eye cleared it too. What flagged it was relationship analysis: the system already knew this contact from the supplier's real domain, recognized that an exact display-name match was now arriving from a domain that contact had never used, and weighed that against community reputation and the malicious link verdict. That behavioral comparison is the layer that survives when SPF, DKIM, and DMARC all say yes.

The industry data backs the priority. Verizon's 2026 Data Breach Investigations Report puts the human element in 62 percent of breaches and phishing in 16 percent of initial-access cases. The FBI's IC3 2024 report continues to rank BEC and vendor fraud among the costliest categories by reported losses, a pattern the FTC Consumer Sentinel Network echoes in its fraud tallies. Microsoft's 2024 Digital Defense Report documents the same shift toward identity and impersonation over malware. CISA's guidance on recognizing and reporting phishing reinforces the operational fix: verify a payment or relationship change through a known channel, never the one in the message.

See Your Risk: Calculate how many threats your SEG is missing

A secure email gateway (SEG) inspects content and reputation, but a genuinely authenticated message from an attacker-owned domain gives it little to fault. IRONSCALES data shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes each month, and lookalike VEC is precisely the gap. The defense is not a better signature check. It is knowing which domain your supplier actually emails from, and noticing the moment a familiar name arrives from a new one.

Verify the relationship, not just the headers. The attacker counted on you reading the name and skipping the hyphen.

Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 35,000+ security professionals. Each post breaks down a real attack. What it looked like, why it worked, and what to do about it.

Related attacks

Attack What happened
The GitLab Alert That Passed Every Filter (Except One Detail Nobody Checked)A GitLab sign-in alert cleared Proofpoint URL Defense and passed SPF/DMARC — then listed a private RFC1918 IP as the sign-in source.
Microsoft Bookings as a Weapon: When DMARC Says Trust Me and ARC Quietly DisagreesA phishing email sent from bookings.microsoft.com passed every authentication check.
The Timestamp That Gave It Away: Oracle Identity Cloud Phishing Targets K-12 with a Stale TimezoneA phishing email impersonating Oracle Identity Cloud targeted a Florida school district employee.
The Phishing Simulation Platform That Powered a Real AttackA salary adjustment lure routed through SendGrid and a Carrd landing page used phishing kit images hosted on a commercial phishing simulation vendor's own...
DocuSign Lure, Diverted Replies: How Reply-Path Manipulation Turns a Legitimate Envelope Into a BEC TrapAn authenticated DocuSign notification arrived with its Reply-To silently diverted to an external attacker-controlled domain.

Explore More Articles

Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.