Invoice & CEO fraud

A fake invoice from accounts@yourcompany.com does not look fake. The logo is right, the signature block is right, the From address is genuinely your domain, and the customer who receives it has no reason to doubt it. That is the whole point of invoice and CEO fraud: the attacker borrows your identity so the request to change bank details, or to wire money urgently, arrives wearing your face. This page explains exactly how the attack works, which version of it DMARC actually stops, which version it does not, and what else you need alongside it.

How the attack works, step by step

Business email compromise (BEC) is not technically clever. It is patient and human. A typical sequence looks like this:

1. The attacker researches your organisation from your website, LinkedIn, and any leaked email lists. They learn who signs off payments, who runs accounts, and who your suppliers and customers are.
2. They send a message that appears to come from a trusted internal or external address. Two common framings: a supplier writes to your finance team saying "our bank details have changed, please update them for the next payment", or someone posing as your CEO writes to a junior finance staffer saying "I need you to process an urgent payment before the board call, keep this between us".
3. Because the email looks routine and carries a familiar name, it clears the human filter. Urgency and a thin layer of secrecy discourage the recipient from picking up the phone to check.
4. The payment goes to an account the attacker controls. By the time anyone reconciles the books, the money has moved through several accounts and is gone.

The same mechanics run in the other direction. An attacker forges a message that genuinely appears to come from your domain and sends a fraudulent invoice to your customers. They pay it, believing they have paid you. You have lost nothing in cash, but you have lost a customer's trust and money, and your brand is now attached to a scam.

Two flavours: exact-domain spoofing versus lookalikes

This distinction matters more than almost anything else on this page, because it decides whether DMARC helps you or not. Be honest about it with yourself and with anyone you brief.

Exact-domain spoofing

Here the attacker puts your real domain in the visible From address. The email claims to be from accounts@yourcompany.com, and that string is literally yourcompany.com. This is the version DMARC was built to defeat. If your domain publishes v=DMARC1; p=reject and the message is not properly authenticated, a receiving mail server rejects it before it reaches the inbox.

Lookalike domains and display-name spoofing

Here the attacker does not use your domain at all. They register something that reads almost the same at a glance:

• Cousin domains: yourcompany-invoices.com, yourcompany.co instead of .com, or your-company.com with a hyphen.
• Homoglyphs: a Latin "a" swapped for a Cyrillic one, or rn standing in for an "m" so modern reads as rnodern.
• Display-name spoofing: the From shows "Jane Smith, CEO" but the underlying address is jane.smith.ceo@gmail.com. On a phone, recipients often see only the display name.

None of these put your domain in the From line, so DMARC on your domain has nothing to act on. The attacker's own domain (or a free webmail account) handles authentication, and it can pass SPF and DKIM perfectly well for itself. DMARC does not stop this. Anyone who tells you it does is selling you something that will not hold.

Scale and cost: why this attack persists

The FBI's Internet Crime Complaint Centre (IC3) consistently ranks business email compromise among the most expensive categories of cybercrime it tracks, well ahead of headline-grabbing categories like ransomware in total reported losses. The reason is simple economics for the attacker. There is no malware to write, no exploit to buy, and no network to breach. A free email account, a convincing template, and a wire instruction are enough. A single successful invoice redirect can move a five or six figure sum, and the marginal cost of the next attempt is close to zero.

That asymmetry is why the volume does not fall. The defender has to be right every time. The attacker only has to be right once, on one tired finance clerk, on one busy afternoon.

Your customers and suppliers are the victims, and you carry the damage

When an attacker spoofs your domain to bill your customer, your customer loses the money, but you inherit the consequences. The conversation that follows is unpleasant and predictable:

• The customer believes you sent the invoice, because the From address was genuinely yours.
• They ask, reasonably, why your email systems let a fraudster impersonate you.
• Even after you explain, the trust does not fully return. People remember the loss, not the technical nuance.

The reputational cost outlives the financial one. Suppliers start treating your invoices with suspicion. Customers add friction to every payment. Procurement teams flag you in their own security reviews. A spoofing incident becomes a line item in someone else's risk register, with your name next to it.

If a fraudster can send mail that genuinely appears to come from your domain and your domain does nothing to stop it, you are providing the attacker with your own credibility for free.

Exactly how enforced DMARC helps

DMARC closes the exact-domain door, and it does so at the recipient's mail server, before a human ever sees the message. It works by combining three things:

• SPF checks whether the sending server is on a list you publish.
• DKIM attaches a cryptographic signature, verified against a public key at selector._domainkey.yourcompany.com, that proves the message was authorised by your domain and not altered in transit.
• Alignment is the part that defeats spoofing. DMARC requires that the domain which passed SPF or DKIM matches the domain in the visible From address. An attacker can make their own server pass SPF for their own domain, but they cannot make it align with yourcompany.com, because they do not hold your DKIM private key and cannot get your domain to authorise their server.

Once you publish v=DMARC1; p=reject; rua=mailto:reports@yourcompany.com, a forged message claiming to be from your domain fails alignment and is refused by Gmail, Yahoo, Outlook and any other receiver that honours DMARC. The fake invoice from accounts@yourcompany.com never lands.

The catch is the word enforced. Most domains that publish DMARC are stuck at p=none, which only watches and reports. It blocks nothing. A spoofed message under p=none is delivered exactly as if you had no DMARC at all. The protection only exists at p=quarantine or p=reject. Getting there safely, without your own legitimate mail being caught, is the work described on our guide to reaching enforcement.

What else you need alongside DMARC

Because DMARC only governs your own domain in the From line, it must sit inside a wider defence. The pieces that cover what DMARC cannot:

Lookalike-domain monitoring

Watch for newly registered domains that resemble yours, including hyphenated variants, alternative top-level domains, and homoglyph swaps. Catching yourcompany.co the week it is registered gives you time to warn customers, file a takedown, or block the domain at your own gateway before an invoice goes out.

Payment verification process

This is the single most effective control against the part DMARC cannot reach, and it costs nothing but discipline:

• Any change to a supplier's bank details must be confirmed by phone, on a number you already held, not one from the email requesting the change.
• Payments above a set threshold require a second authoriser.
• "Urgent and confidential" is treated as a red flag, not a reason to hurry. Genuine executives expect their finance team to verify large transfers.

Staff training

Finance and accounts payable staff should be able to inspect a From address on a desktop client, recognise display-name spoofing, and feel safe slowing a payment down to check. The culture matters as much as the content: people verify when they will not be blamed for the delay.

Inbound TLS and reporting

MTA-STS (a policy at https://mta-sts.yourcompany.com/.well-known/mta-sts.txt plus a _mta-sts TXT record) forces inbound mail to arrive over encrypted connections, and TLS-RPT collects daily reports of any failures. This does not stop BEC on its own, but it removes a class of interception that some advanced fraud relies on.

A candid section: what DMARC does and does not cover

It is tempting to present DMARC as the answer to email fraud. It is not the whole answer, and overselling it leaves you exposed where you think you are covered. To be precise:

DMARC is necessary and it is the only control that stops exact-domain spoofing at scale, automatically, on the recipient's side. But it is one layer. Pair it with monitoring, process, and training, and you have closed the door on the cheapest version of the attack while keeping watch on the rest.

Where to start

Begin by finding out whether your domain can be spoofed right now. A free scan checks whether you publish DMARC, whether it is at p=none or actually enforcing, and whether your SPF and DKIM are aligned. If your record reads p=none, or you have no record at all, a forged invoice from your domain will reach inboxes today. From there, work through our path to enforcement so the move to p=reject does not catch your own newsletters, invoicing platform, or helpdesk mail. The same enforcement work underpins your deliverability at Gmail, Yahoo and Outlook, and it satisfies the anti-spoofing controls that show up in compliance and cyber-insurance reviews.

Invoice and CEO fraud succeeds because it abuses trust you have spent years building. Enforced DMARC takes your own domain off the table as a weapon against your customers, and that is a meaningful, measurable win. Just remember where its protection ends: it guards your name, not every name that looks a little like yours. Cover that gap with people and process, and you have a defence that holds.