7 Sep 20266 minutes read
Waseem OsmanDMARC EnthusiastImpersonation Attack Types: Mapping Vectors to Controls

Impersonation attack types overview:
- Naming determines response and reporting.
- DMARC only covers what claims your domain.
- Compromised accounts pass authentication, so behavior and verification matter most.
- Display name spoofing is social engineering, not a technical exploit.
- No single control covers every vector.
Suppose your CFO receives an urgent wire transfer request that appears to come from your CEO. The address looks right, and nothing about the message stands out as suspicious. That's the problem: the sender looks legitimate, but it could be a compromised executive account, a lookalike domain, or a spoofed display name.
Each of those sends your incident-response team down a different path. Get the classification wrong, and a two-hour investigation turns into a two-week one.
Precise naming is not a matter of semantics. In enterprise environments, the word you use to classify an attack determines which control you test first, which team owns the response, and how you report the incident to your board.
This post maps the main impersonation attack types, explains how each one evades or bypasses common email defenses, and connects each vector to the specific technical controls that actually stop it.
Why Naming Matters in Incident Response
When a suspicious email lands in a finance director's inbox, your security operations team faces a classification question: is this a spoofed domain, a lookalike domain, a compromised supplier account, or an impersonated display name? Each scenario has a different owner and a different remediation path.
A spoofed domain triggers a DNS investigation. A lookalike domain triggers a brand protection and legal takedown workflow. A compromised account triggers a supplier investigation. Display name spoofing triggers a verification response.
These are not interchangeable.
Senior security leaders presenting to risk committees or audit functions need a working vocabulary for these impersonation attack types locked down before an incident occurs, not during one.
The Four Primary Impersonation Attack Types
1. Direct Domain Spoofing
Direct domain spoofing uses your exact domain (example.com) in the “From” header of an email.
This is the vector DMARC was built to block. A p=reject policy, backed by SPF and DKIM alignment, tells receiving servers to reject any message that fails authentication.
Spoofing succeeds when full enforcement is missing: the domain's DMARC record is absent, set to p=none (monitoring), or set to p=quarantine.
By default, subdomains inherit the same policy as your root domain: a p=reject policy extends automatically to marketing.example.com or invoices.example.com, but an explicit sp= (subdomain policy) tag can override it with something weaker.
Detection and prevention:
- Enforce a DMARC policy of p=reject on root domains and all subdomains
- Monitor DMARC aggregate reports for unauthorized sending sources
2. Lookalike Domain Attacks
A lookalike domain is a domain registered by an attacker that resembles your brand. Common techniques include character substitution, added words, or Cyrillic characters and homoglyphs.
The attacker's messages claim to come from the lookalike domain, not yours, so your DMARC policy doesn't matter. It has no authority over a domain you don't own. This is why organizations that believe they've solved impersonation risk by enforcing DMARC often remain exposed to this class of attack.
The operational impact is significant. Finance teams, suppliers, and customers might receive emails from example-billing.com that look legitimate, contain plausible context, and pass authentication checks. Defending against a lookalike domain requires a detection and takedown capability that monitors for newly registered domains mimicking your brand.
Detection and prevention:
- Continuous monitoring for newly registered lookalike domains
- Automated takedown workflows for domains actively used in phishing campaigns
- Internal awareness for finance and procurement teams
3. Compromised Accounts
With a compromised account, the attacker doesn't spoof your domain or register a lookalike domain. They compromise a real account - one of your suppliers, partners, or counterparties - and send emails from that account.
The message comes from a domain you recognize and passes SPF, DKIM, and DMARC. It's technically authentic: it came from a legitimate account, and that authenticity is exactly what makes this vector so effective in business email compromise (BEC) attacks.
The attacker compromises an accounts-payable contact at a supplier, monitors email threads for months, and then steps in at a moment of high value, such as a pending invoice or a contract renewal, to redirect the payment.
Your email gateway won't block this. Your DMARC policy won't block this. The message is, from a technical standpoint, entirely valid.
Detection and prevention:
- Behavioral analysis: Anomalies in sending time, IP geolocation, message volume, or writing style
- Payment verification controls: Independent confirmation of bank account changes through phone or a separate secure channel, never by replying to the same email thread
- Identity threat detection: Monitoring for credential exposure across your domain portfolio
4. Display Name Spoofing
This attack often doesn't use your domain at all. The attacker registers a free or low-cost email account ([email protected]) and sets the display name to match your CEO's name. Many email clients show the display name prominently.
DMARC isn't directly relevant here because the attacker isn't using your domain. The attack succeeds through social engineering, not technical compromise: it exploits the display name and the tendency of recipients to trust names they recognize.
Detection and prevention:
- Email gateway rules: Flag external emails where the display name matches an executive
- BIMI adoption: Train recipients to look for verified brand logos
- Verification procedures: Verify urgent financial instructions from executives directly
Mapping Controls to Impersonation Attack Types
No single control covers every vector.
- DMARC at p=reject blocks direct domain spoofing of your owned domains
- Lookalike domain monitoring addresses the vector DMARC cannot reach
- Behavioral analysis surfaces anomalies that authenticated accounts can still produce
- Identity threat detection monitors for credential exposure that leads to compromised accounts
- BIMI provides visual trust signals that help recipients identify authentic emails from your domain
- Payment verification procedures are the final check no technical control can replace
How Sendmarc Helps
Sendmarc gives enterprise security and risk teams the visibility and controls needed to address multiple impersonation attack types from a single platform.
DMARC Management covers domain-level authentication across root domains, subdomains, and inactive domains in your portfolio, reducing the manual investigation load on stretched security and IT teams. Lookalike Domain Defense surfaces newly registered domains mimicking your brand before they're weaponized.
Breach Detection provides credential exposure detection that reduces the window between a supplier or employee account compromise and detection. For risk and compliance teams, Sendmarc produces reporting that maps authentication status by domain, structured to support board presentations, committee updates, and audit documentation.
Sendmarc also supports BIMI implementation once your domain reaches enforcement, so your verified logo is displayed in supporting inboxes as an added visual trust signal.
This gives stretched security and IT teams continuous coverage against direct spoofing and lookalike domain threats without adding to their workload, and gives compliance and audit functions a credible record to demonstrate to regulators and boards.
Explore the Sendmarc Platform to see how DMARC Management, Lookalike Domain Defense, Breach Detection, and BIMI work together to cover the impersonation attack types this post maps.



Leave a reply Cancel reply
Your email address will not be published. Required fields are marked *