Payroll diversion fraud

29 March 2026 · 15 min read

Payroll diversion fraud is one of the quietest and most profitable email scams running, and it almost never involves malware, a hacked server, or anything a virus scanner would notice. The attacker sends a polite message that appears to come from an employee, asks the payroll or HR team to update the bank details on file for the next salary run, and waits. If the team makes the change, the employee's entire net pay lands in the criminal's account on payday. The employee notices nothing until the money does not arrive, by which point the funds have usually been moved on through a chain of mule accounts and are unrecoverable.

This article is specifically about that scam: the direct-deposit redirect, sometimes called salary diversion or payroll redirection. It is a close cousin of invoice fraud, but the target, the pretext, and the controls that stop it are different enough to deserve their own treatment. We will walk through exactly how the email side works, why standard spam filtering does not catch it, what email authentication does and does not do against it, and the process controls that close the gap authentication cannot reach on its own.

What payroll diversion fraud actually is

The mechanics are simple, which is part of why it works so well. Most employers pay staff by direct deposit (in the UK, by BACS or Faster Payments; in the US, by ACH). The bank account each employee is paid into is held as a field in the payroll or HR system. Change that field, and the next payment goes wherever the new field says.

A payroll diversion attack is just a social-engineering campaign aimed at getting that field changed. The attacker impersonates an employee and emails whoever processes bank-detail changes, usually a payroll administrator, an HR generalist, or a finance assistant. The message says something like "I have switched banks, please update my account for this month's pay" and supplies a new sort code and account number, or routing and account number. There is no invoice, no attachment, no link to click. It is a plain request that looks entirely routine, because it is a routine request: employees genuinely do change banks.

The payout is large and clean. A single salary can be four or five figures, it arrives on a predictable date, and unlike a card transaction there is no chargeback mechanism. By the time payday reveals the diversion, the attacker has had the whole pay cycle to launder it.

Two variants are worth naming, because the defence differs slightly:

• Employee impersonation (the common case). The attacker pretends to be a rank-and-file employee changing their own bank details. Low scrutiny, because the request is mundane and the amount is one person's salary.
• Executive or manager impersonation. The attacker poses as a senior person instructing payroll to make a change or to push a payment, leaning on authority and urgency. This shades into classic business email compromise, and the same authority pressure shows up in CEO-fraud-style wire requests.

In both cases the criminal never needs to touch your money systems. They only need to convince a human to type new digits into a form.

How the email is built: four ways the "from" gets faked

The believability of the request rests almost entirely on who the email appears to be from. There are four distinct techniques attackers use to make a message look like it comes from an employee, and they fail very differently against authentication. Knowing which one you are looking at tells you whether DMARC could have stopped it.

1. Exact-domain spoofing (forging your own domain)

The attacker puts a real employee's address in the From header, using your actual domain, for example j.smith@yourcompany.com. Nothing is misspelled. To the recipient it looks indistinguishable from a genuine internal email.

This is the variant that email authentication was built to kill. The forged message is sent from infrastructure that has no right to use your domain, so it cannot produce a valid SPF pass for your domain or a valid DKIM signature aligned to it. A DMARC policy at enforcement (p=quarantine or p=reject) instructs the receiving server to junk or reject mail that claims your domain but fails authentication. Done properly, exact-domain spoofing of your own staff simply stops landing in your own inboxes. We will come back to why "done properly" is load-bearing.

2. Lookalike (cousin) domain spoofing

Here the attacker registers a domain that resembles yours and sends from it: yourcompany-hr.com, yourccompany.com (doubled letter), yourcompany.co instead of .com, or a homoglyph swap that is invisible at a glance. The From address is genuinely valid for that domain, so the message can pass SPF and DKIM and DMARC for the lookalike. Authentication on the lookalike succeeds, because the criminal owns it.

This is the crucial limit to understand: DMARC protects the exact domain that publishes the record. It says nothing about domains that merely look similar. Your own enforcement policy cannot block yourcompany-hr.com, because you do not control its DNS and it is not your domain. Lookalike domains are defeated by different tools, covered below.

3. Display-name spoofing

The From address is some unrelated mailbox the attacker controls, often a free webmail account, but the display name is set to the employee's full name: John Smith <john.smith.payroll@gmail.com>. Many mail clients, especially on mobile, show only the display name and hide the actual address. The recipient sees "John Smith" and reads no further.

Authentication passes here too, but for the attacker's throwaway account, not for you. The mail is genuinely from gmail.com and authenticates as gmail.com. DMARC on your domain is irrelevant because your domain never appears in the authenticated From. This is pure display-name spoofing, and it is depressingly effective precisely because it sidesteps the cryptographic controls entirely.

4. Account takeover (the genuine account)

The worst case: the attacker has the employee's real mailbox credentials, through phishing or a reused password, and sends from the actual account. Now the email is genuinely from j.smith@yourcompany.com, it passes every authentication check correctly, and there is no spoofing to detect because there is no spoofing. The message is real; only the intent is fraudulent.

No email-authentication control can stop this, by definition, because authentication confirms the message came from the legitimate sender, and it did. This is why process controls, not just DNS records, are non-negotiable.

Why spam filters and "looks fine" miss it

Payroll diversion emails are unusually hard for content filtering because they have none of the usual spam signals. There is typically no attachment, no URL, no malware, no shouting subject line, and no obvious phishing kit. A message that reads "Hi, I've changed banks, new details below, thanks" is linguistically indistinguishable from a legitimate request. The fraud lives in the identity of the sender and the action being requested, not in any payload a scanner can fingerprint.

That is exactly why this category sits in the threats space rather than the spam space, and why identity controls (authentication) plus procedure controls (verification) carry the defence. The filter has nothing to grab onto. You have to decide based on who really sent the message and whether the change was independently confirmed.

What email authentication does, precisely, against payroll fraud

Let us be honest and specific about which variants authentication kills and which it cannot touch, because overstating DMARC's reach is how organisations end up with a false sense of safety.

Authentication at enforcement defeats exact-domain spoofing

If you publish DMARC at p=reject with aligned SPF and DKIM, variant 1 (forging your own domain) is shut down. An attacker can no longer drop j.smith@yourcompany.com into the From and have it delivered to your payroll team, because the receiving server checks your DMARC policy, sees the authentication fail, and rejects. This is real, meaningful protection and it is the single highest-value control you can put in place, because exact-domain spoofing is both common and the most convincing variant.

A correct enforcement record looks like this:

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

The p=reject is what does the work. A policy of p=none monitors and reports but instructs receivers to do nothing, so a p=none domain offers zero protection against spoofing despite "having DMARC". This is the trap covered in why p=none is a false sense of security: the record exists, the reports flow, and the spoofed payroll email still sails through because you never told receivers to act. If your goal is stopping fraud, monitoring is the start of the journey, not the destination. The whole point of reaching p=reject safely is to get from monitoring to actual enforcement without breaking legitimate mail along the way.

You can confirm where a domain actually stands with the DMARC checker; a record sitting at p=none is not protecting you regardless of how complete it looks.

Strict alignment closes a subtle gap

Notice the adkim=s and aspf=s in that record: strict alignment. With the default relaxed alignment, a message From yourcompany.com can pass DMARC on the strength of authentication for a subdomain such as mail.yourcompany.com. Usually that is fine and desirable. But if an attacker can get mail authenticated for any subdomain, perhaps a forgotten or weakly controlled one, relaxed alignment lets it count. For high-value internal domains, strict alignment narrows that. More importantly, make sure your organisational policy and your subdomain policy (sp=) both enforce, so an attacker cannot exploit a permissive subdomain that inherits nothing. A domain that enforces at the apex but leaves subdomains at p=none has a side door.

Authentication does not touch lookalikes, display-name spoofing, or account takeover

Be clear-eyed here. Of the four variants:

• Variant 1 (exact-domain spoof): stopped by DMARC at enforcement.
• Variant 2 (lookalike domain): not stopped, because the criminal authenticates their own domain.
• Variant 3 (display-name spoof): not stopped, because your domain is not in the authenticated From.
• Variant 4 (account takeover): not stopped, because the mail is genuinely authentic.

So enforcement is necessary and high-value, but it covers one of the four pathways outright. The other three demand controls outside DNS. Anyone who tells you "we have DMARC, so payroll fraud is handled" has only addressed a quarter of the attack surface.

The controls that catch what authentication cannot

Because three of the four variants slip past authentication, the durable defence pairs your DMARC enforcement with process and visibility controls. These are the ones that actually catch the lookalike, the display-name fake, and even the compromised genuine account.

1. Out-of-band verification for every bank-detail change

This is the single most important control, full stop. Any request to change an employee's bank details, or to make or redirect a payment, must be confirmed through a channel that is not the email that requested it. Call the employee on the phone number already held in the HR system, not a number supplied in the email. Speak to them, or use a known internal messaging channel, and confirm they genuinely changed banks.

Out-of-band verification is the only control that defeats account takeover, because it does not rely on the email being fake. Even if the message is genuinely from the employee's real mailbox, a separate human confirmation surfaces the fraud, since the real employee will say "I never sent that". Bake it into the procedure as mandatory, not discretionary, so an administrator under time pressure cannot quietly skip it.

2. A change-of-bank-details cooling-off and dual-control rule

Add friction precisely where the money is at risk:

• No bank change takes effect in the same pay cycle it is requested. A short delay removes the urgency the attacker depends on and gives verification time to happen.
• Two people must approve any change to payment destination. Dual control means a single tricked administrator cannot complete the diversion alone.
• Treat urgency as a red flag, not a reason to hurry. "Please update before today's run" is the attacker's lever. Genuine bank changes are rarely that time-critical, and payroll teams should be trained to slow down precisely when pushed to speed up.

3. Make external mail visibly external

Display-name spoofing and lookalike domains both rely on a message feeling internal. A mail-flow rule that prepends a clear banner to every message originating outside your organisation breaks that illusion. When "John Smith" emails payroll but the banner says EXTERNAL, the administrator's guard goes up before they read the request. It is a blunt control, but it is cheap and it directly counters variants 2 and 3, which authentication cannot.

4. Defend against lookalike domains directly

Since DMARC cannot reach cousin domains, address them on their own terms:

• Register the obvious permutations of your domain yourself (.co, doubled letters, hyphenated -hr and -payroll variants) so attackers cannot.
• Monitor for newly registered lookalikes through a domain-monitoring service, so a fresh yourcompany-payroll.com triggers an alert while it is still being set up rather than after it has been used.
• Block or flag known lookalikes at your own mail gateway once spotted, so even if staff at other organisations cannot be protected, your own people are.

5. Reduce account takeover risk at source

Variant 4 only exists because mailboxes get compromised. Phishing-resistant multi-factor authentication on email accounts, particularly for anyone in HR, payroll, and finance, removes the most common path to a stolen mailbox. This is general security hygiene, but it is directly load-bearing for payroll fraud, because a protected mailbox cannot be turned into a perfectly authenticated fraud-sending tool.

How your DMARC reports help you see attacks in progress

Even though authentication only blocks one variant outright, your DMARC reporting stream is a genuine intelligence feed for exact-domain spoofing attempts against you. When someone tries to forge yourcompany.com to hit your payroll team, the receiving servers that reject it also report it, and those failures show up in your aggregate data.

Feed your reports into the DMARC report analyzer and watch for failing sources that claim your domain from infrastructure you do not own. A sudden cluster of forged mail from an unfamiliar IP range, claiming your domain, is frequently the reconnaissance or opening move of a spoofing campaign. It is the early-warning value of reporting, distinct from the blocking value of enforcement. If you are new to reading this data, reading your first DMARC report covers how to interpret it, and DMARC alignment explained clarifies why a message can pass SPF or DKIM yet still fail DMARC, which is exactly the pattern a forger produces.

The catch is that reports are only useful if someone actually looks at them, and raw XML at volume is unreadable. Continuous monitoring with change alerts means a new spoofing source or a sudden spike surfaces as a notification rather than sitting unread in a mailbox. Our monitoring and change alerts describe how that works in practice, and ongoing monitoring keeps the enforcement you worked to achieve from silently regressing.

Putting it together: a defence that actually holds

Payroll diversion fraud succeeds at the seam between technology and process, so the defence has to span both. No single control is sufficient, and the failure mode of most organisations is to do one and assume it covers the rest.

A defence that holds looks like this:

1. Get to p=reject with aligned SPF and DKIM, including subdomains, so exact-domain spoofing of your staff stops being delivered. Verify with the DMARC checker, SPF checker, and DKIM checker, and use the DMARC generator to build the record if you are starting fresh.
2. Mandate out-of-band verification of every bank-detail change and payment redirect, through a known phone number, never a contact detail from the email itself. This is the control that catches the lookalike, the display-name fake, and even the genuinely compromised account.
3. Add a cooling-off period and dual control on payment-destination changes, and train payroll to treat urgency as suspicious.
4. Flag external mail visibly and defensively register and monitor lookalike domains, since authentication cannot reach those.
5. Harden mailboxes with phishing-resistant MFA, especially in HR, payroll, and finance, to shrink the account-takeover path.
6. Watch your DMARC reports for forging attempts as an early-warning feed, with alerting so attacks surface fast.

The honest summary: email authentication is essential and it closes the most convincing single pathway, exact-domain spoofing, but on its own it leaves three of four variants open. Pair enforcement with verification process and lookalike defence and you close the gaps that authentication architecturally cannot.

If you are not yet sure whether your own domain is actually enforcing or merely monitoring, run it through the DMARC checker now: a record sitting at p=none is leaving the door open to exactly this attack. And if getting safely from monitoring to p=reject without breaking legitimate payroll and HR mail sounds like more risk than you want to carry, that managed journey, from first record to enforced policy with monitoring that keeps it there, is precisely what our done-for-you DMARC service exists to handle.