Spoofing vs. Impersonation: Why Mixing Them Up Breaks Your Playbook

The alert fires. It’s a high-confidence Business Email Compromise (BEC) attempt flagged by your secure email gateway. The sender appears to be your CFO, the subject is 'Urgent Q3 Wire Transfer Adjustment', and the recipient is a junior accounts payable clerk.

Your IR playbook is clear: first, verify the email authentication. You pull the headers and check the `Authentication-Results` field. You see `dmarc=pass`. The email is authentic. Now what?

This is the moment where most playbooks fall apart. The team declares it a false positive or gets tangled in knots trying to explain how a message can be both authentic and malicious. The problem isn't the alert or the playbook; it's the vocabulary. Your CFO wasn't spoofed. They were impersonated. And that difference changes everything.

Spoofing is Forgery, and We Have Protocols for That

Let's be precise. Email spoofing, in the technical sense that matters for infrastructure, is the act of forging the `From:` header (specified in RFC 5322) of an email. The attacker constructs a raw SMTP message and places an address they don't own—like `cfo@yourcompany.com`—into that visible From field. Their goal is to make the message appear to originate from a trusted internal source.

This is a direct assault on email's core trust model. For decades, it was trivial to do. Today, it’s much harder, thanks to three key standards that work in concert: SPF, DKIM, and DMARC.

The Authentication Trio: SPF, DKIM, and DMARC

Sender Policy Framework (RFC 7208) is a DNS record that declares which IP addresses are authorized to send mail for a domain. When a receiving mail server gets an email, it checks the connecting IP against the SPF record of the domain found in the SMTP `MAIL FROM` command (the envelope sender). If the IP isn't on the list, SPF fails.

DomainKeys Identified Mail (RFC 6376) uses public-key cryptography. The sending mail server signs parts of the email—including the `From:` header and the body—with a private key. The corresponding public key is published in DNS. The receiver can fetch this key, verify the signature, and be confident that the message hasn't been altered in transit and was sent by an authorized server. A mismatch in the body hash, often caused by mailing list footers or anti-virus scanner additions, is a classic DKIM failure mode.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489), or DMARC, is the policy layer that ties them together. It tells receivers what to do if SPF or DKIM checks fail. More importantly, DMARC introduces the concept of 'alignment'. It's not enough for SPF or DKIM to simply 'pass'. The domain used for the SPF (`MAIL FROM`) or DKIM (`d=` tag in the signature) check must *align* with the domain in the visible `From:` header. A true spoof of `cfo@yourcompany.com` sent from an attacker's server will fail this alignment check, triggering the DMARC policy—ideally `p=reject`.

Authentication-Results: mta.example.net; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourcompany.com

Impersonation is Deception, and Authentication Passes

If spoofing is forgery, impersonation is a con game. The attacker isn't trying to break the authentication system; they're trying to fool the human who's reading the email. All the underlying technical signals can be perfectly valid, resulting in that confusing `dmarc=pass` result that stalls your investigation. Impersonation comes in several flavors, but two are rampant.

Display Name Deception

This is the most common and lowest-effort tactic. The attacker registers a generic email account and sets the display name to that of the target. The `From:` header looks like this:

From: "CFO Name" <urgent-fin-request-8921@somefreemail.com>

Most email clients, especially on mobile, will only show "CFO Name". The actual sending address is hidden behind a tap. From a protocol perspective, everything checks out. The email from `somefreemail.com` passes SPF and DKIM for that domain, so it also passes DMARC. The authentication systems did their job perfectly. They authenticated the *sender*, `somefreemail.com`. The security failure is a human factors problem, not a protocol one.

Cousin and Lookalike Domains

This is a more sophisticated version of impersonation. The attacker registers a domain that looks visually similar to yours. Think `your-c0mpany.com` (with a zero) or `yourcompanys.com` (plural). They then set up valid SPF and DKIM records for this malicious domain and send the email.

The email arrives from `cfo@your-c0mpany.com`. To the casual observer, it looks legitimate. To the receiving mail server, it also looks legitimate. The SPF and DKIM checks are performed against `your-c0mpany.com`, and since the attacker controls that domain, they pass. DMARC alignment also passes, because the domain in the `From:` header matches the domain authenticated by SPF/DKIM. Again: `dmarc=pass`. The system is working as designed, but you are still under attack.

Matching the Control to the Threat

Confusing these two threats leads to catastrophic control choices. You can't fix an impersonation problem by tightening your DMARC policy, and you can't stop a direct spoof by only looking for display name anomalies.

Fighting Spoofing Is a Technical Mandate

The defense against direct header spoofing is non-negotiable: implement DMARC at `p=reject`. This instructs receiving mail servers to drop any email that claims to be from your domain but fails the alignment checks. It's the single most effective control against this attack vector.

But what about legitimate mail that fails DMARC, like messages from a third-party service or a complex forwarding chain? That’s where the Authenticated Received Chain (ARC), defined in RFC 8617, comes in. ARC preserves the initial authentication results across multiple hops. An ARC-aware receiver can see that the email originally passed DMARC before being forwarded by a server that broke SPF alignment. It allows you to maintain a strict DMARC policy without breaking legitimate mail flows. If your vendors complain that your `p=reject` policy is blocking their mail, the conversation should be about their lack of ARC support.

Fighting Impersonation Requires Heuristics

Since authentication passes for impersonation attacks, you need a completely different set of tools that operate post-authentication. This is the world of advanced threat detection, focusing on intent and context, not just origin.

These controls analyze the content (language of urgency, requests for credentials or financial transactions), sender reputation (has this address or lookalike domain been seen before?), and behavioral patterns (is it normal for the CFO to email this clerk directly?). They look for cousin domains, mismatches between display names and sending addresses, and other signs of social engineering. This is where your secure email gateway (SEG) proves its worth—not by checking DMARC, but by applying these complex, stateful heuristics.

How You Report an Incident Defines the Fix

When you debrief an incident, the language you use has consequences. It sets the direction for remediation and demonstrates your team's competence.

If you report that 'the CFO was spoofed' when it was a cousin domain attack, you will face a logical question from leadership: 'I thought our DMARC project was supposed to prevent that?' You then have to awkwardly walk back your statement, explaining that authentication actually passed. This undermines credibility and confuses stakeholders. It sends the infrastructure team on a wild goose chase, re-checking DNS records that were never the problem.

But if you report that 'we blocked a CEO impersonation attempt using a lookalike domain,' the path forward is clear. The remediation isn't about DMARC. It's about tuning the SEG to be more aggressive on cousin domain detection, exploring a brand protection service that monitors for typo-squatting registrations, and delivering targeted training to the finance department on this specific tactic. The problem is correctly scoped, and the solution is relevant.

The takeaway

Knowing the difference between a spoof and an impersonation isn't just pedantic email nerdery. It's the fundamental branching point in an investigation. One path leads down a rabbit hole of authentication protocols, RFCs, and DNS records. The other leads into the murkier, more human world of social engineering, behavioral analysis, and deception.

The analyst who can stand up in a debrief and state with confidence, 'This wasn't a spoof, it was a display name impersonation, and that's why DMARC passed,' is the analyst who drives real security improvements. They aren't just closing a ticket; they are precisely identifying a control gap. Tools that visualize these header relationships and flag the specific type of deception, like MailSleuth.AI, make that critical first step immediate and clear.