Stop Invoice Fraud in Microsoft 365: The Six Layers That Actually Work

By Jonathan Fykes, CTO · Published February 21, 2026 · Last updated April 26, 2026

What "invoice fraud" actually means in Microsoft 365

"Invoice fraud" is a marketing umbrella. The attacks underneath it have different mechanics, and which control stops which attack matters.

The version that costs the most money is vendor email compromise (VEC). An attacker phishes a real person at one of your vendors, steals their M365 credentials, and signs into the vendor's mailbox. They don't blast spam. They sit. They read the Sent Items folder for two or three weeks until they understand who invoices whom, when, and for how much. When a real invoice goes out to you, the attacker either intercepts the reply thread or sends a follow-up from the legitimate mailbox saying "small change, please update remit-to bank details, see attached." Your accounting team sees an email from a sender they've worked with for years, in the same thread as the original invoice, and wires the money.

The version that's louder but cheaper is CEO or CFO impersonation, sometimes called business email compromise (BEC). The attacker spoofs the executive's display name on an external sender, emails accounting, and asks for an "urgent" wire to a new vendor. No mailbox is compromised. The attack lives entirely in the From line and the body of one message. This is the one your spam filter should catch, and the one that gets through anyway when impersonation protection isn't configured.

A third pattern blends them: an attacker compromises a junior account inside your tenant, sets up a hidden inbox rule to forward any message containing "wire" or "invoice" to an external Gmail address, and uses that intelligence to craft a follow-on attack against a sister company or a bigger customer. We cover the forwarding piece in detail in a sibling guide on how attackers use email forwarding rules in Microsoft 365.

The reason all three target M365 specifically is simple: M365 is where most small and mid-sized businesses run their email, and most of those tenants are still on close-to-default settings. The attacker doesn't need a zero-day. They need you not to have turned the dials.

A real attack flow, step by step

Picture a 40-person construction firm that subcontracts steel work from a fabrication shop two states over. They've worked together for six years. Standard payment is net 30 by ACH against a PDF invoice.

1. An estimator at the fabrication shop clicks a "DocuSign" link in a phishing email. The page is an Evilginx proxy. He enters his M365 password and approves the MFA prompt. The attacker now has a session token for his mailbox.
2. The attacker logs in via Outlook on the web and creates an inbox rule: any message with "invoice," "remit," or "wire" in the subject is moved to RSS Feeds and marked read. The estimator's Outlook never shows the rule because Outlook hides RSS Feeds by default.
3. For 19 days the attacker reads everything that hits that folder, learns the construction firm is the largest customer, learns the AP contact's name, and pulls a recent PDF invoice as a template.
4. A new $84,000 invoice goes out from the estimator to the construction firm's AP inbox. The attacker pulls it from the Sent Items folder.
5. An hour later, the attacker sends a follow-up from the same legitimate mailbox: "Hi, quick note: our bank changed last month, please use the routing/account on the attached updated invoice. Thanks." The PDF is a near-perfect copy with one swapped routing number.
6. AP sees the same sender, same thread, same logo, slightly different attachment. They wire $84,000 to a money-mule account in another state.
7. Three days later the real estimator calls asking when payment is coming. Everyone realizes at once. The bank has already executed the second-leg transfer overseas.

That entire chain is preventable. Layers 4 and 6 below would have stopped it cold. Layer 1 would have made it harder to disguise. The point of the stack is that no single control has to be perfect. They backstop each other.

Layer 1: Defender for Office 365 impersonation protection

Defender for Office 365 (included with Microsoft 365 Business Premium and most E-plan SKUs) has a feature called impersonation protection that most tenants never configure. It does two specific jobs:

• User impersonation: you give Defender a list of "protected users" (typically your CEO, CFO, controller, and AP lead), and Defender flags any inbound mail where the display name or address closely matches one of those users but the actual sending mailbox doesn't belong to your tenant.
• Domain impersonation: you give Defender a list of "protected domains" (your own primary domain, your largest vendors' domains, your bank's domain), and Defender flags inbound mail from look-alike domains (the classic vendorsupp1y.com versus vendorsupply.com swap).

To turn it on: Microsoft 365 Defender → Email & collaboration → Policies & rules → Threat policies → Anti-phishing. Edit the default policy or create a new one. Add up to 350 protected users and up to 50 protected domains. Set the action for detected user impersonation to Quarantine (not "move to Junk", because Junk is too easy for accounting to fish messages out of). Set the action for domain impersonation the same way.

The threshold setting matters. Defender has four levels: Standard, Aggressive, More aggressive, Most aggressive. Aggressive is the right default for invoice-fraud prevention. Standard misses too many display-name games. Most aggressive will quarantine your sister company's marketing newsletter and you'll get a help-desk ticket.

One thing this layer doesn't do: it doesn't catch a message sent from a genuinely compromised vendor mailbox. There's nothing to detect. The sender is real. That's what Layer 6 is for.

Layer 2: DMARC, DKIM, and SPF — what each one actually does

These three DNS records get blurred together in security articles. They do different things and you need all three.

SPF (Sender Policy Framework) is a TXT record on your domain that lists every IP address and service allowed to send mail as you. When a receiving server gets a message claiming to be from [email protected], it checks SPF: did this come from an approved sender? Without SPF, anyone in the world can spoof your domain.

DKIM (DomainKeys Identified Mail) is a cryptographic signature your mail server adds to every outbound message. The receiver looks up your DKIM public key in DNS and verifies the signature. If the message was forged or modified in transit, the signature fails. Microsoft 365 generates DKIM keys automatically but doesn't enable signing by default on custom domains. You have to turn it on in Defender → Email & collaboration → Policies → DKIM.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy that ties them together. A DMARC record tells receivers: "if a message claiming to be from my domain fails both SPF and DKIM alignment, here's what to do with it." It also asks receivers to send you reports about who's trying to spoof you.

The DMARC record has three policy settings:

• p=none: receivers report failures to you but deliver the mail anyway. This is monitoring mode, useful for the first 30 days while you find legitimate senders you forgot about.
• p=quarantine: receivers send failing messages to spam. Decent middle ground.
• p=reject: receivers refuse the message entirely. This is where you want to be.

A clean DMARC record for a small business looks like this:

_dmarc.yourcompany.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s"

Common misconfigurations we see all the time: SPF records that include a forgotten marketing platform from 2019 (include: entries that no longer resolve), DKIM enabled on the default onmicrosoft.com tenant domain but not on the company's actual sending domain, and DMARC stuck at p=none for two years because nobody owned moving it forward.

Read your DMARC reports. The rua reports come back as XML and are unreadable raw, but free tools like Postmark's DMARC Digests or DMARCian's free tier parse them into a dashboard. You'll see which IPs are sending mail as you, which pass, and which fail. That's how you find legitimate senders you forgot about, and how you spot when an attacker starts probing.

Layer 3: External sender warnings on every inbound message

The simplest layer in the stack and one of the most effective. A transport rule prepends a warning banner (usually [EXTERNAL] in the subject line and a yellow info box at the top of the body) to every message from outside your tenant. Outlook now has a native "External" tag on the web and mobile clients, but the transport-rule version works on every client and can't be hidden by Outlook customizations.

To create it: Exchange admin center → Mail flow → Rules → Add a rule → Create a new rule.

• Apply this rule if: The sender is located → Outside the organization.
• Do the following: Prepend the subject of the message with → [EXTERNAL]
• And: Apply a disclaimer to the message → Prepend a disclaimer with the HTML banner of your choice. Keep the banner short. A 200-word legal warning gets ignored after week one.
• Except if: The sender's address contains the domain of any vendor you want exempted (use this sparingly).

Why this layer matters specifically for invoice fraud: the CFO-impersonation attack relies on the recipient skimming the From field and seeing a familiar name. When the subject line starts with [EXTERNAL] and there's a yellow box at the top of the message, the visual context breaks. Accounting staff who've been trained to pause when they see the banner will pause.

One caveat: if your CEO actually does email from her personal Gmail when traveling, the banner will show on her real messages too. That's the right outcome. Train the team to call her on her cell when an "urgent wire" request lands with the external banner, regardless of which Gmail account it came from.

Layer 4: Block external auto-forwarding (and audit what's already there)

Of every control on this list, this one stops the most damage post-compromise. Once an attacker has a session token, the first thing they do is set up forwarding so they can keep reading mail after you reset the password. Kill the forwarding capability and you cap the blast radius.

Microsoft made this easier in 2020. Defender's outbound spam policy now blocks automatic external forwarding by default for tenants created after that date. Older tenants (anyone who set up M365 before 2020 and hasn't touched the policy since) are still wide open.

Check your current setting: Defender → Email & collaboration → Policies & rules → Anti-spam → Outbound spam policy (default) → Forwarding rules. The setting "Automatic forwarding rules" should be set to Off, Forwarding is disabled. If it's on "Automatic, System-controlled" or "On," change it.

That blocks new forwarding rules. It doesn't tell you what's already there. Run this in Exchange Online PowerShell to find existing inbox rules that forward externally:

Connect-ExchangeOnline

$mailboxes = Get-Mailbox -ResultSize Unlimited
$findings = foreach ($mbx in $mailboxes) {
    Get-InboxRule -Mailbox $mbx.UserPrincipalName |
      Where-Object {
        $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo
      } |
      Select-Object @{n='Mailbox';e={$mbx.UserPrincipalName}},
                    Name, Enabled, ForwardTo, ForwardAsAttachmentTo, RedirectTo
}

$findings | Export-Csv forwarding-rules-audit.csv -NoTypeInformation

Open the CSV. Anything in ForwardTo or RedirectTo that points to a Gmail, Yahoo, ProtonMail, or any address outside your tenant is a finding. Disable the rule, change the user's password, revoke their sessions, and treat that mailbox as compromised until you can prove otherwise. The recovery path runs through our sibling guide on how to tell if your M365 email has been compromised.

Also check mailbox-level forwarding (different from inbox rules):

Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
  Select-Object UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward |
  Format-Table -AutoSize

Same logic. Anything pointing outside your tenant gets investigated.

Layer 5: Lock down OAuth app consent

The newest attack pattern, and the one most tenants haven't caught up to. Instead of phishing a password, the attacker phishes consent. They send a link that looks like a legitimate "Microsoft" prompt asking the user to grant a third-party app permission to read their mail and send on their behalf. The user clicks Accept. The attacker now has a long-lived OAuth token tied to that user's mailbox, and that token survives password resets and MFA changes because it isn't a password.

Two settings close this door.

1. Restrict who can consent to apps. In Entra admin center → Identity → Applications → Enterprise applications → Consent and permissions → User consent settings, set "User consent for applications" to either Do not allow user consent (strict) or Allow user consent for apps from verified publishers, for selected permissions (balanced). The default ("Allow user consent for apps") is what gets tenants compromised.

2. Require admin approval for new apps. Same screen, enable the admin consent workflow. When a user tries to consent to an app that's not pre-approved, the request goes to a designated admin reviewer instead of being granted automatically.

Find apps users have already consented to with mailbox scopes:

Connect-MgGraph -Scopes "Directory.Read.All","Application.Read.All"

$mailScopes = @("Mail.Read","Mail.ReadWrite","Mail.Send","Mail.ReadWrite.All","MailboxSettings.ReadWrite")

Get-MgOauth2PermissionGrant -All |
  Where-Object {
    $scopes = $_.Scope -split ' '
    ($scopes | Where-Object { $mailScopes -contains $_ }).Count -gt 0
  } |
  Select-Object ClientId, ConsentType, PrincipalId, Scope |
  Export-Csv oauth-mail-consent-audit.csv -NoTypeInformation

Cross-reference the ClientId values with Get-MgServicePrincipal -ServicePrincipalId <ClientId> to see the app's display name and publisher. Anything you don't recognize, anything from an unverified publisher, anything created in the last 30 days that you didn't expect. Investigate. Common malicious patterns: apps named "PDF Viewer," "eFax," "Mail Manager," published by single-name developers with no website, requesting Mail.ReadWrite and Mail.Send.

Layer 6: The out-of-band verification rule that pays for everything else

Every technical control above can fail. Layer 6 is the one that doesn't, because it doesn't depend on email at all.

The rule: any change to vendor banking information, and any wire transfer over a defined dollar threshold, requires a verbal callback to a phone number on file from before the change request. Not a number in the email. Not a number on the new invoice. The number from the vendor's signed master service agreement, or from a previous invoice that was paid successfully, or from the vendor's main website.

What "defined dollar threshold" should be is a business call. Many small businesses set it at $5,000. Mid-market firms run $25,000. The threshold matters less than the existence of the rule. Three operational details make it work in practice:

• Document the vendor phone number once, at onboarding. Store it in your accounting system's vendor record. Don't trust the number on a future invoice.
• Two-person approval over a higher threshold. One person initiates, a second approves, and the second person is the one who places the verification call. This stops the social-engineering attack where the attacker has already compromised the AP clerk.
• Make the rule painful to skip. If a controller signs off on a wire without the callback log attached, that's a finding in the next audit. Make the audit real.

If the construction firm in the example above had this rule, the $84,000 wire would have been delayed by exactly one phone call. That's the entire trade.

How to know if it's already happening

Prevention is half the job. The other half is noticing fast when one of the layers fails. Three things to watch:

Defender alerts on impersonation hits. Once impersonation protection is on, Defender starts firing alerts for matched messages. Defender → Incidents & alerts → Alerts, filter on "Email messages containing user impersonation" and "Email messages containing domain impersonation." Review them weekly. Most will be false positives at first, and that's signal too. You're tuning the system.

Anomalous sign-in detection in Entra. Entra → Protection → Risky users / Risky sign-ins. Microsoft scores every sign-in for risk based on impossible travel, unfamiliar location, anonymous IP, leaked credentials, and a few other signals. A "high" risk score on a finance user is a "stop everything and investigate" event. Set up a Conditional Access policy that requires MFA re-prompt and password change on high-risk sign-ins.

The forwarding-rule audit on a schedule. The PowerShell snippet from Layer 4 should run monthly, the output emailed to whoever owns tenant security. New external-forwarding rules between runs are findings until proven benign.

For the specific signs that a single mailbox is in trouble, our deep-dive on spotting an M365 email compromise walks through the full set of indicators, including unified audit log queries.

If you find an active invoice-fraud incident

Two paths fork here. If money has already left the account, your first calls in order are: your bank's wire-recall desk, your cyber insurance carrier's incident hotline, and the FBI's IC3 portal at ic3.gov. The 72-hour window for wire recall is real and it's tight.

If you've caught it before the wire cleared, or if you've found a compromised mailbox during routine auditing, the response is structured and the order matters. We've documented the full sequence in the 25-step data-breach response checklist on BreachShield365, which covers password resets, session revocation, audit log preservation, customer notification, and the legal/insurance touchpoints in the right order. The point of the structure is that doing step 7 before step 4 can compromise the evidence you need for the insurance claim.

Lessons-learned reading: a sibling case study on a $312,000 invoice-fraud incident at a 60-person engineering firm, and what they changed afterward, is in our BEC prevention case study. Pattern-matching against a real loss makes the controls above stop feeling like checklist items.

Where this fits in a full email security baseline

The six layers in this post stop invoice fraud specifically. They're a subset of a broader email-security baseline that covers attachment sandboxing, URL rewriting, anti-phishing for non-financial attacks, retention and journaling, and the rest of the controls a cyber insurance carrier expects to see. The full set is in our Microsoft 365 email security checklist, which sequences them by ROI for a 30 to 100-seat business.

If you suspect your tenant is already in trouble (odd alerts, unfamiliar sign-ins, missing emails, vendors complaining about messages they didn't send), work through our broader BEC prevention guide first. It assumes nothing about whether you've been compromised yet and steers the diagnostic accordingly.

Common questions

Will turning on impersonation protection and external banners break legitimate vendor email?

Some, briefly. The first two weeks after enabling impersonation protection in Aggressive mode produce a handful of false positives, usually marketing newsletters where the display name matches a protected user's name, or a sister-company email from a similar domain. Whitelist those specific senders or domains in the anti-phishing policy. By week three the signal-to-noise ratio is fine. The external banner produces zero false positives because every external sender genuinely is external. The only complaint is aesthetic.

What's the difference between BEC and invoice fraud?

Invoice fraud is a subset of BEC (business email compromise). BEC is the umbrella for any attack that uses business email to trick someone into transferring money or data. Invoice fraud is the specific BEC pattern where the bait is a fake or modified invoice. CEO-impersonation wire requests, payroll-redirect attacks ("please change my direct deposit"), and gift-card scams are also BEC, just not invoice fraud. The controls overlap heavily. Fix invoice fraud and you've fixed most BEC.

Do I need a third-party email security tool, or is M365 enough?

Microsoft 365 Business Premium plus Defender for Office 365 covers the six layers above when configured correctly. Most small businesses don't need a separate tool. Where third-party tools (Mimecast, Proofpoint, Abnormal Security) earn their keep is at the 200+ seat range, in regulated industries, or for tenants that need behavioral-AI detection of socially-engineered attacks that pass authentication. Below 200 seats, the highest-ROI move is configuring what Microsoft already gave you, not buying another product.

We have MFA on every account. Aren't we covered?

MFA prevents the password-stuffing version of mailbox compromise. It does nothing against the OAuth-consent attack pattern in Layer 5, and modern adversary-in-the-middle phishing kits like Evilginx capture both the password and the post-MFA session cookie in a single user click. MFA is necessary, not sufficient. The six layers are the actual defense. MFA is the precondition.

How long does it take to deploy all six layers?

For a tenant of 25 to 100 seats, plan on 8 to 12 hours of admin time spread across two weeks, plus a 30-day DMARC monitoring window before flipping to p=reject. The order: external banner first (low risk, immediate value), forwarding restriction second, impersonation protection third, OAuth consent fourth, DMARC monitoring/enforcement throughout, process control documented and announced last. Total elapsed calendar time about 35 days end to end.