CEO Fraud Explained: Why Publishing DMARC Is Not Enough

Published 2026-08-21

CEO fraud is a business email compromise scam in which a criminal, posing as your chief executive or another senior leader, emails an employee — usually in finance — with an urgent request to move money or change payment details. The dangerous myth is that publishing a DMARC record protects the executive’s domain from being impersonated. It often does not. The August 2026 defaults.exposed census found that of every domain publishing a DMARC record, 53.6% — 40,541,896 domains — sit at p=none: the record is published, a checker shows it green, and yet a receiving mail server has been told to take no action on forged mail. The CEO’s own domain is exactly as spoofable as one with no record at all. Only 9.3% of all graded domains enforce DMARC, and only 2.9% carry the full SPF, DKIM and DMARC stack. This guide explains how CEO fraud works, why a published policy is not a protective one, and how to check whether your executive’s domain can be impersonated.

If your organisation “has DMARC,” the natural assumption is that no one can send email as your CEO. That assumption is wrong far more often than it is right, because publishing a DMARC record and enforcing one are two different states — separated by a single tag that most people never read. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

What is CEO fraud, and why is it the costliest BEC variant?

CEO fraud — also called executive impersonation, or “whaling” when the impersonated party is a senior figure — is a specific play within the broader category of business email compromise (BEC). The attacker does not hack the CEO’s mailbox. They do not need to. They send an email that appears to come from the CEO, aimed at someone with the authority to move money or reveal sensitive data, and they rely on rank and urgency to bypass the recipient’s judgement.

It is the costliest BEC variant for three reasons that compound each other:

Authority short-circuits scrutiny. An instruction that appears to come from the top of the organisation is questioned far less than the same instruction from a peer. Junior staff are conditioned not to second-guess the boss.
Urgency removes the pause. The request is always time-critical — a deal closing, a supplier threatening to walk, a confidential acquisition. The pressure is designed to stop the recipient from picking up the phone to verify.
The amounts are large and the path is one-way. CEO-fraud requests are wire transfers, not invoice payments — often five or six figures — and once the money lands in the criminal’s account and is moved on, it is rarely recovered.

CEO fraud sits inside the BEC family alongside vendor invoice fraud and payroll-diversion scams. For the umbrella definition, the taxonomy of BEC variants, and the losses across all of them, see What Is Business Email Compromise: Inside the 90.7% Spoofing Gap. This article stays in one lane: the executive-impersonation variant, and the false comfort that a published DMARC record gives the people most likely to be impersonated.

Anatomy of a CEO-fraud attack: the urgent wire request

Every CEO-fraud attempt follows the same shape, because the shape works. Understanding the sequence is the first defence, because each stage is an opportunity to break the chain.

Reconnaissance. The attacker identifies the CEO’s name and email address — trivially available from a website, a press release, or LinkedIn — and identifies a target in finance who would plausibly act on a payment instruction. Public DNS is part of this reconnaissance: an attacker queries the domain’s DMARC record before sending, and a p=none result tells them the domain can be spoofed without the forgery being blocked.
The pretext. The scenario is chosen to justify secrecy and speed: a confidential acquisition, an overdue supplier, a regulatory deadline, a deal that “cannot wait for the usual process.” Confidentiality is the point — it explains why the recipient should not check with anyone else.
The impersonated email. The message arrives, appearing to be from the CEO. It is short, informal, and pressured: “Are you at your desk? I need a payment made urgently before end of day. Can you handle this discreetly?” There is often no attachment and no link — nothing for a security scanner to flag. The payload is the instruction itself.
The escalation. If the target replies, a rapid back-and-forth follows: banking details, an amount, a deadline. The attacker keeps the pressure high and the channel closed, discouraging any move to a phone call or a face-to-face check.
The transfer. The employee initiates the wire. By the time anyone notices the CEO never sent the email, the money has been layered through intermediary accounts and is gone.

Because the payload is a plain-text instruction with no attachment or link, spam filters and malware scanners have little to catch. That shifts the burden onto two things: the domain’s authentication posture, and the recipient’s ability to spot the pattern. A CEO-fraud email tends to carry a recognisable cluster of signals:

A pressured, time-boxed request — “before end of day,” “right now,” “urgently” — designed to prevent verification.
An appeal to confidentiality — “keep this between us,” “don’t loop in the team” — which conveniently removes the second pair of eyes.
A money or data action — a wire transfer, a change of bank details, a batch of gift cards, or a request for payroll or W-2/tax data.
A subtle channel shift — a reply-to address that differs from the visible From, or a nudge to continue on personal email or text.
Tone that leans on rank — brief, informal, and framed so that questioning it feels like questioning the boss.

The single technical enabler that makes stage 3 land in the inbox — rather than the spam folder or nowhere at all — is the domain’s email-authentication posture. If the domain enforces DMARC, a message forging the exact executive address is rejected before delivery. If it does not, the forgery arrives looking authentic. That posture is what the census measures, and what most organisations get wrong.

Exact-domain spoofing vs look-alike domains: how the fake “CEO” email lands

There are two ways to make an email appear to come from the CEO, and they call for different defences. Confusing them is why many organisations believe they are protected when they are not.

Exact-domain spoofing forges the real domain. The From header reads [email protected] — the genuine address, character for character. This is only stopped by email authentication: an enforcing DMARC policy on yourcompany.com instructs receiving servers to reject any message that fails SPF and DKIM alignment for that domain. If the policy is p=none, or absent, exact-domain forgery is delivered. This is the attack DMARC exists to stop, and the attack a p=none record fails to stop. The mechanics of how a message passes SPF for the wrong domain while displaying yours are covered in Email Spoofing Explained: Why 90.7% of Domains Can Be Forged.

Look-alike domains register a similar but different domain — yourcompany-finance.com, your-company.com, or a lookalike using visually confusable characters. The From address is not your domain at all, so your DMARC policy is irrelevant to it; these are defended by user vigilance, display-name scrutiny, and separately by monitoring for newly registered lookalikes.

The two are often conflated into “someone can pretend to be our CEO,” but they demand different controls. This article — and the census data behind it — concerns the first kind: the forgery of the genuine executive domain, which is a solved problem in theory and an unsolved one in practice. The reason it stays unsolved is that most domains publish a DMARC record and then stop one tag short of enforcing it.

A related subtlety: even a domain that enforces DMARC on the parent can leave a back door open on its subdomains. A record of p=reject with sp=none protects yourcompany.com while leaving billing.yourcompany.com and finance.yourcompany.com freely spoofable — addresses a CEO-fraud email could plausibly use. The census found 1.3 million domains carrying exactly this subdomain back door, measured in DMARC Subdomain Policy: 1.3 Million sp= Back Doors.

The false comfort of DMARC: 53.6% publish p=none and stay spoofable

Here is the finding that should reframe how any executive thinks about their own domain.

Of the 376,928,750 domains graded in the August 2026 census, only 20.0% — 75,571,248 — publish any DMARC record at all. That already means four in five domains have nothing. But the more revealing number is what the publishers chose. Of those 75.6 million domains that went to the trouble of publishing a DMARC record, 53.6% — 40,541,896 domains — set the policy to p=none.

p=none is monitor-only. It instructs receiving mail servers to take no action on forged mail: deliver it as normal, and merely send back a report. A domain at p=none can be spoofed exactly as freely as a domain with no DMARC record whatsoever. The difference is purely that the owner believes they are protected, because a checker showed a valid record and the check stopped there.

This is the false-comfort trap, and it is worst precisely where it matters most. An organisation deploys DMARC, sees the record go live, ticks the box, and tells the board that executive impersonation is handled. Meanwhile the policy that would actually block a forged [email protected] email — p=quarantine or p=reject — was never switched on. More than half of all DMARC deployments in the world are stuck at exactly this stage.

Pulling back to the full population makes the scale plain:

90.7% of all graded domains — 341,945,132 — have no enforcing DMARC policy. They publish nothing, or they publish p=none.
Only 9.3% — 34,983,618 — enforce DMARC with p=quarantine or p=reject, the two values that actually stop a forgery reaching a recipient.
56.8% — 214,276,774 — publish neither SPF nor DMARC, so there is not even a partial posture to lean on; that population is profiled in The Silent Domain.

The p=none majority is not a failure of intent — it is a failure of finishing. p=none is the correct first step of a DMARC rollout, a listening phase used to confirm which legitimate senders exist before enforcement is switched on. The problem is that for 40,541,896 domains, the listening phase became the destination. The record was published, the project was marked done, and enforcement never followed. To read whether a given record actually enforces, tag by tag, see DMARC Checker: How to Read Your Record. The grading logic behind the enforcing-versus-published distinction is documented in the DMARC policy methodology.

Only 2.9% of domains are fully protected — is your executive’s domain one?

Enforcing DMARC is necessary, but on its own it is not the whole picture. Full protection against exact-domain impersonation requires three records working together: SPF to declare which servers may send for the domain, DKIM to cryptographically sign outbound mail, and an enforcing DMARC policy to tell receivers what to do when a message fails to align with either.

Across the census, only 2.9% of domains — 10,902,284 — carry the complete SPF, DKIM and enforcing-DMARC stack. That is the true “fully protected against email forgery” population: fewer than three domains in every hundred. Every other domain has at least one leg of the stack missing or non-enforcing — and every missing leg is a way for a forged executive email to survive delivery.

The reason the full stack matters, rather than DMARC alone, is alignment. DMARC only blocks a forgery if the message fails both SPF and DKIM alignment for the visible From domain. A domain that publishes an enforcing DMARC policy but has weak or incomplete SPF and DKIM can still let mail through in ways it did not intend, and can also break its own legitimate senders. The building blocks each have their own grading page: SPF and DKIM. The census also shows the reporting side is neglected — the rua address that would surface a spoofing attempt in progress is frequently pointed nowhere, quantified against the DMARC reporting methodology.

The 2.9% figure is also why “we have DMARC” is such an unreliable proxy for safety. A leadership team that has been told the domain is protected is, on the base rates, most likely sitting in the 53.6% p=none cohort, or in the far larger group missing DMARC entirely — not in the 2.9% that have closed the whole surface. The only way to know which group your executive’s domain is in is to read the live records. Domains that do close every surface at once are rare enough to have their own study: The Locked Vault: Only 10.9 Million Domains Close Every Attack Surface Simultaneously.

You can settle the question for your own domain in about thirty seconds. Check your domain free at defaults.exposed — it reads your live SPF, DKIM and DMARC records straight from public DNS and tells you whether your executive’s domain actually enforces, or merely publishes.

Stopping CEO fraud: enforce DMARC (p=reject) and add out-of-band verification

CEO fraud is defended on two layers at once: a technical layer that stops the forged email arriving, and a human layer that stops a request from being acted on even if it does. Neither is sufficient alone. Both are cheap relative to a single successful transfer.

Layer one — close the technical door (get the domain to p=reject). The path from a p=none record to an enforcing one is well-trodden and low-risk when done in order:

Start at p=none with rua= reporting to a monitored mailbox. If you already publish p=none, you are here — but here is a runway, not a runway’s end. If you publish nothing, this is step one and it breaks no mail.
Read the aggregate reports and fix alignment. Over two to four weeks the reports reveal every legitimate service sending as you — mail platform, CRM, invoicing tool, newsletter provider. Bring each into SPF and DKIM so genuine mail aligns.
Move to p=quarantine. Forged mail now diverts to spam. This alone removes most impersonation exposure.
Move to p=reject, pct=100, sp=reject. Forged mail is refused outright; the policy covers all mail, not a sample; and subdomains inherit the protection so finance.yourcompany.com cannot be used as a back door. This is the destination — the state that actually blocks a forged [email protected].

Each step is a single DNS TXT edit. The work is the listening in step 2, which is why starting today matters even if you cannot enforce today. To see how the full fix is delivered — SPF, DKIM and an enforcing DMARC policy done correctly — see how the fix works.

Layer two — build an out-of-band verification habit. Technical controls protect the domain you own; they do not protect against look-alike domains, compromised supplier mailboxes, or the day a control is misconfigured. So pair enforcement with a human rule that no urgent payment or payment-detail change is ever actioned on the strength of an email alone:

Mandate a second channel for money movements. Any wire transfer or change of bank details above a threshold must be confirmed by a call to a known number — not a number supplied in the email — or in person.
Kill the urgency lever. Make it explicit policy that “urgent and confidential” is a reason to slow down and verify, not to skip the check. Remove the social cost of a junior employee pausing to confirm with the CEO.
Run the drill. Brief finance staff on the exact CEO-fraud pattern above so the request pattern is recognised the moment it arrives.

The two layers reinforce each other. Enforcement drops the volume of forged mail that ever reaches a human; the verification habit catches the residual — the look-alike domain, the compromised third party, the misconfiguration. An organisation with only the human layer is one distracted afternoon from a loss; an organisation with only the technical layer is exposed the moment an attacker switches from exact-domain spoofing to a look-alike.

What this means

For executives and finance leaders, the uncomfortable takeaway is that “we deployed DMARC” is not the same statement as “my domain cannot be impersonated,” and the gap between them is where CEO fraud lives. On the census base rates, a domain told it is protected is most likely sitting at p=none — one of the 40,541,896 that publish but do not enforce — and the people defrauded will be your own staff, acting in good faith on an email that looked exactly like it came from you. The fix is free to implement and costs an afternoon of listening followed by a one-line DNS change. Not finishing the rollout is a decision to stay spoofable.

For IT and security teams, the number to report to leadership is not “DMARC is deployed” but “DMARC is enforcing at p=reject, pct=100, with sp=reject, and legitimate senders align.” A record at p=none belongs on the project plan, not the completed list. Given that only 2.9% of the entire internet has closed the full stack, assume your own posture needs reading rather than assuming it is finished — and pair the technical fix with the out-of-band verification rule, because enforcement does not touch look-alike domains or a compromised counterparty.

FAQ

What is CEO fraud? CEO fraud is a type of business email compromise in which a criminal impersonates a chief executive or other senior leader and emails an employee — usually in finance — with an urgent, confidential request to transfer money or change payment details. The attacker does not need to hack the CEO’s mailbox; they forge the appearance of an email from it. It succeeds by combining authority with urgency to bypass normal scrutiny. It is enabled technically when the executive’s domain does not enforce DMARC: the August 2026 census found 90.7% of domains — 341,945,132 — have no enforcing policy, so a forged executive email is delivered rather than rejected.

How does CEO fraud work? The attacker researches the executive’s name and email and picks a finance target, then sends a short, pressured message appearing to come from the CEO: an urgent, confidential payment that “cannot wait.” There is usually no attachment or link — nothing for a scanner to catch — because the instruction itself is the payload. Whether that forged email lands in the inbox depends on the domain’s DMARC policy. If the domain enforces DMARC (p=quarantine or p=reject), the forgery is blocked; if it publishes p=none — as 53.6% of the 75,571,248 DMARC publishers do — the email is delivered looking authentic. Check your domain free at defaults.exposed to see which state your domain is in.

How do you prevent CEO fraud? Defend on two layers. Technically, move your domain’s DMARC policy from p=none to p=reject at pct=100 with sp=reject, backed by aligned SPF and DKIM, so a forged executive address is rejected before delivery — the full stack only 2.9% of domains (10,902,284) currently run. Procedurally, require that every wire transfer or bank-detail change is verified out-of-band via a known phone number, never a number supplied in the email, and make “urgent and confidential” a trigger to slow down rather than to skip the check. Enforcement stops exact-domain forgeries; the verification habit catches look-alike domains and compromised third parties that DMARC cannot touch.

What is the difference between CEO fraud and BEC? Business email compromise (BEC) is the umbrella category for all email-based scams that impersonate a trusted party to redirect money or data. CEO fraud is one variant within it — the executive-impersonation play, where the forged sender is a senior leader and the target is someone who can move money on their say-so. Other BEC variants include vendor or invoice fraud (impersonating a supplier) and payroll diversion. What they share is the enabling weakness: a domain that can be spoofed because it does not enforce DMARC. For the full taxonomy and losses across every variant, see What Is Business Email Compromise.

Data to cite

“53.6% of the domains that publish a DMARC record — 40,541,896 of 75,571,248 publishers — set the policy to p=none, meaning it is published but not enforcing and the domain stays fully spoofable.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“90.7% of graded domains — 341,945,132 of 376,928,750 — have no enforcing DMARC policy, leaving the executive’s own domain forgeable in a CEO-fraud attempt.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Only 2.9% of domains — 10,902,284 — carry the complete SPF, DKIM and enforcing-DMARC stack that fully blocks exact-domain email forgery.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Only 9.3% of graded domains — 34,983,618 — enforce DMARC with p=quarantine or p=reject, the two values that actually stop a forged email reaching a recipient.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Just 20.0% of graded domains — 75,571,248 — publish any DMARC record at all, and most of those do not enforce it.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

CEO fraud does not begin with a hacked mailbox. It begins with a domain that can be forged — and most organisations that believe they are protected are reading a published record as an enforcing one. On the census base rates, the odds are that your executive’s domain either publishes no DMARC or sits at p=none, one of the 40,541,896 records that look protective and do nothing.

Check your domain free at defaults.exposed — it reads your live SPF, DKIM and DMARC records from public DNS and tells you instantly whether your policy actually enforces, whether your subdomains are covered, and whether someone could send email as your CEO. Takes 30 seconds. No account needed. If you want the gaps closed properly — SPF, DKIM, and an enforcing DMARC policy done right — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded from 432,127,908 scanned. All figures are counts of graded domains. References: RFC 7489 (DMARC), RFC 7208 (SPF), RFC 6376 (DKIM).

How to cite this report

Press / blog: defaults.exposed (2026). CEO Fraud Explained: Why Publishing DMARC Is Not Enough. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/ceo-fraud-explained-why-publishing-dmarc-is-not-enough

Academic: defaults.exposed. (2026, August 21). CEO Fraud Explained: Why Publishing DMARC Is Not Enough. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/ceo-fraud-explained-why-publishing-dmarc-is-not-enough

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750 graded domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,750 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →