Invoice Fraud Prevention: Closing the Domain-Spoofing Gap Behind BEC

Published 2026-08-21

Invoice fraud is the manipulation of billing to divert a legitimate payment to a criminal — most often by impersonating a real supplier and sending an invoice with altered banking details. It is the commonest financial outcome of business email compromise (BEC), and it works because the supplier’s domain can usually be spoofed. The August 2026 census of 376,928,750 graded domains finds that 90.7% have no enforcing DMARC policy, and of the estimated 223 million domains that actively receive mail, roughly 195 million remain spoofable. Preventing invoice fraud takes two things most programs treat separately: accounts payable controls, and closing the domain-spoofing gap that lets the fraudulent email arrive looking genuine.

An organisation can have immaculate internal process and still pay a criminal, because the weak link is often not inside the finance team at all — it is a supplier whose domain any attacker can forge. This report sets out the full prevention picture: how invoice fraud works, the accounts payable controls that stop it, and the technical control — enforcing email authentication — that removes the fraudulent email’s disguise before it ever reaches a human. The spoofability figures throughout come from the defaults.exposed August 2026 census, a scan of 432,127,908 domains graded as of 2026-08-16.

What Invoice Fraud Is, and How It Relates to BEC

Invoice fraud is a family of attacks with one goal: get a real organisation to send a real payment to the wrong account. The dominant variants:

Supplier impersonation (mandate fraud). The attacker poses as an existing supplier and notifies accounts payable of “new banking details.” The next genuine invoice is paid to the criminal’s account.
CEO / executive fraud. The attacker impersonates a senior figure and instructs finance to make an urgent payment, often bypassing normal process “just this once.”
Fake or duplicate invoices. The attacker submits an invoice for goods or services never supplied, or re-submits a genuine invoice for a second payment, relying on weak duplicate invoice detection to slip through.

Almost all of these are delivered by business email compromise. BEC is the umbrella term for attacks that use email — spoofed, impersonated, or from a genuinely compromised mailbox — to induce a fraudulent transfer. The FBI’s Internet Crime Complaint Center has for years ranked BEC among the highest-loss categories of cybercrime it tracks, consistently ahead of ransomware in reported losses, because it needs no malware and no technical exploit. It needs a believable email about money.

The believability is the whole game. An invoice-fraud email is persuasive in direct proportion to how much it looks like it came from the real supplier. And that is decided not by the attacker’s skill but by whether the supplier’s domain published a record telling the world’s mail servers to reject forgeries.

How the Attack Actually Works

Follow a supplier-impersonation attack end to end and every step maps to a specific control that could have stopped it.

Reconnaissance. The attacker learns which suppliers you use — from a data breach, a LinkedIn post, a public tender, or a genuinely compromised mailbox somewhere in the supply chain. Compromised-mailbox access is especially dangerous because it reveals real invoice formats, real amounts, and the real timing of billing cycles.
The disguised email. The attacker sends an invoice or a banking-change notice that appears to come from the supplier. If the supplier’s domain has no enforcing DMARC policy, the attacker can spoof it exactly — the visible From address is the supplier’s real domain, and the receiving mail server has no instruction to reject it. If the domain is locked down, the attacker falls back to a lookalike domain (supplier-billing.com) or display-name impersonation, both of which are more noticeable.
The altered detail. The invoice is normal in every respect except the bank account, or it carries a “we’ve changed banks, please update our details” note. A Reply-To pointing to the attacker keeps the conversation away from the real supplier.
The urgency. The message manufactures time pressure — an early-payment discount expiring, a service about to be cut off, an executive who needs it done before a flight. Urgency exists to push the payment past verification.
The payment. Without a payment authorization step that independently verifies the account change, the transfer goes out. By the time the real supplier chases the overdue invoice, the money has moved through several accounts.

Notice where the attack is won or lost. Step 2 is a technical control — email authentication on the supplier’s domain. Steps 3 to 5 are process controls inside your finance function. A serious invoice-fraud prevention program needs both, because each covers the other’s blind spot: authentication stops the convincing forgery from arriving, and process stops the ones that still get through by other means.

The Root Cause the Census Measures: Spoofable Supplier Domains

Here is the uncomfortable finding, and the reason this is a defaults.exposed report rather than a generic finance-controls checklist.

The census graded 376,928,750 domains. 341,945,132 of them — 90.7% — have no enforcing DMARC policy. On this site, that is the definition of spoofable: without an enforcing policy, no receiving mail server has an instruction to reject mail that forges the domain. Narrow the lens to domains that actually run email — the ones that matter for invoice fraud, because they belong to real trading businesses — and the picture barely improves. Of an estimated 223 million domains with MX records, roughly 195 million lack an enforcing DMARC policy and can therefore be exactly spoofed.

In plain terms: pick any supplier at random, and the odds are heavily against their domain being protected. The email your accounts-payable team is about to trust could carry that supplier’s genuine domain in the From field and still have been sent by a criminal, because the supplier never published the record that would have stopped it.

This reframes vendor verification. The usual questions — is this a real company, are these the agreed terms — are necessary but they assume the email itself is genuine. At a 90.7% spoofability rate, that assumption is unsafe. Supplier verification has to include the supplier’s email security posture, because a supplier who cannot stop their own domain being forged is a supplier whose invoices you cannot take at face value. That posture is externally checkable in seconds, from public DNS, without the supplier’s involvement — which is exactly what the census does at scale.

And the same logic runs the other way. Your customers are, to their own finance teams, a supplier. If your domain has no enforcing DMARC, you are the spoofable link in someone else’s accounts-payable process, and an attacker who forges you can defraud your customers. Closing your own domain protects your revenue relationships, not just your inbox.

The Red Flags Accounts-Payable Teams Should Train On

Employee training is a control, not a poster. The specific patterns that should trigger a hold-and-verify:

Any change to banking details. This is the single highest-risk event in accounts payable. A change of bank account, sort code, IBAN, or beneficiary name is the payload of nearly every mandate-fraud attack. It should never be actioned from an email alone.
Last-minute changes to payment instructions. “Use this account instead, the usual one is being audited.” Legitimate suppliers change banks rarely and calmly; fraud changes them urgently and at the last moment.
Unusual urgency or secrecy. Pressure to pay immediately, to skip the normal approval, or to keep the payment confidential is a defining marker of BEC.
A mismatched or subtly wrong sender domain. supplier.co instead of .com, an extra word, a swapped character. Train staff to read the full address, not the display name.
A Reply-To that differs from the From. Visible in the email headers; a hallmark of impersonation.
An invoice that doesn’t match a purchase order, or a second copy of an invoice already paid — the signals that purchase order matching and duplicate invoice detection exist to catch.

The training goal is narrow and achievable: make every banking-detail change and every out-of-band payment request trigger the same reflex — stop, and verify through a channel the email did not choose.

Accounts Payable Controls That Stop Invoice Fraud

The process side of prevention is a small set of controls that, applied together, make a single fraudulent email insufficient to move money.

Independent callback verification. Any change of bank details, and any unusual payment request, is verified by calling the supplier back on a number you already hold — never a number or link in the email requesting the change. This one control defeats the majority of mandate fraud, because the attacker controls the email thread but not the supplier’s known phone line.

Segregation of duties. The person who can add or amend a supplier’s bank details must not be the person who approves the payment. Separating those roles means no single compromised account or deceived individual can both redirect and release a payment. Segregation of duties is the structural backbone of invoice-fraud resistance.

Payment authorization thresholds and dual approval. Payments above a defined value, and all new-payee or changed-payee payments, require a second authoriser. Payment authorization should be tied to the risk of the change, not just the amount — a changed bank account on a small recurring invoice deserves the same scrutiny as a large one-off.

Purchase order matching (three-way match). Match every invoice to its purchase order and to the goods-received record before payment. Purchase order matching kills fake-invoice fraud outright: an invoice with no corresponding PO and no delivery has nothing to match, and stops at the gate.

Duplicate invoice detection. Automated checks for repeated invoice numbers, amounts, and dates catch both honest error and the re-submission attack. Duplicate invoice detection belongs in the AP system, not in someone’s memory.

Structured invoice validation. Beyond matching, invoice validation confirms the supplier is on the approved vendor master, the bank details match the record on file, the tax details are consistent, and the terms are as agreed. Invoice validation is where a changed bank account should surface as an exception before payment, not after.

A controlled vendor master and real vendor verification. New suppliers are onboarded through a defined vendor verification process — confirmed legal identity, confirmed bank ownership, confirmed contacts — and the vendor master is access-controlled and change-logged. Vendor verification at onboarding, and again whenever details change, is the record everything else validates against.

Fraud detection software. Modern accounts-payable and payment platforms include fraud detection software that scores payments for anomalies — new payees, changed accounts, out-of-pattern amounts, mismatched beneficiary names against the destination account (confirmation-of-payee). Fraud detection software is a strong backstop, but it works best behind, not instead of, the process controls above.

None of these is exotic. Together they express one principle: a payment or a payee change should require more than one email to happen.

The Technical Control Most Invoice-Fraud Programs Miss

Almost every invoice-fraud guide stops at the process controls above. The census shows why that leaves the biggest hole open: those controls all activate after the fraudulent email has arrived and been believed. The cheapest place to stop invoice fraud is one step earlier — stopping the convincing forgery from arriving at all.

That is what enforcing email authentication does, and it is the control most finance-led programs never reach because it lives in DNS rather than in the finance system.

On your own domain, publish SPF, DKIM, and an enforcing DMARC policy (p=reject). This makes your domain impossible to exactly-spoof, which protects your customers and suppliers from fraud committed in your name — a direct defence of your trading relationships. Only 9.3% of graded domains have done this; being in that cohort is a genuine trust signal.

On your suppliers’ domains, add email-security posture to vendor verification. You cannot fix a supplier’s DNS, but you can check it — spoofability is externally measurable — and you can treat a spoofable supplier’s banking-change emails with elevated scrutiny, and encourage your key suppliers to close the gap. A supplier who publishes enforcing DMARC has removed the attacker’s ability to forge them; a supplier who has not is a standing risk to your payments.

Where it fits alongside the rest: enforcing DMARC does not replace callback verification or segregation of duties — display-name spoofing, lookalike domains, and genuinely compromised mailboxes all bypass it, and process catches those. It removes the single most convincing attack, exact-domain spoofing, from the board, so your process controls face a smaller, noisier set of attempts. Digital signatures on invoices, where a supplier relationship supports them, add a further cryptographic assurance of origin and integrity on top. MFA on every mailbox with access to billing closes the compromised-account route that authentication alone cannot.

The layered posture — enforcing email authentication, MFA, and disciplined accounts payable controls — is what turns invoice fraud from a plausible email into a chain of independent checks an attacker has to defeat all at once.

What this means

For finance leaders, invoice fraud is not purely a finance-process problem, and treating it as one leaves the largest gap open. Your controls — segregation of duties, payment authorization, purchase order matching, duplicate invoice detection, callback verification — are necessary and they stop most attacks that reach a human. But 90.7% of domains can be spoofed, which means the fraudulent email that starts the attack usually arrives wearing a genuine supplier’s identity. Add the supplier’s email-security posture to your vendor verification, and make every banking-detail change a verify-by-phone event regardless of how convincing the email looks.

For IT and security teams, the ask from finance is concrete and measurable: publish an enforcing DMARC policy on every domain the organisation owns, so no one can be defrauded by mail forged in your name, and give the finance team a way to check whether a supplier’s domain is spoofable. Both are externally verifiable from public DNS. If your own domain sits at p=none today, moving to p=quarantine is a single record edit and immediately reduces the organisation’s exposure to impersonation — of you, to your customers.

For business owners, the exposure cuts both ways and both sides are cheap to close. An unprotected domain lets criminals invoice your customers in your name; unverified supplier email lets criminals invoice you in your suppliers’ names. The fix for the first is free and takes an afternoon. The fix for the second is a habit — verify every payment change out of band — plus a quick check of whether the suppliers you pay most can be spoofed. Neither requires new software; both require deciding that a payment should never turn on a single email.

FAQ

What is invoice fraud? Invoice fraud is the manipulation of billing to divert a legitimate payment to a criminal. The commonest form is supplier impersonation, or mandate fraud, where an attacker poses as a real supplier and sends an invoice or notice with altered banking details so the next genuine payment goes to the attacker’s account. Other forms include fake invoices for goods never supplied and duplicate invoices submitted for a second payment.

How is invoice fraud related to business email compromise? Most invoice fraud is delivered by business email compromise (BEC) — an attack that uses a spoofed, impersonated, or genuinely compromised email account to induce a fraudulent payment. BEC is consistently among the highest-loss categories of cybercrime reported to the FBI’s IC3, because it requires no malware, only a believable email about money. Invoice fraud is the financial payload; BEC is the delivery method.

How does email spoofing enable invoice fraud? If a supplier’s domain has no enforcing DMARC policy, an attacker can send an email that carries the supplier’s real domain in the From field, and the receiving mail server has no instruction to reject it. The invoice then looks genuine to accounts payable. The August 2026 census found 90.7% of graded domains — and roughly 195 million of the estimated 223 million mail-receiving domains — lack an enforcing policy, so most suppliers can be spoofed this way.

What accounts payable controls prevent invoice fraud? The core set is: independent callback verification of any banking-detail change using a number you already hold; segregation of duties so the person who changes a payee is not the person who approves payment; payment authorization with dual approval for new or changed payees; purchase order matching to reject invoices with no corresponding order; duplicate invoice detection; structured invoice validation against the vendor master; and disciplined vendor verification at onboarding and whenever details change. Together they ensure no single email can move money.

Can email authentication alone stop invoice fraud? No, but it removes the most convincing attack. Enforcing DMARC on your own domain stops criminals exactly-spoofing you to defraud your customers, and checking suppliers’ domains tells you which of their emails to treat with extra caution. It does not stop display-name spoofing, lookalike domains, or a genuinely compromised supplier mailbox — which is why accounts payable controls and MFA remain essential. Authentication and process each cover the other’s blind spot.

How can we check whether a supplier’s domain can be spoofed? A domain’s email-authentication posture is published in public DNS and can be checked externally without the supplier’s involvement. A free domain scan shows whether the domain publishes SPF, DKIM, and an enforcing DMARC policy, or whether it can be spoofed. Adding this check to vendor onboarding and to any banking-change request gives accounts payable an objective risk signal alongside the usual verification steps.

Data to cite

“90.7% of graded domains — 341,945,132 of the 376.9 million measured in the August 2026 census — have no enforcing DMARC policy, meaning a supplier chosen at random can most likely be spoofed in the emails your accounts-payable team receives.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Of an estimated 223 million domains that actively receive mail, roughly 195 million lack an enforcing DMARC policy — the majority of real trading businesses can be exactly spoofed.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Only 9.3% of graded domains — 34,983,618 — publish an enforcing DMARC policy, the control that stops criminals forging a domain to send fraudulent invoices in its name.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“214,276,774 domains — 56.8% of the graded web — publish neither SPF nor DMARC, leaving them with no email-authentication posture for a vendor-verification check to rely on.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Invoice fraud is defeated by a layered posture: enforcing email authentication removes exact-domain spoofing, while accounts payable controls — segregation of duties, callback verification, and purchase order matching — catch the attacks that reach a human by other means.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands — and your suppliers’

Invoice fraud turns on one question accounts payable rarely asks: can the domain this invoice came from be spoofed? For 90.7% of domains, the answer is yes — and the owners mostly don’t know. You can check any domain, yours or a supplier’s, privately and free, and see exactly which email-authentication records it publishes and whether its DMARC policy is enforcing.

Check your domain free at defaults.exposed — see instantly whether your domain can be spoofed to invoice your customers, and where your key suppliers stand. Takes 30 seconds. No account needed. If you want your own domain’s gaps closed properly — SPF, DKIM, and enforcing DMARC 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. MX-domain figures are approximate estimates scaled from the graded population and the August SPF/DMARC overlap data. All other figures are counts of graded domains. References: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), FBI IC3 Business Email Compromise reporting, EU NIS2 Directive 2022/2555.

How to cite this report

Press / blog: defaults.exposed (2026). Invoice Fraud Prevention: Closing the Domain-Spoofing Gap Behind BEC. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/invoice-fraud-prevention-closing-the-domain-spoofing-gap-behind-bec

Academic: defaults.exposed. (2026, August 21). Invoice Fraud Prevention: Closing the Domain-Spoofing Gap Behind BEC. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/invoice-fraud-prevention-closing-the-domain-spoofing-gap-behind-bec

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 →