Spoofing vs. business email compromise: two distinct threats

Three terms, three scopes — and none that covers the whole

The problem is that each of these terms names a different portion of the threat, and none covers it entirely.

• "CEO fraud" names a single scenario: the impersonation of a company director. It leaves out the fake supplier invoice, which is in fact the most frequent variant by volume, and payroll redirection fraud.
• "Business email compromise" suggests the mailbox itself has been broken into. That is sometimes true — but it is the rarest of the three vectors. The term describes the exception as though it were the rule.
• "FOVI" retains only the financial outcome, and by construction excludes variants that target data rather than a payment.

This imprecision carries a direct operational cost. It suggests a single countermeasure will do: that deploying DMARC closes the subject, or that training the finance team closes it just as well. Both claims are false taken in isolation, and the second is more dangerous than the first, because it is harder to measure.

The three vectors, and the one DMARC stops

An attack in this family takes one of three paths. DMARC treats them radically differently, and that is the point the vocabulary confusion obscures.

First vector — the spoofed domain. The attacker sends from an address displaying exactly the legitimate domain. This is spoofing in the strict sense, and DMARC at enforcement stops it. The message fails alignment and is rejected before reaching the inbox. No human vigilance is called upon, because nothing arrives.

Second vector — the lookalike domain. The attacker registers a visually similar domain, then publishes their own SPF and DKIM records on it. The message is perfectly authenticated — for that domain. DMARC does not refuse it, and has no reason to: the protocol verifies that a sender is entitled to write on behalf of the domain it announces, not that the domain resembles another. Defence here rests on monitoring nearby registrations, covered among the priorities for protecting against impersonation.

Third vector — the genuinely compromised account. The attacker holds credentials to a legitimate mailbox, often obtained through earlier phishing or by replaying a password leaked elsewhere. The message leaves authorised infrastructure, signed with the correct keys, from the correct domain. SPF passes, DKIM passes, DMARC passes — because the send is authentically legitimate. The protocol works exactly as designed; it is the account that no longer is.

This third case is the one that gives the whole family its English name, while constituting its minority. Its defence belongs not to domain authentication but to access hygiene: multi-factor authentication on exposed mailboxes, detection of anomalous sign-ins, and centralised secrets management rather than credentials scattered across configuration files and chat channels. A dedicated vault such as Hucency Vault, published by cybersecurity specialist Hucency, addresses that need by placing credentials and tokens under controlled, logged access.

Telling the three apart after an incident

The distinction is not merely conceptual: it determines the response. And the three vectors leave different traces, which makes them separable after the fact.

A spoofed domain shows up in DMARC aggregate reports as a failing source — an IP address sending on behalf of the domain without passing alignment. That is the vector aggregate reporting was designed to reveal — with one condition that the phrase “just read the reports” glosses over: the collection has to exist in the first place. Without a rua tag published in the DMARC record, and without receivers willing to emit reports, the attempt leaves no readable trace. Diagnostics name this case explicitly: a domain with a published policy but no returning reports is blind to its own impersonation.

A lookalike domain leaves no trace whatsoever in those reports, for the simple reason that it is a different domain: its own reports go to whoever registered it. Detection depends on watching registrations, or on the message itself once a recipient forwards it. The header trail then shows a domain that authenticates cleanly but is not the one it imitates — which is why reading the headers of a suspect message settles the question faster than any amount of speculation about the sender.

A compromised account is the hardest of the three to spot from the mail layer alone, precisely because everything it produces is valid. The signals live elsewhere: an unusual sign-in location, a mailbox rule created to hide replies, an outbound message with no corresponding item in the sender's own sent folder. Aggregate reports will show the send as a legitimate, aligned one — because it is.

The practical consequence is that an organisation seeing a fraud attempt should not assume its DMARC posture failed. In two cases out of three, the posture worked exactly as specified and the attack simply did not go through the door it guards.

What the distinction changes for a domain already at p=reject

The finding is uncomfortable but better stated plainly: a DMARC policy at p=reject closes one vector out of three. That is considerable — it is the easiest vector to exploit, the cheapest for the attacker, and the one that enables large-scale campaigns. Closing it eliminates opportunistic fraud and forces the attacker to invest more.

But the claim "the domain is at p=reject, therefore transfer fraud is handled" does not hold. The other two vectors remain open, and they are precisely the ones a methodical attacker turns to once the first is shut. Deploying DMARC moves the threat upmarket rather than removing it.

Two practical consequences follow. First, organisational defences — two-person approval above a threshold, verification of banking-detail changes through a channel independent of email — are not an optional complement to DMARC: they cover the portion authentication structurally cannot reach. Second, monitoring lookalike domain registrations becomes the natural extension of a completed deployment, since that is where the activity shifts.

One further point deserves noting: warning signs based on clumsy writing have lost their reliability. Generative tools now produce messages in impeccable prose, modelled on the public style of the person being impersonated. The signals that survive are structural — urgency, confidentiality, an explicit request to bypass a procedure — because they are inherent to the fraud itself: style can be polished indefinitely, the request cannot be withdrawn.

The reverse does not hold either: not all spoofing targets a payment

A large share of spoofing has nothing to do with transfer fraud: generic phishing campaigns sent to tens of thousands of recipients to harvest credentials, brand impersonation for the purpose of damage, malware distribution under cover of a known sender.

These uses share the same technique and call for the same countermeasure — domain authentication — but belong to a different economy: volume rather than targeting. An unprotected domain suffers them without any transfer ever being requested, and the harm is measured instead in sender reputation and degraded deliverability for legitimate mail.

Two layers, two treatments

Restoring these notions to their proper scope produces a legible defence architecture. Spoofing is handled at the technical layer, through domain authentication, and that treatment is objectively verifiable: a published policy, measured alignment, aggregate reports confirming the outcome. Business email compromise is handled at the organisational layer, through validation procedures that depend on no trust granted to any message.

Neither layer makes the other redundant. The first eliminates mass fraud and makes the second more costly; the second covers what the first cannot see. Defining them precisely, as the email authentication glossary does, is the prerequisite to any sensible investment decision on the matter.

The state of the first layer can be established immediately: running the domain through a free DMARC analyzer reveals the published posture — DMARC policy, SPF record, detected DKIM selectors. The check reads DNS, and DNS alone: the sources actually sending on the domain's behalf only become readable in aggregate reports, once collection is in place. The resulting posture then compares against the sector in the DMARC Observatory. The second layer cannot be measured from outside — it is audited internally, and that is often where the widest gap turns up.