Executive impersonation and CEO fraud

22 April 2026 · 16 min read

A finance clerk gets an email that appears to be from the chief executive. It is short, slightly urgent, and plausible: "Are you at your desk? I need you to process a payment to a new supplier before the close of business, I'm in back-to-back meetings so just email me when it's done." The reply-to address is the boss's name. The tone matches how the boss actually writes. There is no malware, no dodgy attachment, no link to a fake login page. There is just a request from authority, and a member of staff who wants to be helpful. This is executive impersonation, also called CEO fraud or business email compromise, and it is the single most expensive category of email attack measured by money lost per incident.

This article is specifically about the impersonation-of-a-leader variant and the exact role DMARC plays in stopping it. DMARC is genuinely powerful here, but it is powerful against one precise technique and blind to several others. Understanding exactly which attacks an enforced DMARC policy kills outright, and which ones sail straight past it, is the difference between a real defence and a false sense of security. We will be concrete about both.

What "executive impersonation" actually means

CEO fraud is a social-engineering attack that wears the costume of authority. The attacker does not need to break anything technical if they can convince a human with payment authority that an instruction came from someone they would not question. The mechanics are almost always the same:

• A target with the power to move money or data. Accounts payable, finance, payroll, or an executive assistant who can authorise or initiate a transfer.
• An impersonated authority figure. The CEO, CFO, a board member, a managing partner. Someone whose request you act on without escalating.
• A pretext that suppresses verification. Urgency ("before close of business"), secrecy ("this is a confidential acquisition, don't discuss it"), unavailability ("I'm on a flight, can't take calls"), and plausibility (a real supplier, a believable amount).
• A new payment destination. A changed bank account, a new beneficiary, a "supplier" the attacker controls, or a gift-card request.

Notice what is missing. There is frequently no malicious payload at all. A classic CEO-fraud message is plain text with a name in the From field and a request in the body. That matters enormously for defence, because most email security tools are tuned to catch malware, credential-phishing links, and known-bad attachments. A message with none of those can look completely clean to a content scanner. The deception lives entirely in the identity the message claims and the behaviour it asks for. That is precisely the layer DMARC governs, which is why it is part of the answer, and precisely why the parts of the deception DMARC cannot see are where these attacks succeed.

The technique DMARC was built to kill: exact-domain spoofing

The most direct way to impersonate your CEO is to forge their actual email address. If the chief executive is ceo@yourcompany.com, the cleanest attack is to send a message where the From header literally reads ceo@yourcompany.com. No typos, no lookalikes, the genuine address. To a recipient scanning their inbox, it is indistinguishable from the real person because it is the real person's address in the From line.

This is called exact-domain spoofing, and it is trivial to attempt. The SMTP protocol lets any server set any From address it likes; nothing in the basic act of sending mail proves the sender is entitled to the domain they claim. An attacker can stand up a mail server, or abuse an open relay, and emit thousands of messages with From: ceo@yourcompany.com in minutes. Without authentication, the receiving server has no way to know this did not come from your real infrastructure.

DMARC exists to close exactly this hole. When a receiver evaluates a message claiming to be from yourcompany.com, DMARC asks one question: does an authenticated identity align with the domain in the visible From header? It checks two underlying mechanisms:

• SPF confirms the sending IP is authorised to send for the envelope domain. For DMARC, the envelope domain must align with the From domain.
• DKIM confirms a cryptographic signature over the message, tied to a domain via the d= tag. For DMARC, that d= domain must align with the From domain.

If at least one of those passes and aligns with the From domain, DMARC passes. If neither does, DMARC fails, and your published policy tells the receiver what to do. A record at enforcement looks like this:

v=DMARC1; p=reject; rua=mailto:reports@yourcompany.com; adkim=s; aspf=s

With p=reject published, a forged message claiming From: ceo@yourcompany.com from an attacker's server has no valid SPF or DKIM that aligns with yourcompany.com. The attacker does not hold your DKIM private key and is not sending from an IP in your SPF record. DMARC fails, and a conformant receiver rejects the message before it reaches the clerk's inbox. The attack never lands. This is the core, and it is a genuinely hard wall: exact-domain spoofing of an enforced domain simply does not work against any receiver that honours DMARC, which now includes Gmail, Yahoo, Microsoft and effectively every major mailbox provider.

If you do not yet know whether your domain is at p=reject, check it with the DMARC checker, and read what is DMARC and DMARC alignment explained for the underlying mechanics. The fact that the policy must be at reject, not merely published, is the crux of the next section.

Why p=none gives you nothing against CEO fraud

A published DMARC record is not the same as protection. The policy tag is what counts. A record of p=none asks receivers to report on failures but to deliver the mail anyway. Against executive impersonation, p=none is worth almost nothing as a live defence: a forged From: ceo@yourcompany.com message still arrives in the inbox, because you have explicitly told receivers not to act on the failure.

This is the most common and most dangerous misunderstanding in this area. Organisations publish a DMARC record, see it in their DNS, and believe they are "doing DMARC". But p=none is a monitoring state, not an enforcement state. It is the right place to start, because it lets you discover every legitimate sender before you switch on blocking, but a domain that sits at p=none for years is fully exposed to exact-domain spoofing the entire time. We have a dedicated piece on this trap, the false security of p=none, because it catches so many people.

The protection only exists once you reach p=quarantine (forged mail goes to spam) or, properly, p=reject (forged mail is refused outright). Getting there without blocking your own legitimate mail is the whole discipline of DMARC deployment: discover every sender, align them all with SPF and DKIM, then ratchet the policy up. Reach p=reject without breaking email and the enforcement journey lay out that sequence. The takeaway for impersonation specifically: if your goal is to stop someone forging your CEO's exact address, you have not started until your policy is at enforcement. Everything before that is groundwork.

The gaps: what exact-domain DMARC does not stop

Here is where honesty matters. An attacker who knows you have p=reject on yourcompany.com does not give up; they switch technique. Every method below produces an email that looks like it comes from your CEO while passing DMARC cleanly or never being subject to your DMARC policy at all. These are the attacks that succeed against well-configured domains, and they are why DMARC is necessary but not sufficient.

Lookalike and cousin domains

If the attacker cannot send from yourcompany.com, they register a domain that reads like it at a glance and send from there instead. They control the new domain entirely, so they publish perfectly valid SPF and DKIM for it, and their forged mail passes DMARC, because it is genuinely authenticated mail from a domain they own. DMARC checks alignment with the From domain; it has no opinion about whether that domain looks confusingly similar to yours.

The variations are endless:

• Character swaps: yourcompany.com becomes yourconpany.com or yourcompany.co.
• Homoglyphs: a Latin letter replaced with a near-identical Unicode character from another script.
• Inserted or hyphenated words: your-company.com, yourcompany-finance.com, yourcompanygroup.com.
• Different TLDs: yourcompany.org, yourcompany.net, yourcompany.io.

To the human reading "ceo@yourcompany-group.com" on a phone screen, the difference is invisible. Your DMARC policy on yourcompany.com is completely irrelevant, because the message never claimed to be from yourcompany.com. This is the most important gap to internalise: DMARC protects the exact domains you publish it on, and nothing else. The defence against lookalikes is not DMARC; it is defensive registration of obvious variants, brand and domain monitoring to spot new registrations, and crucially the human verification process described later.

Display-name spoofing

This one is almost embarrassingly simple and remains devastatingly effective, especially on mobile. Every email has two parts to its From: the display name (the friendly label) and the actual address. An attacker sets the display name to your CEO's full name while sending from any address they control:

From: "Jane Smith, CEO" <accounts.dept9912@gmail.com>

Most mail clients, particularly on phones, show only the display name. The recipient sees "Jane Smith, CEO" and reads no further. The message was sent from a Gmail address that has impeccable SPF and DKIM (Google signs it), so it passes Gmail's own DMARC for gmail.com. Your domain is never in the picture. Your p=reject does absolutely nothing, because the message is, technically, a perfectly legitimate email from a real Gmail account. Display-name spoofing and our explainer on email spoofing cover the technique in more depth. The only reliable defences are receiver-side display-name analysis (some gateways flag external mail whose display name matches an internal executive), client configuration that shows the real address, and human process.

Free-webmail and reply-to manipulation

A close cousin of display-name spoofing. The attacker sends from a throwaway webmail account, sets a convincing display name, and often sets the Reply-To header to a second address they control so that when the victim replies, the conversation continues directly with the attacker. Because the originating account (Gmail, Outlook.com, a fresh provider) is real and properly authenticated for its own domain, there is nothing for your DMARC policy to fail. The lure frequently opens with "I changed my email, use this one" to pre-empt the reply going to the real executive.

Compromised legitimate accounts

The most dangerous variant of all, and the one DMARC is structurally unable to stop. If an attacker steals the actual credentials to ceo@yourcompany.com, through phishing, password reuse, or a stolen session, and logs into the real mailbox, then every email they send is genuinely from your CEO's account. It passes SPF, it is signed with your real DKIM key, it aligns perfectly, and it sails through p=reject because it is not a forgery at all. It is authentic mail sent by an unauthorised person.

DMARC authenticates the domain and sending path, not the intent of the human at the keyboard. A compromised account is the textbook case where authentication is working exactly as designed and the attack still succeeds. The defences here live elsewhere: strong multi-factor authentication on every mailbox, conditional-access policies, anomaly detection for unusual sending behaviour, and rapid response when a compromise is suspected. This is also why we treat MFA on executive and finance mailboxes as non-negotiable rather than optional.

Subdomain and inactive-domain gaps

Two narrower but real gaps. First, subdomains: if you publish DMARC on yourcompany.com but not a strict subdomain policy, an attacker may try to forge from a subdomain you never send from, such as accounts.yourcompany.com. The fix is the sp tag controlling subdomain policy; see DMARC and subdomain policy. Second, parked or non-sending domains: every domain your organisation owns but does not send mail from should still carry a hard p=reject so it cannot be abused. Forgetting these leaves an attacker a domain that genuinely belongs to your brand and has no DMARC protection.

A clear map of what DMARC stops and what it does not

Stated plainly, so there is no ambiguity:

Enforced DMARC (p=reject) on your sending domains stops exact-domain spoofing dead: nobody can forge ceo@yourcompany.com and have it delivered by a DMARC-honouring receiver. It does nothing about lookalike domains, display-name spoofing, free-webmail impersonation, reply-to tricks, or a genuinely compromised account, because in every one of those cases the message either comes from a domain you do not control or is authentically from the account it claims.

That is not a criticism of DMARC; it is the correct scope of the tool. DMARC closes the one gap that is otherwise wide open and that no human process can reliably catch, namely a message bearing your CEO's real, exact address. The remaining gaps are real, but they all share a feature that the exact-domain attack lacks: there is something about the message a careful human or a layered control can catch, whether a slightly wrong domain, an external-sender warning, or a payment instruction that breaks normal process. The exact-domain forgery has none of those tells, which is why removing it with DMARC is so valuable even though it is not the whole defence.

Building the layers DMARC cannot provide

Because the surviving attacks are about human trust and lookalike identity rather than forged headers, the rest of the defence is part technical and part procedural.

Get to enforcement first. None of the layering below matters if exact-domain spoofing is still on the table, because that is the cleanest possible attack and it is fully solvable. Reach p=reject on every active sending domain and a hard reject on every parked domain. Verify each legitimate sender is aligned before you tighten, using the SPF checker and DKIM checker, and the DMARC report analyzer to confirm nothing legitimate is failing. If a finance-related sending service is not aligned at the point you flip to reject, you will lose real mail; service not aligned at reject covers that failure mode.

Flag external mail clearly. Configure your mail platform to mark messages from outside the organisation with a visible banner. Display-name spoofing relies on a recipient assuming an internal sender; an "EXTERNAL" tag on a message claiming to be from your CEO is a strong, cheap tell. In Microsoft 365 and Google Workspace this is a built-in setting; see DMARC for Microsoft 365 and DMARC for Google Workspace for where authentication and these controls sit together.

Register and monitor lookalikes. Defensively register the obvious cousin domains (common typos, the main alternative TLDs) and put new-registration monitoring in place so you learn quickly when someone registers yourcompany-payments.com. A registered lookalike you control cannot be used against you.

Lock down executive and finance mailboxes. Mandatory phishing-resistant MFA, tight session controls, and alerting on anomalous sends. This is the only defence against the compromised-account case, which DMARC cannot touch.

Make payment process the backstop. The deepest truth of CEO fraud is that it targets a process failure, not just a technical one. The instruction the attacker needs (move money to a new account, urgently, quietly) should be impossible to action on the strength of an email alone. Out-of-band verification, a call back on a known number, never the contact details in the email, dual authorisation for new payees and changed bank details, and an explicit organisational norm that no genuine executive will ever be angry that you verified a payment request are what stop the attacks that get past every header check. The pretext of urgency and secrecy exists precisely to short-circuit this step, which tells you how important the step is.

Adding visible trust: BIMI and verified logos

One forward-looking layer worth a mention. Once you are at enforcement, BIMI lets you publish your brand logo so it can display next to authenticated mail from your domain in supporting clients, and with a Verified Mark Certificate it carries an indication that the logo is a verified, registered trademark. This does not stop impersonation by itself, and it explicitly only appears on DMARC-passing mail, but it raises the baseline: recipients become accustomed to seeing the verified mark on genuine mail from you, which makes a logo-less lookalike message marginally more conspicuous. It is a reinforcement of an already enforced domain, never a substitute for one. See do you need BIMI and the BIMI checker if you want to evaluate it; treat it as the last 5 per cent, not the first move.

A worked scenario

Picture an attacker targeting a mid-sized firm with p=reject correctly deployed.

1. They try the clean forgery first. From: cfo@yourcompany.com, urgent supplier payment. The receiving server checks DMARC, finds no aligned SPF or DKIM, and your p=reject policy means the message is refused. The clerk never sees it. DMARC wins.
2. They switch to a lookalike. They register yourcompany-finance.com overnight, publish valid SPF and DKIM for it, and send From: cfo@yourcompany-finance.com. DMARC passes, because it is authenticated mail from a domain they own. Your policy on yourcompany.com is irrelevant. Now the only things standing in the way are the external-sender banner, the slightly wrong domain a careful reader might notice, and the payment-verification process. DMARC is bypassed; layers must catch it.
3. They go simpler still. From: "CFO Name" <financedept.secure@gmail.com>, a display-name spoof from a clean Gmail account. It passes Gmail's DMARC. On a phone, the clerk sees only "CFO Name". Here the only defences are the external tag, the recipient noticing it is a Gmail address, and the rule that a new bank account is never actioned without an out-of-band call. DMARC is irrelevant; process is the backstop.

The pattern is consistent. DMARC removes the strongest and stealthiest attack, the one with no human-visible tell, and forces the adversary into noisier techniques that a layered defence and a disciplined payment process are positioned to catch. That is exactly the right division of labour, and it is why you want both rather than treating either as complete on its own.

The practical takeaway

Executive impersonation is the most costly email attack per incident because it bypasses content scanners entirely and exploits human trust in authority. DMARC at enforcement is the indispensable first layer: published at p=reject, it makes exact-domain spoofing of your CEO's real address impossible against any modern receiver, and that is the one attack variant a human cannot reliably spot, since the address is genuinely correct. But DMARC protects only the exact domains you publish it on. Lookalike domains, display-name spoofing, free-webmail impersonation, reply-to tricks and compromised real accounts all produce a message that passes DMARC or sits outside its scope, and every one of them is a live threat against a perfectly configured domain. The complete defence is layered: enforcement on every sending and parked domain, external-sender banners, lookalike registration and monitoring, MFA on executive and finance mailboxes, and above all a payment process with out-of-band verification and dual authorisation that an urgent email cannot override.

Start by confirming where your policy actually sits with the DMARC checker; if you are still at p=none, you have no protection against even the simplest forgery yet. To close the exact-domain gap properly without losing legitimate finance mail in the process, our managed DMARC service discovers every sender, aligns them, and takes your domains from p=none to p=reject safely, while continuous monitoring alerts you the moment a new sending source or a spoofing burst appears, so the one attack DMARC can kill stays killed and you can focus your human controls on the ones it cannot.