Business email compromise: a tenant lockdown plan

Preventing business email compromise in Microsoft 365 comes down to seven controls: phishing-resistant multifactor authentication, a Conditional Access baseline that blocks legacy authentication, disabled automatic external forwarding, enforced SPF, DKIM and DMARC, Defender for Office 365 impersonation policies, mailbox auditing with alert policies, and an out-of-band verification step for every payment detail change.

The scale is documented. Australians reported $2.18 billion in combined scam losses in 2025, up 7.8% on the year before, and payment redirection, the category that covers business email compromise (BEC), accounted for $166.8 million of it, up from $152.6 million in 2024. Those figures come from the National Anti-Scam Centre's Targeting Scams report published in March 2026, which combines data from Scamwatch, ReportCyber, IDCARE, the Australian Financial Crimes Exchange and ASIC. Frontrow's separate BEC statistics guide reconciles the numbers across the official sources; this article is the build plan that follows from them.

Every technical control below is a capability Microsoft already ships inside Microsoft 365. The criminals running payment redirection scams rarely exploit anything exotic; they exploit tenants where the available protections were never turned on, and businesses where nobody has defined how a change to bank details gets verified before money moves. An IT manager with admin access can implement the six technical controls in a working week. The seventh belongs to the CFO, and it is the one that holds when everything else has been beaten.

Which MFA setup actually stops credential phishing?

Most BEC incidents start with a phished password, so the first control is making a password alone useless. Tenants created on or after 22 October 2019 generally have Microsoft Entra security defaults enabled, which require every user to register for multifactor authentication (MFA) and show a number on the sign-in screen that must be typed into Microsoft Authenticator. That number-matching step matters: it defeats the approval-fatigue tactic where criminals fire push prompts at a user until one gets accepted. Microsoft's data puts the effect of MFA plus blocking legacy authentication at stopping more than 99.9% of common identity attacks.

Standard push MFA still has a gap. Attacker-in-the-middle phishing kits proxy the real sign-in page and relay one-time codes and approvals as the victim types them. The answer is the Require authentication strength control in Conditional Access, using the built-in Phishing-resistant MFA strength: Windows Hello for Business or a platform credential, FIDO2 security keys and passkeys, or certificate-based authentication. These methods are bound to the sign-in surface, so there is nothing for a phishing kit to relay. Conditional Access needs Microsoft Entra ID P1, which Microsoft 365 Business Premium and Microsoft 365 E3 both include. Start where the damage concentrates: Microsoft provides a ready-made Conditional Access template requiring phishing-resistant MFA for administrators, and finance staff should be next in line.

What should the Conditional Access baseline block?

Legacy authentication, first. Older protocols such as IMAP, POP3 and SMTP basic authentication cannot perform MFA, which makes them the standing workaround for a criminal holding a phished password: authenticate through an old protocol and every MFA policy is bypassed. Microsoft states plainly that most compromising sign-in attempts come from legacy authentication. Security defaults block it automatically, along with device code flow, another sign-in path criminals abuse in phishing campaigns.

The risk moment is the transition. Turning off security defaults to adopt Conditional Access, then never finishing the replacement policies, leaves a tenant with neither protection. Microsoft's secure foundation templates recreate the baseline in four policies: require MFA for all users, require MFA for administrators, block legacy authentication and require MFA for Azure management. Build and enable all four before adding anything more ambitious, and exclude only the two break-glass emergency accounts every tenant should keep.

Why is automatic external forwarding the classic exfiltration channel?

When criminals get into a mailbox, one of the first moves is an inbox rule that silently forwards mail to an outside address. From that point they read invoice traffic in real time, learn who pays whom and when, and keep receiving copies even after the password is reset. Blocking automatic external forwarding removes the surveillance channel that makes convincing fake invoices possible.

The control lives in the outbound spam policy in the Microsoft Defender portal, and it has three values: on, off, and the default, Automatic - System-controlled. That default deserves attention. When it was introduced it behaved as on; in 2021 Microsoft changed it to behave as off for new organisations and for tenants that were not actively using it, but for some longstanding tenants it can still behave as on. Microsoft's guidance is to stop relying on the automatic value and configure it explicitly. Set it to Off - Forwarding is disabled. Any rule that tries to forward externally then generates a bounce with code 5.7.520, internal forwarding is untouched, and a genuine business exception can be handled per domain through remote domain settings.

What does DMARC enforcement change for a business domain?

SPF, DKIM and DMARC are DNS records that let receiving mail systems verify a message genuinely came from the domain it claims. Microsoft's guidance is direct about why they belong in a BEC plan:

The detail that separates a configured domain from a protected one is the DMARC policy value. A record with p=none only monitors; receiving systems are told to take no action when a criminal sends mail as the exact domain. Enforcement means p=quarantine, which sends failing mail to junk or quarantine, or p=reject, which refuses it outright. Microsoft's recommended path is staged: publish p=none with aggregate reporting, watch the reports until every legitimate sending service authenticates, step up to p=quarantine, then finish at p=reject. Parked domains that never send mail should go straight to p=reject. The beneficiaries are customers and suppliers, because an enforced policy stops criminals putting the business's exact domain on fake invoices sent to the people who pay them.

Does Defender for Office 365 stop executive and supplier impersonation?

DMARC cannot stop a lookalike. A criminal who registers a domain one character away from a supplier's, publishes valid SPF and DKIM records for it, then emails accounts payable will pass every authentication check. Catching that is what the impersonation protection in Microsoft Defender for Office 365 anti-phishing policies is for. User impersonation protection watches for mail posing as specific people, up to 350 protected senders per policy; the CFO, directors and the finance team belong on that list. Domain impersonation protection watches for close variants of nominated domains, covering the organisation's own accepted domains plus up to 50 custom entries, which is where major supplier domains go. Mailbox intelligence adds a contact graph, flagging senders who resemble a known contact but have never actually corresponded with the recipient.

Licensing is the part to get right. Impersonation settings are exclusive to Defender for Office 365; the built-in protection for all cloud mailboxes includes spoof intelligence but not impersonation policies. Microsoft's documentation lists Defender for Office 365 Plan 1 as included in Microsoft 365 Business Premium and Microsoft 365 E3, with Plan 2, which adds investigation, hunting and attack simulation training, included in Microsoft 365 E5. Plan 1 is the tier Microsoft positions squarely at protecting email from phishing and BEC.

Which audit and alert settings catch a compromise in progress?

Mailbox audit logging is on by default in every Microsoft 365 organisation and records the actions that matter in a BEC investigation, including UpdateInboxRules whenever an inbox rule is added, removed or changed. Confirm nobody has switched it off: Get-OrganizationConfig in Exchange Online PowerShell should show AuditDisabled as False. The audit trail is what turns a suspicious afternoon into a clear timeline of what an intruder saw and did.

Two default alert policies do the real-time watching. Creation of forwarding/redirect rule raises an informational alert whenever someone creates an inbox rule that forwards or redirects mail to another account, and Suspicious email forwarding activity raises a high-severity alert when a user has been auto-forwarding to a suspicious external address. Both ship in standard business and enterprise subscriptions. The operational step is routing: alerts sent to an unmonitored admin mailbox are alerts nobody receives, so point them at a mailbox someone actually reads and treat the high-severity one as a same-day investigation.

What is the one control that works when everything else fails?

A supplier's mailbox gets compromised at their end, and the payment-detail change arrives from the genuine address, passing SPF, DKIM, DMARC and every impersonation check, sitting in a thread with months of real history. No security setting in any tenant can label that email as fraudulent, because as email it is authentic. This is why BEC is a payments fraud problem wearing an IT costume, and why the strongest control in this plan is a finance procedure.

• No change to a supplier's bank details is actioned on email alone. Someone phones the supplier on a number already held on file, never a number taken from the email or its signature block, and confirms the change before a dollar moves.
• The same callback applies to new supplier onboarding and to any urgent payment request that claims to come from an executive. Urgency is the tell, not a reason to skip the check.
• Payments above an agreed threshold require two approvers, so one convincing email can never move serious money on its own.
• The procedure is written down, owned by the CFO or finance lead, and communicated to suppliers so their staff expect the call.

The verification call costs two minutes and works in the exact scenario where every technical layer has already been beaten.

How does the lockdown week run?

1. 1Day one, baseline: confirm whether the tenant runs security defaults or Conditional Access, check the automatic forwarding value in the outbound spam policy, review the Auto forwarded messages report, list DKIM and DMARC records for every sending domain, and verify mailbox auditing is still on.
2. 2Day two, cut the exfiltration channel: set automatic external forwarding to off, handle legitimate forwarding through remote domain exceptions, and investigate anything unexpected found in the report.
3. 3Day three, identity: enable the four baseline Conditional Access policies, or confirm security defaults are doing that work, and apply phishing-resistant MFA to administrators with finance staff scheduled next.
4. 4Day four, mail protection: populate the Defender for Office 365 impersonation lists with executives, finance staff, owned domains and key supplier domains, and turn on the mailbox intelligence impersonation action.
5. 5Day five, domains and alerts: publish or step up DMARC along the enforcement path, confirm DKIM signing for every sending domain, and route the two forwarding alert policies to a monitored mailbox.
6. 6With the CFO, any day this week: sign off the payment verification procedure and communicate it to the finance team and to suppliers. It needs no licence and no deployment.

Frontrow runs this as a fixed-scope hardening engagement for Australian businesses: the tenant baseline, the six technical controls configured and evidenced, and a payment verification procedure the finance team will actually follow, with the whole exercise documented for insurers and auditors.