3 June 2026 · The DMARC Engine Team · 12 min read
Invoice fraud rarely starts with a dramatic breach. It usually starts with an email that looks completely ordinary: a supplier you already work with, sending a routine invoice, asking you to settle it by bank transfer. The sender address is correct. The branding is right. The amount is plausible. The only thing wrong is who actually sent it, and by the time anyone notices, the money has left the account.
This is the quiet, expensive end of business email compromise (BEC). It does not rely on malware or stolen credentials in most cases. It relies on one weakness that millions of domains still have: the ability for a stranger to put your domain in the From address and have it land in someone's inbox looking genuine. This article walks through exactly how that happens, why recipients trust it, how the payment-redirect scam plays out, and precisely what a correctly deployed DMARC policy stops. It also draws a clear line around what DMARC does not stop, because pretending otherwise gets people robbed.
Why the From address is so easy to forge
Email was designed in an era of mutual trust between a small number of cooperating systems. The protocol that carries mail, SMTP, was never built to verify who a sender claims to be. There are two separate sender identities in any message, and most people only ever see one of them.
The first is the envelope sender (also called the Return-Path or MAIL FROM). This is used during the SMTP conversation between mail servers and is where bounce messages go. Recipients almost never see it.
The second is the header From, the human-readable address shown in the email client as "From: Accounts <accounts@yourcompany.co.uk>". This is the identity people actually read and trust. It is just a line of text in the message headers, and nothing in base SMTP stops an attacker from writing whatever they like there.
So an attacker can connect to a mail server they control, set the visible From to accounts@yourcompany.co.uk, write a convincing invoice, and send it. No password needed. No access to your systems. The recipient's mail client displays your domain because the message told it to, and historically there was no check to confirm the message had any right to use that domain. This is exact-domain spoofing: the forged address is character-for-character your real domain.
Three standards exist to close this gap, and DMARC ties them together. Understanding each is worth a few minutes because the whole defence rests on how they interact.
SPF, DKIM and DMARC in plain terms
SPF (Sender Policy Framework) is a published list of the mail servers allowed to send for your domain. You add a DNS record naming the IP addresses and services that legitimately send your mail. A receiving server can check whether the connecting server is on that list. SPF validates the envelope sender domain, not the visible From, which matters later. You can check what your domain currently publishes with the SPF checker, and there is a fuller explanation on the SPF product page.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing mail. Your sending system signs parts of the message with a private key, and the matching public key sits in your DNS. A receiver recomputes the signature and confirms the message genuinely came from a system holding your key and was not altered in transit. The DKIM checker inspects a published key, and the DKIM product page covers selectors and key rotation.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that turns SPF and DKIM into a usable defence for the visible From address. It does two essential things.
First, it adds alignment. SPF on its own validates the envelope sender. DKIM validates the signing domain. Neither inherently protects the From address that humans read. DMARC requires that a passing SPF or DKIM result line up with the domain in the visible From. If a message claims to be from yourcompany.co.uk in the header but only passes SPF for some unrelated domain, DMARC alignment fails. This is the part that actually defends the address recipients see.
Second, it lets you publish a policy telling the world what to do with mail that fails. The policy lives in a DNS record and has three settings:
p=none: monitor only. Failures are reported back to you but still delivered. Useful for learning, useless as protection.p=quarantine: failing mail is treated as suspicious, usually routed to spam or junk.p=reject: failing mail is refused outright at the receiving server. It never reaches the inbox.
You can see any domain's current policy with the DMARC checker, and the DMARC product page explains the full record syntax.
The headline fact is simple: a DMARC record at p=reject, properly aligned, is what stops a stranger from putting your exact domain in the From address and reaching an inbox. At p=none, the spoof still lands. The policy is the part that bites.
The anatomy of an invoice-fraud attack
Let us walk through a realistic attack from the criminal's side, because seeing the steps makes the defences obvious.
Step 1: Reconnaissance
The attacker chooses a target and learns the relationships. They might know your company has a finance team, regular suppliers, and a habit of paying invoices by bank transfer. A great deal of this is public or semi-public: company websites list staff, LinkedIn reveals who works in accounts payable, press releases mention partnerships, and procurement portals leak supplier names. Sometimes the attacker has already read a real email thread, either from a compromised mailbox somewhere in the supply chain or from a leaked dataset.
The single most valuable piece of intelligence is a genuine, in-progress transaction. If a real invoice is due, a fake one inserted at the right moment is almost impossible to spot.
Step 2: Choosing the forged identity
Now the attacker decides whose name to wear. The strongest choice, if it works, is your exact domain. An email that genuinely shows billing@yoursupplier.com carries the full weight of an established relationship. There is nothing to notice because there is nothing wrong with the address itself.
This is the decision point that DMARC influences. If the chosen domain publishes p=reject with correct alignment, exact-domain spoofing fails at the receiving server and the attacker has to fall back to a weaker, more noticeable trick (covered later). If the domain has no DMARC, or sits at p=none, exact-domain spoofing is wide open.
Step 3: Crafting the message
The fake invoice is built to look routine. It often reuses real logos, a real invoice template scraped from an earlier genuine document, a plausible reference number, and language consistent with the supplier's usual tone. The payload is rarely a malicious attachment. The payload is new bank details.
The message says something like: "Please note our banking has changed; future payments should go to the account below." Or it simply attaches an invoice that already contains the attacker's account number. There is no link to click, no file to scan, nothing for a malware filter to catch. The entire attack is a few sentences of text and a sort code.
Step 4: Delivery and timing
The attacker sends the message so it arrives when finance is busy and a payment is plausibly due, often near month-end or just before a weekend. If they have exact-domain spoofing working, the email shows your real domain and threads naturally into existing correspondence. Sometimes they reply within a real thread by spoofing the From of a known participant.
Step 5: The payment
A staff member sees a known supplier, a normal invoice, updated bank details, and a deadline. They process the transfer. The money moves to a "mule" account and is rapidly dispersed. Recovery is rare because the funds are gone within hours and often cross borders. By the time the real supplier chases the genuine unpaid invoice, weeks later, the trail is cold.
The whole scheme hinges on one moment of misplaced trust, and that trust is granted largely because the From address looked right.
Why recipients trust a spoofed address
It is easy to blame the person who paid, but the design of email is working against them. A few human and technical factors stack up.
People read the display name and the visible address, not the headers. Almost nobody inspects the Return-Path, the Received chain, or the Authentication-Results header before paying an invoice. On a phone, many clients show only the display name and hide the address entirely.
Trust is transferred from the relationship to the message. If you already pay this supplier every month, your guard is down. The email is not asking you to do anything unusual; paying their invoice is your job.
Authentication, where it exists, is invisible when it passes. Recipients never see "this message failed DMARC" unless the receiving server acts on it. That is the entire point of p=reject: the failing message is removed before a human is asked to judge it, because humans are unreliable judges of forged headers.
This is why the defence has to be at the protocol level. You cannot train your suppliers' finance teams to manually verify your headers, and you cannot train your own staff to catch a perfect forgery. You can publish a policy that stops the perfect forgery from arriving.
What DMARC at p=reject actually stops
Be precise about the win, because precision is what makes the rest of the plan honest.
A DMARC record at p=reject, with SPF and/or DKIM correctly aligned to your domain, stops exact-domain spoofing of your domain at any receiver that honours DMARC. The major mailbox providers (Google, Microsoft, Yahoo and others) honour it.
Concretely, this means an attacker can no longer connect to a random server, set the From to accounts@yourcompany.co.uk, and have it delivered to one of your customers or staff. The receiving server checks DMARC, finds the message fails alignment, sees your published p=reject, and refuses it. The inbox never sees the forgery.
That is a genuine and large reduction in attack surface. Exact-domain spoofing is the most convincing version of the attack precisely because the address is flawless, and p=reject removes it. For the subset of invoice fraud that wears your real domain, this is the single most effective control you can deploy.
It also protects your outbound reputation. When criminals cannot send convincing mail as you, your customers stop receiving fraud that appears to come from you, and your brand stops being the vehicle for someone else's crime. The aggregate reports DMARC generates also show you who is sending under your name, which is how you discover both abuse and your own forgotten legitimate senders. Continuous monitoring of those reports is what keeps the policy safe over time as your sending systems change.
There is a sequencing caution worth stating plainly. You cannot jump straight to p=reject without preparation. If your real mail (the marketing platform, the invoicing tool, the CRM, the helpdesk) is not properly covered by aligned SPF and DKIM, p=reject will block your own legitimate email. The correct path is to start at p=none, read the reports, bring every genuine sender into alignment, move to p=quarantine, confirm nothing legitimate breaks, then move to p=reject. Done carelessly this causes an outage. Done methodically it causes nothing but a quieter inbox for everyone. This staged migration is exactly what a done-for-you service handles so the only mail that ever gets blocked is the forged kind.
What DMARC does not stop
Here is where honesty matters most. DMARC protects your exact domain. It does nothing about domains that merely look like yours, and nothing about a display name that lies while using a different address. Attackers know this, and when p=reject closes the exact-domain door, they walk through one of these instead.
Lookalike and cousin domains
A cousin domain is a separate domain registered by the attacker that resembles yours closely enough to fool a quick glance. Examples against yourcompany.co.uk:
yourcompany-invoices.co.uk(extra word)yourcompany.cooryourcompany.com(different top-level domain)yourcornpany.co.uk(the letters "rn" imitating "m")yourcompany-ltd.com(added suffix)your-company.co.uk(added hyphen)- Internationalised lookalikes using Unicode characters that render almost identically to Latin letters (a homograph attack)
The attacker owns this domain outright. They can, and often do, publish perfectly valid SPF, DKIM and even DMARC p=reject for their own fraudulent domain. From the receiver's point of view the cousin-domain email passes authentication, because it is genuinely authenticated mail from a domain the criminal legally controls. Your DMARC record protects yourcompany.co.uk; it has no authority over yourcornpany.co.uk. The two are unrelated domains as far as the protocol is concerned.
So a cousin-domain invoice sails past DMARC entirely. The defence here is different: domain monitoring and registration of obvious lookalikes, careful human review of the address (not just the display name), and process controls on payments. More on those below.
Display-name spoofing
Many email clients prominently show the display name and tuck the actual address away, especially on mobile. An attacker can set the display name to "Your Company Accounts" while the real address behind it is accounts.yourcompany@gmail.com or some throwaway address on a domain you have never heard of.
DMARC evaluates the domain in the From address. If that domain is some random Gmail or attacker-owned address, DMARC for your domain is never even consulted, because the message does not claim to be from your domain at the protocol level. It only claims it in the friendly name a human reads. The message can pass its own authentication while still showing "Your Company Accounts" to a busy recipient who never expands the address.
This is one of the most common BEC variants precisely because it sidesteps authentication completely. It is defeated by client configuration that surfaces the full address, by user awareness, and by payment process controls, not by DMARC.
Compromised real accounts
If an attacker has stolen the actual credentials of a real mailbox (yours or a supplier's), they can send genuine mail from a genuine account. It will pass SPF, DKIM and DMARC, because it is, by every technical measure, legitimate. Authentication confirms the message came from an authorised system; it cannot tell that the human at the keyboard is a criminal. This is defended by multi-factor authentication, login monitoring and the same payment controls.
The pattern across all three gaps is the same: DMARC removes the cleanest attack (exact-domain spoofing) and forces the attacker into noisier, more detectable techniques. That is exactly why you want it, and exactly why it cannot be your only control.
A layered prevention plan
Because no single technology covers every variant, invoice fraud is defeated by layers. Here is a practical, ordered plan.
1. Lock down your own domain with DMARC at enforcement
Publish SPF and DKIM for every legitimate sender, align them to your domain, and progress through p=none, p=quarantine and finally p=reject. This is the foundation and the thing that stops exact-domain spoofing of you. Use the free tools to inspect your current records, and review the practical sequence on the requirements page. Do not stop at p=none; monitoring alone protects nobody.
Also publish DMARC on domains you own but do not send from, including parked and brand-protection domains. An unused domain with no DMARC is a free spoofing vehicle. A short v=DMARC1; p=reject; record on a non-sending domain shuts that down.
2. Tighten the supporting standards
Add MTA-STS so mail to your domain is delivered over enforced TLS and cannot be silently downgraded or intercepted in transit, explained on the MTA-STS product page. Consider BIMI, which displays your verified logo in supporting inboxes once you are at enforcement, covered on the BIMI product page. BIMI gives recipients a genuine visual trust signal that cousin domains cannot replicate, because it requires DMARC enforcement and a verified mark.
3. Monitor for lookalike domains
Since DMARC cannot touch cousin domains, watch for them. Track new registrations that resemble your brand, register the most obvious and dangerous variants yourself (common misspellings, the .com/.co/.net of your .co.uk), and keep an eye on certificate transparency logs for suspicious lookalikes acquiring TLS certificates. Where a malicious domain is actively impersonating you, pursue takedown through the registrar.
4. Surface the real address to humans
Configure mail clients to show the full email address, not just the display name, and add external-sender banners that warn when a message originates outside your organisation. These two changes directly counter display-name spoofing and many cousin-domain attempts by making the deception visible at a glance.
5. Put process controls on every payment
This is the layer that catches what technology misses. Make these non-negotiable in finance:
- Verify any change of bank details out of band. If an email asks you to update an account number or sort code, confirm it by calling a known, previously stored phone number for the supplier, never a number from the email itself. This single rule defeats most invoice fraud regardless of how the email was forged.
- Require dual authorisation for payments above a threshold and for any first-time or changed payee.
- Maintain a verified supplier bank-details record and treat any deviation as suspicious until confirmed.
- Slow down on urgency. Pressure and tight deadlines are the attacker's main tool; a mandatory pause for verification removes their advantage.
6. Protect accounts and train staff
Enforce multi-factor authentication on all mailboxes to reduce account takeover, and train finance and procurement staff to recognise the pattern: a changed bank account, an unexpected urgency, a slightly odd address. Awareness will not catch a perfect forgery, which is why it sits last, after the technical and process controls that do the heavy lifting.
The practical takeaway
Invoice fraud begins with a forged sender because, for decades, forging the visible From address cost an attacker nothing. DMARC at p=reject, with aligned SPF and DKIM, takes that for granted no longer: it stops exact-domain spoofing of your domain at every major receiver, which removes the most convincing version of the attack and stops criminals using your brand against your own customers. That is a real, measurable reduction in risk and the first thing every domain should put in place.
Be equally clear-eyed about the limits. DMARC does not stop lookalike or cousin domains, display-name spoofing, or mail from compromised accounts. Those need domain monitoring, client configuration, and above all a hard rule that no change of bank details is ever actioned on the strength of an email alone. Defence in depth is not a slogan here; it is the difference between blocking the clean attack and ignoring the messy ones.
Start by seeing where you stand. Run your domain through the DMARC checker to find your current policy, and if you are still at p=none or have no record at all, the safe path to p=reject without breaking your real mail is exactly what the done-for-you DMARC service exists to do.