Email Security in Microsoft 365: A UK Business Guide to Stopping Phishing, Spoofing and Business Email Compromise in 2026

Microsoft 365 email security is the set of tenant configuration decisions, domain authentication records and human controls that determine whether a fraudulent email reaches a UK employee’s inbox and whether that employee acts on it. It is not a product you buy, and it is not switched on by default. A Microsoft 365 tenant provisioned out of the box will block the overwhelming majority of commodity spam and known malware, because Exchange Online Protection is genuinely good at that job. What it will not reliably stop is the small, targeted, text-only message from a supplier’s genuinely compromised mailbox asking you to update their bank details — and that is the message that costs UK businesses the most money.

This guide starts with how business email compromise actually works, because almost every control decision that follows only makes sense once you understand the attack it is defending against. From there it works through the domain authentication trio of SPF, DKIM and DMARC in the level of detail needed to actually get to an enforcing policy without breaking your own mail; the Entra ID Conditional Access policies that stop a stolen password and a stolen session token turning into a month of silent mailbox access; the mailbox rule and audit log forensics that reveal a compromise you would otherwise never see; the Defender for Office 365 policies that are worth the licence and the ones that are theatre; and the staff-facing controls — external tagging, reporting buttons, callback verification — that close the gap the technical controls structurally cannot. There is a twelve-point hardening checklist, a costed 2026 UK licensing breakdown, a ninety-day implementation timeline and an honest list of the mistakes that leave a tenant looking secure on a dashboard while remaining trivially exploitable in practice.

What business email compromise actually is — and why it is not phishing

The two terms get used interchangeably and they describe different problems with different solutions. Phishing, in the classic sense, is a message designed to harvest something: credentials, a session token, a card number. It has a payload — a link to a fake sign-in page, an attachment, a QR code — and because it has a payload, it has something a security filter can detect. Sandboxes can detonate the attachment, URL rewriting can check the destination at click time, and reputation systems can score the sending infrastructure. Phishing is a technical problem with meaningful technical answers, and Microsoft 365 with a properly configured anti-phishing policy handles a great deal of it.

Business email compromise is a fraud problem wearing an email costume. The message is usually plain text. It contains no attachment, no link, no malware, and often no urgency markers a filter would recognise. It asks a person with payment authority to do something that person is entirely authorised to do — pay an invoice, update a bank record, process a payroll change, release a deposit. From the filter’s perspective there is nothing wrong with it, because there is nothing technically wrong with it. The fraud lives entirely in the identity of the sender and the legitimacy of the request, and neither of those is a property a mail gateway can inspect.

That distinction has a direct consequence for how you spend money and effort. Buying a higher Defender tier will measurably reduce your exposure to malware and credential phishing. It will do considerably less for BEC, because BEC frequently arrives from a real, reputable, fully authenticated mailbox — your supplier’s — that has itself been compromised. The sending domain passes SPF. The signature passes DKIM. The DMARC alignment is perfect, because the mail genuinely originated from the domain it claims. Every technical authentication signal you have deployed reports green, and the mail is fraudulent anyway. Defending against that requires controls at the process layer, not the gateway layer, and this guide treats both as first-class.

The five BEC patterns UK businesses actually encounter

Fraud reported to Action Fraud and tracked by UK Finance under the heading of authorised push payment fraud and mandate fraud is not a single technique. In practice, UK organisations encounter five recognisable patterns, and the defences differ meaningfully between them. Understanding which ones your organisation is realistically exposed to prevents you from spending the entire budget defending against the pattern that gets the most press coverage rather than the one most likely to reach your finance team.

Mandate fraud, also called supplier bank detail fraud, is the expensive one. An email arrives from a supplier — frequently from their real, compromised mailbox, sometimes from a lookalike domain — advising that their bank details have changed and asking that future payments go to a new account. The message often references a genuine outstanding invoice by number, because the attacker has been reading the mailbox for weeks and knows exactly what is owed and when it falls due. The payment is authorised by a person who believed they were following a legitimate instruction, which is precisely why recovery through the banking system is so difficult: the payment was authorised, and the reimbursement rules for authorised push payment fraud were built around consumers rather than businesses.

CEO fraud, or executive impersonation, is the pattern most people picture. A message purporting to come from the managing director, finance director or a senior partner asks a junior member of the finance team to make an urgent payment, buy vouchers, or handle something confidential outside the usual process. The sending address is typically a free webmail account with the executive’s display name set, or a domain one character different from yours. It relies on hierarchy and urgency rather than technical sophistication, and it is disproportionately effective in organisations where the finance team would find it socially awkward to question the founder.

Payroll diversion targets HR rather than finance. An email that appears to come from an employee asks to change the bank account their salary is paid into, timed to arrive shortly before the payroll cut-off so there is no time for a leisurely check. The individual amounts are smaller than mandate fraud, but the attack is repeatable across an employee list and frequently goes unnoticed until the affected employee reports a missing salary — by which point the funds are gone.

Vendor email compromise and conversation hijacking is the most technically capable version. Having gained access to a mailbox, the attacker does not send anything immediately. They read. They set up a rule that quietly files replies from a particular counterparty into an obscure folder, they learn the tone and the schedule, and then they insert themselves into an existing legitimate thread — replying to a real conversation, quoting real history, from the real address. There is no impersonation to detect because there is no impersonation happening. This is the pattern that domain authentication cannot address at all.

Gift card and credential-harvest hybrids round out the list. Lower value, higher volume, and frequently the opening move rather than the objective: a harvested credential from a marketing coordinator is not valuable in itself, but it is a foothold from which internal mail can be sent, and internal mail is trusted far more readily than external mail by both people and, in badly configured tenants, by the transport rules themselves.

Where Microsoft 365 tenants actually fall short

Across tenant assessments the same gaps recur with striking consistency, and they cluster into three groups: identity controls that were never completed, domain authentication that was started and abandoned at monitoring stage, and detection capability that exists in the licence but was never configured or is not being read by anybody. The grid below is a reasonable self-assessment starting point — work down each column and mark honestly rather than aspirationally, because the gap between what an organisation believes is configured and what is actually enforced is the single most common finding in this work.

Two rows in that grid deserve particular attention because they are so frequently misjudged. The first is “DMARC aggregate reports actually being read”. Publishing a DMARC record with a rua address that nobody monitors is worse than useless: it creates the paperwork of a control without the function of one, and it means you will never discover the legitimate sending service that has been failing authentication for eight months. The second is “alert destination is a monitored mailbox”. A remarkable number of tenants route their security alerts to a shared mailbox that a departed IT manager configured and nobody has opened since. The alert fires exactly as designed, and it lands in a room with nobody in it.

Microsoft 365 email security by the numbers

The figures below are drawn from Cloudswitched tenant assessments of UK small and medium businesses and from the published UK Government Cyber Security Breaches Survey, which has consistently found phishing to be the most commonly identified attack type against UK organisations year after year. They are a starting point for framing your own risk rather than a substitute for looking at your own tenant — the useful exercise is to run the equivalent numbers for your own organisation and see where you sit.

The first of those cards is the one worth sitting with. The controls that do the most to reduce email fraud exposure in a Microsoft 365 tenant — enforcing multi-factor authentication on every account, blocking legacy authentication protocols that bypass it, publishing an enforcing DMARC policy, restricting user consent to third-party applications, and switching on alerting for suspicious inbox rules — are all included in licences you already hold. They cost configuration time, not licence spend. Organisations routinely defer them while evaluating a paid product that addresses a narrower slice of the problem, and the deferral is where the exposure lives.

Default tenant versus hardened tenant — what actually changes

It is worth being concrete about the difference between a Microsoft 365 tenant as it arrives and one that has been through a deliberate hardening exercise, because the gap is not a matter of degree. The two columns below describe the same licence, the same mailboxes and the same users. The only difference is configuration, and almost every line in the right-hand column is achievable within the Business Premium licence that a large proportion of UK SMEs already pay for.

The bottom row is the one that determines the financial outcome. In a default tenant, the organisation almost always learns about a mailbox compromise from outside: a supplier phones to ask why they received a strange invoice, or a customer reports that a payment went to an account nobody recognises. By then the attacker has had weeks of access and the money has moved. In a hardened tenant the malicious inbox rule — which the attacker creates almost immediately, because hiding replies is essential to the fraud — generates an alert on the day it is created, and the investigation starts before the fraudulent request is ever sent. The technical difference between those two scenarios is a single alert policy that costs nothing to enable.

How UK businesses are actually attacked

The distribution below reflects the initial access and fraud vectors observed across UK SME email security incidents and tenant assessments. It matters because defensive effort tends to be allocated according to how frightening a technique sounds rather than how often it is actually used, and the two orderings are not the same. Malware-bearing attachments, which absorb a disproportionate share of security conversation, sit well down the list against a Microsoft 365 estate; credential capture and plain-text social engineering dominate.

The fourth row is the one that has changed most in the last two years and the one most organisations have not adjusted for. Adversary-in-the-middle phishing works by placing a reverse proxy between the victim and the genuine Microsoft sign-in page. The user sees a real Microsoft login, enters real credentials, completes a real MFA prompt on their real phone — and the proxy captures the resulting session cookie. The attacker replays that cookie and is inside the mailbox without ever needing the password again. Standard multi-factor authentication does not stop this, which is the uncomfortable point: MFA remains essential and it is no longer sufficient on its own for high-value accounts.

The defences that do address token theft are specific. Phishing-resistant authentication methods — FIDO2 security keys, Windows Hello for Business, or passkeys — break the attack because the cryptographic assertion is bound to the genuine domain and simply will not be produced for the proxy. Conditional Access policies that require a compliant or Entra-joined device mean a replayed cookie from an unmanaged machine is refused regardless. Continuous Access Evaluation shortens the window in which a stolen token remains usable by revoking it in near real time when risk conditions change. Sign-in risk policies in Entra ID P2 catch the impossible-travel and anomalous-session signals that a replayed cookie generates. None of these are exotic; all of them require a deliberate decision to configure.

SPF, DKIM and DMARC — getting to enforcement without breaking your mail

Domain authentication is where most organisations start, and it is where most organisations stop halfway. The three records work as a system and none of them is useful in isolation, so it is worth understanding precisely what each one does before touching DNS. Done properly, the outcome is that nobody on the internet can send mail claiming to come from your domain and have it accepted. Done as far as most organisations take it, the outcome is a DMARC record at p=none that tells the world your domain may be freely spoofed and asks politely for a report about it.

That figure understates the problem, because it counts only primary sending domains. Parked domains, old trading names, domains acquired with a business and domains registered defensively years ago are almost never covered, and an unprotected parked domain is an excellent spoofing platform precisely because it is genuinely yours and genuinely associated with your organisation.

SPF — who is allowed to send

The Sender Policy Framework is a DNS TXT record listing the servers permitted to send mail on behalf of your domain. A receiving server checks the IP address of the connecting host against that list. For a straightforward Microsoft 365 tenant the record is short: v=spf1 include:spf.protection.outlook.com -all. The complications arrive with every additional service that sends on your behalf — a marketing platform, an accounting package emailing invoices, a helpdesk system, a CRM, a payroll provider — each of which wants its own include.

Two details cause most real-world SPF failures. The first is the ten DNS lookup limit: SPF evaluation is capped at ten nested lookups, and every include consumes at least one, often more, because vendor includes nest further includes of their own. Exceed the limit and the result is a permanent error, which many receivers treat as a failure — so the record you added to improve deliverability starts harming it. Audit the record with an SPF checker that reports the lookup count, and remove includes for services you no longer use, which is usually where the headroom comes from. Resist the temptation to flatten the record into raw IP addresses: it works today and breaks silently the next time your vendor changes infrastructure.

The second is the choice between -all (hard fail) and ~all (soft fail). Soft fail is the cautious option and it is the right place to start while you are still discovering senders, but it is not a destination. Leave it at soft fail permanently and you are telling receivers that mail from unlisted sources is suspicious but probably fine. Move to hard fail once your DMARC reports show no legitimate senders failing for a couple of weeks.

DKIM — proving the message was not altered

DomainKeys Identified Mail adds a cryptographic signature to the message header, covering selected headers and the body. The receiving server retrieves your public key from DNS and verifies the signature. If it validates, the message genuinely originated from a system holding your private key and has not been modified in transit. In Microsoft 365 this is enabled per domain in the Defender portal, and it requires two CNAME records — conventionally selector1 and selector2 — pointing at Microsoft’s key infrastructure. The two selectors exist so that keys can be rotated without an outage.

Three points are routinely missed. Custom domains do not have DKIM enabled automatically — the tenant signs with the onmicrosoft.com domain by default, which produces a valid signature that does not align with your visible From address and therefore does not satisfy DMARC. Key length matters: older tenants may still be signing with 1024-bit keys and should be rotated to 2048-bit. And every third-party service that sends on your behalf needs its own DKIM configuration in that vendor’s portal, with its own selector; SPF alone will not carry them through DMARC alignment reliably, particularly once forwarding is involved.

DMARC — the policy that ties the two together

DMARC is the record that makes SPF and DKIM meaningful, and understanding alignment is the key to understanding DMARC. SPF validates the envelope sender — the Return-Path — which the recipient never sees. DKIM validates the signing domain, which the recipient also never sees. The domain a human reads is the From header. DMARC requires that at least one of SPF or DKIM both passes and matches the From header domain. That alignment requirement is what closes the gap: without it, an attacker can pass SPF for their own throwaway domain while displaying yours in the From field.

A DMARC record is a TXT record at _dmarc.yourdomain.co.uk. The policy tag p= takes three values: none (take no action, just report), quarantine (treat failures as suspicious, typically junk them) and reject (refuse them outright at the SMTP conversation). The rua= tag specifies where aggregate XML reports are delivered. The sp= tag sets policy for subdomains, and matters more than it appears — attackers routinely target subdomains precisely because sp= is left unset and inherits weakly in some implementations. Set it explicitly.

The migration to enforcement follows a well-established sequence and it should not be rushed, because the failure mode of moving too quickly is that your own invoices stop being delivered. Publish at p=none with a rua address pointed at a reporting service that renders the XML into something readable. Spend two to four weeks identifying every legitimate sender in those reports — and there will be more than you expect, because departments procure email-sending services without telling IT. Fix each one by adding the SPF include and configuring DKIM at the vendor. When the reports show clean alignment, move to p=quarantine, optionally with pct= set to ramp gradually. Watch for a further two weeks, then move to p=reject. Ninety days is a comfortable timeline for an organisation of any size; the constraint is discovering senders, not changing DNS.

Two adjacent standards are worth adding once DMARC is enforcing. MTA-STS publishes a policy asserting that mail to your domain must be delivered over authenticated TLS, which defends against downgrade attacks on inbound mail; TLS-RPT gives you reporting on delivery failures against that policy. Both are supported by Microsoft 365 and both are a DNS record plus, for MTA-STS, a policy file served over HTTPS. They are a sensible afternoon’s work once the core three are enforcing, and they are increasingly expected in supply-chain security questionnaires.

Conditional Access — the policies that actually reduce email fraud

Conditional Access is the Entra ID policy engine that evaluates every sign-in against conditions you define and decides whether to allow it, block it, or require something additional. It is the single most effective set of controls available in a Microsoft 365 tenant, and it is also the one most likely to be half-configured, because policies are easy to create and their interactions are easy to get wrong. The guidance below is a practical baseline rather than an exhaustive catalogue.

Start with security defaults, then graduate away from them. Security defaults enforce MFA registration and blocks legacy authentication for the whole tenant with no configuration, and for a very small organisation with no complexity they are a reasonable place to be. They are also all-or-nothing: you cannot exclude a service account, cannot vary requirements by role, and cannot layer device conditions. The moment you need any exception, you must turn security defaults off and rebuild the equivalent protections as explicit Conditional Access policies — and the dangerous window is the period between switching security defaults off and finishing the policy build. Build the policies in report-only mode first, verify them against sign-in logs, then enable them and disable security defaults in the same change window.

Require MFA for all users, with no permanent exclusions. The exception list is where this control dies. Service accounts, shared mailboxes with sign-in enabled, the finance director who travels, the scanner that emails PDFs — each exclusion is individually defensible and collectively fatal, because an attacker only needs one. Shared mailboxes should have sign-in blocked entirely and be accessed through delegation. Devices that send mail should use SMTP AUTH scoped to a single mailbox with a dedicated account, not an exclusion from MFA on a licensed user. Where an exclusion is genuinely unavoidable, it should be documented, time-limited, and compensated for with a location restriction.

Block legacy authentication explicitly. Basic authentication for most Exchange Online protocols was retired by Microsoft, but the picture is not as clean as it sounds: SMTP AUTH remains available and is frequently enabled tenant-wide, and legacy clients still attempt POP and IMAP. Legacy protocols do not support modern authentication, which means they do not support MFA, which means a valid username and password is sufficient. A password spray against a tenant with legacy protocols enabled will find the one account with a weak password, and no MFA prompt will ever be raised. Create an explicit Conditional Access policy blocking legacy authentication clients, and separately disable SMTP AUTH at tenant level, enabling it per-mailbox only where a specific device genuinely needs it.

Add device and location conditions for privileged and finance roles. Requiring a compliant or hybrid-joined device for global administrators, and for the handful of accounts with payment authority, is the control that defeats replayed session tokens. An attacker with a stolen cookie is operating from their own infrastructure on their own machine; a device compliance requirement refuses that session regardless of how valid the token is. Where full device management is not in place, a policy that blocks sign-ins from countries the organisation does not operate in is a coarser but genuinely useful substitute — it will not stop a determined attacker using a UK proxy, but it eliminates a large volume of opportunistic access.

Restrict user consent to third-party applications. The illicit consent grant attack does not need a password at all. The user receives a link to a genuine Microsoft consent prompt for an application with an innocuous name, clicks Accept, and grants an attacker-controlled application persistent, token-based access to read their mail. MFA does not apply, a password change does not revoke it, and the access survives until someone finds and removes the application from the tenant. Set user consent to require administrator approval, or at minimum restrict it to verified publishers and low-impact permissions, and enable the admin consent workflow so legitimate requests have a route through. Review enterprise applications periodically for anything nobody recognises.

Protect the break-glass account properly. Every Conditional Access deployment needs at least one emergency access account excluded from the policies, or you will eventually lock yourself out of your own tenant. That account should have a long random password stored offline, no MFA method that depends on a phone that might be lost, a name that does not advertise its function, and — critically — an alert that fires the moment it signs in. An excluded, unmonitored, permanently valid global administrator account is otherwise the most attractive target in the tenant.

Defender for Office 365 — what is worth configuring

Every Microsoft 365 tenant includes Exchange Online Protection, which handles connection filtering, anti-spam, anti-malware and the transport rule engine. Defender for Office 365 sits on top of it and comes in two plans, with Plan 1 included in Business Premium and Plan 2 in E5 or as an add-on. The distinction between what EOP gives you free and what the Defender plans add is worth understanding before a renewal conversation.

The anti-phishing policy is the highest-value item and it is not configured by default. Impersonation protection lets you name the individuals most likely to be impersonated — the managing director, the finance director, anyone who can authorise a payment — and the domains you trade with most closely. Microsoft then applies additional scrutiny to messages that appear to come from those names and domains but do not. Mailbox intelligence builds a picture of each user’s normal correspondents and flags deviations, which is one of the few automated signals with any purchase on conversation hijacking. Both need explicit configuration; a protected-users list with nobody on it protects nobody.

Safe Links and Safe Attachments handle the payload side. Safe Links rewrites URLs so they are checked at click time rather than delivery time, which matters because a link that was benign when the mail arrived is frequently weaponised hours later specifically to evade delivery-time scanning. Safe Attachments detonates attachments in a sandbox before delivery. Both add latency and both are worth it. Configure Safe Links for Teams and Office applications as well as email — attackers moved to Teams messages and shared documents as soon as email links became reliably inspected.

Preset security policies are the pragmatic starting point. Rather than tuning dozens of individual settings, apply the Standard or Strict preset to all users and let Microsoft maintain the values. Strict is more aggressive about quarantining and generates more false positives; Standard is appropriate for most organisations, with Strict applied to the specific high-risk users. Then run the Configuration Analyzer, which compares your actual settings against the preset baselines and lists every deviation. It is the fastest available answer to “what is wrong with our configuration” and it takes minutes.

Zero-hour Auto Purge retroactively removes messages from mailboxes when a verdict changes after delivery. It is on by default and it is one of the genuinely valuable automatic behaviours — the phishing campaign delivered at 08:00 and identified at 08:40 is pulled from every inbox that received it, including the ones already read. Confirm it has not been disabled, and confirm that mail flow rules do not bypass filtering in ways that neutralise it.

Attack simulation training, included with Plan 2, runs controlled phishing simulations against your own staff and assigns training to those who click. Used well, it produces a measurable baseline and a downward trend in click rate. Used badly — as a mechanism for embarrassing individuals, or with simulations so cruel that staff stop trusting internal communications entirely — it damages the reporting culture you actually depend on. The metric worth optimising is not click rate but report rate: the objective is staff who tell you quickly, not staff who never make a mistake.

One structural warning applies to all of the above. Mail flow rules that bypass filtering for a specific sender, domain or IP range — usually created to fix a deliverability complaint from a supplier or a marketing platform — punch a hole straight through every control described in this section. An attacker who compromises that supplier inherits an allow-list entry into your organisation. Audit mail flow rules for bypass conditions at least annually, use the Tenant Allow/Block List with expiry dates rather than permanent transport rules, and document why each exception exists.

A ninety-day hardening programme

The sequence below reflects how this work is actually delivered against a live tenant where people still need to send and receive mail every day. It is deliberately ordered so that the controls with the highest impact and lowest breakage risk land first, and the changes with real potential to disrupt legitimate mail flow — DMARC enforcement in particular — happen only after the evidence to support them has been gathered. A single-site organisation of thirty to eighty people completes this comfortably in ninety days alongside normal work.

Note where the process work sits. It is last in the sequence but it is not least in importance — it is last because it is the control that continues to function when every technical control has been legitimately satisfied by a fraudulent message. If you have limited capacity and can only complete part of this programme, the identity baseline in days 10–30 and the payment verification process in days 75–90 are the two blocks that deliver the most protection per hour invested.

Scoring your tenant — where a typical UK SME sits

The benchmark below aggregates tenant assessment scoring across identity controls, domain authentication, filtering configuration, detection capability and documented process. It is not Microsoft Secure Score, which is a useful but noisy measure heavily weighted towards licence-gated features; this scoring weights the controls by their observed contribution to preventing an actual email fraud loss in an SME context.

A score in the low fifties has a consistent shape and it is not the shape most people expect. Filtering scores well — Microsoft’s defaults are strong and the marginal gain from tuning is modest. Identity scores moderately: MFA is usually present but with exclusions, and legacy authentication is usually still reachable. Domain authentication scores poorly, dragged down by DMARC stuck at monitoring and by uncovered parked domains. Detection scores worst of all, because alert policies are either absent or firing into an unmonitored mailbox. Process scores are bimodal — organisations either have a real payment verification procedure or they have nothing at all, with very little middle ground.

The encouraging conclusion is that the deficit is almost entirely configuration and procedure rather than capital expenditure. Organisations scoring above eighty are rarely the ones spending the most on security licensing; they are the ones that finished the configuration work, wrote down the process, and put a named person in front of the alerts. If you are considering where a fractional technology leadership function adds value, this is a representative example — the work is not difficult, but it needs someone whose job it is to see that it is finished. Our guide on when a UK SME needs a virtual CIO covers how that role is typically scoped.

Mailbox rule auditing and compromise forensics

If you take one operational practice from this guide, make it this one. When an attacker gains access to a mailbox, they need to solve a problem: the legitimate owner is still reading that mailbox and will notice replies to messages they never sent. The universal solution is a mail rule. Almost every mailbox compromise involves the creation of an inbox rule within minutes of first access, and that rule is the most reliable detection signal available.

The rules follow recognisable patterns. The classic form moves messages containing keywords such as invoice, payment, bank, remittance or BACS straight to a folder the user never opens — RSS Feeds and Conversation History are perennial favourites — and often marks them read. A variant forwards all mail to an external address, giving the attacker continued visibility after the password is changed. A subtler variant filters on a specific counterparty’s domain, so that only the conversation being hijacked is hidden and everything else behaves normally. Some rules delete rather than move, which is harder to spot and more damaging. A rule named with a single character or a space is not a coincidence; it is an attempt to be invisible in the Outlook rules list.

The alerts to configure

Microsoft Purview provides alert policies that cover the important cases, and the ones worth enabling explicitly are: creation of a forwarding or redirect inbox rule, suspicious email sending patterns, a user restricted from sending mail, unusual volume of external file sharing, and elevation of Exchange administrative privilege. Several exist by default but with the destination unset or pointed at a distribution group nobody reads. Configure each one to deliver to a mailbox with a named owner, then deliberately trigger one to prove the path works end to end. An untested alert path is an assumption, not a control.

Alongside alerting, disable automatic external forwarding as the default posture. The outbound spam filter policy controls this and the modern default is to block automatic forwarding, but tenants that have been running for years frequently carry an older setting or a mail flow rule that permits it. Where a genuine business need for external forwarding exists — and it occasionally does — it should be an explicit, documented, reviewed exception rather than a tenant-wide permission.

Reading the audit log

The unified audit log is where an investigation actually happens, and it is worth confirming three things before you need it: that it is switched on, what your retention period actually is under your licence, and who has the permissions to search it. Retention is the detail that catches organisations out. Standard audit retention covers a period measured in months rather than years, and BEC dwell times are frequently long enough that the earliest evidence has already aged out by the time anybody investigates. If your regulatory position or your risk appetite requires longer, that is a licensing decision to make before an incident rather than during one.

In an investigation, the operations that matter are the mailbox rule events (New-InboxRule and Set-InboxRule), the mailbox permission changes, the sign-in records with their IP addresses and user agents, the consent grants to enterprise applications, and — where your licensing includes it — the MailItemsAccessed records that show which messages were actually read. That last one is the difference between telling the ICO “an attacker had access to this mailbox for six weeks and we cannot say what they read” and being able to scope the personal data exposure precisely. Under UK GDPR, a personal data breach must be reported to the ICO without undue delay and where feasible within 72 hours of becoming aware of it, and the quality of that notification depends almost entirely on the audit evidence you retained beforehand.

The compromise runbook

When a mailbox compromise is confirmed, the order of operations matters. Revoke the user’s active sessions first — a password reset alone does not invalidate an existing session token, and an attacker holding a valid cookie retains access straight through the reset. Then reset the password, re-register MFA methods from scratch in case an attacker method was added, and block sign-in temporarily if the situation warrants it. Enumerate and remove malicious inbox rules and forwarding. Check delegate and mailbox permissions for additions. Review consented enterprise applications. Search the audit log for the full access window and identify every counterparty the attacker corresponded with. Notify those counterparties directly — by telephone, not email — because your compromised mailbox is now the origin of their mandate fraud attempt. Finally, assess the personal data exposure for ICO notification, and report the fraud to Action Fraud.

What Microsoft 365 email security actually costs

Licensing is where a great deal of confusion — and a certain amount of unnecessary spend — occurs. The table below sets out the realistic options for a UK SME, with approximate per-user monthly list prices at the time of writing on annual commitment terms. Microsoft adjusts list pricing periodically and applies different rates to monthly-commitment terms, so confirm current figures against your own agreement before budgeting; the relative positioning of the tiers is the durable part.

Two observations from doing this repeatedly. First, the step from Business Standard to Business Premium is the highest-value licensing decision available to a UK SME, and it is frequently declined on the basis of the headline difference without accounting for what it replaces — Entra ID P1 and Intune purchased separately cost considerably more than the increment. Second, adding a third-party gateway to an unconfigured tenant is the most expensive way to buy the least protection. The gateway inspects inbound mail; it does not enforce MFA, does not block legacy authentication, does not publish DMARC and does not alert on inbox rules. Configure the tenant first, then decide whether a gateway adds anything the configured tenant does not already do.

Set against those figures, the cost of the event being avoided is the relevant comparison. A single successful mandate fraud on a mid-sized invoice is a five-figure loss that is rarely recovered, before counting the investigation time, the ICO notification if personal data was in the mailbox, the supplier relationship damage and the insurance excess. Cyber insurance policies increasingly ask direct questions about MFA coverage and email authentication at renewal, and a materially inaccurate answer on a proposal form is a poor position to be in when claiming. If you are working towards Cyber Essentials certification, much of the identity work described here maps directly onto the scheme’s requirements, which makes it efficient to run the two exercises together.

Staff-facing controls — closing the gap filters cannot

Every control described so far operates on the message. The remaining exposure operates on the person, and it needs controls designed for people rather than for mail servers. The organisations that avoid losses are not the ones with the most perceptive staff; they are the ones that removed the need for perceptiveness by making the fraudulent instruction fail at a process step regardless of how convincing it was.

The payment verification rule is the single highest-value control in this entire guide. Written down, it is one sentence: any change to a supplier’s bank details, and any payment above an agreed threshold to a new account, is verified by telephone to a number already held on file — never a number contained in the email requesting the change — before the payment is released. The clause that does the work is “already held on file”. Attackers supply a phone number in the fraudulent email precisely because they expect a callback, and a callback to the attacker’s number confirms the fraud beautifully. If your telephony has moved to a hosted platform, the direct-dial numbers held on supplier records should be re-verified after that migration; our guide to the PSTN switch-off and VoIP migration covers why number continuity matters operationally, and it matters here for exactly this reason.

The rule needs three supporting elements to survive contact with a busy month-end. It needs a named second authoriser above a threshold, so no single person can release a large payment alone. It needs explicit, repeated permission from the senior team for finance staff to delay a payment while they verify it — the reason CEO fraud works is that a junior finance assistant is more afraid of annoying the managing director than of the fraud, and only the managing director can fix that. And it needs to apply to the managing director too, visibly, because a rule with an exception for the person most likely to be impersonated is not a rule.

External sender tagging is a small change with a real effect. Microsoft 365 can mark messages from outside the organisation with a native tag in Outlook, and a transport rule can prepend a visible banner to the message body for clients that do not honour the native tag. When a message claiming to be from the finance director carries an external marker, the contradiction is visible without the recipient needing to inspect a header. Keep the banner short and do not apply it to everything, including partner domains you communicate with constantly — a banner on ninety per cent of mail is wallpaper within a fortnight.

Give staff a one-click report button and read what they send. The built-in Report button in Outlook submits directly to Microsoft and, where configured, to your own reporting mailbox. It is materially better than asking people to forward suspicious mail, which loses headers and risks the recipient interacting with the payload. The critical half of this control is the response: someone must review submissions and reply to the reporter, even briefly, even when the message was harmless. A user who reports three messages and hears nothing back stops reporting, and you have lost your best sensor for the attacks that got through the filters.

Train for the specific fraud, not for generic awareness. Annual computer-based training on identifying phishing produces a compliance record and very little behaviour change. What works is short, role-specific and repeated: fifteen minutes with the finance team on mandate fraud, using a real example, focused entirely on the callback rule; fifteen minutes with HR on payroll diversion; fifteen minutes with anyone holding an executive assistant role on how their principal actually communicates. Measure the reporting rate rather than the click rate, and treat a rising report rate as the success signal it is.

Email controls also sit within a wider architecture. A compromised mailbox on a device with unrestricted access to the internal network is a materially worse outcome than the same compromise on a segmented network; if you are reviewing this end of the estate, our guide to network segmentation for UK SMEs covers the containment side of the same problem.

Benchmarks — what is actually configured in UK SME tenants

The distribution below is drawn from Microsoft 365 tenant assessments of UK organisations between roughly ten and three hundred seats. The pattern is the useful part rather than any individual figure: coverage is high on the controls that are visible and enabled by default, and falls away sharply on the controls that require someone to make a deliberate decision and finish a piece of work.

Read that list from the bottom up and it describes the anatomy of a successful business email compromise almost exactly. There is no documented payment verification process, so a fraudulent instruction is actioned. Nobody is alerted when the attacker creates an inbox rule, so the compromise runs undetected for weeks. User consent is unrestricted, so a malicious application retains access after the password is changed. DMARC is at monitoring, so the domain can be spoofed. The controls at the top of the list — the ones with high coverage — are all present in the organisations that lose money, which is precisely why they are not the ones to measure yourself against.

Common Microsoft 365 email security mistakes

These are the findings that recur most often in assessments, ordered roughly by how much damage they enable relative to how easy they are to fix. None of them requires additional licensing to correct.

• Leaving DMARC at p=none indefinitely. The record exists, the security questionnaire is answered truthfully, and the domain remains freely spoofable. A monitoring policy is a stage in a project, not a destination. If nobody is reading the aggregate reports it is not even that.
• MFA with a standing exclusion list. Every exclusion is individually reasonable and the aggregate is a bypass. Service accounts, shared mailboxes with sign-in enabled and “temporary” exceptions that have outlived the person who requested them are where attackers find their way in.
• Assuming MFA defeats phishing. Adversary-in-the-middle proxies capture the session token after a successful MFA prompt. MFA remains essential; for privileged and finance accounts it needs to be paired with device compliance requirements or phishing-resistant methods.
• Alerts routed to an unmonitored mailbox. The alert policy is enabled, the dashboard is green, and the notifications have been accumulating unread in a shared mailbox since the last IT manager left. Trigger every alert path deliberately and confirm a human receives it.
• Mail flow rules that bypass filtering. Created to resolve a deliverability complaint and never removed, these punch a permanent hole through every filtering control for a specified sender — who may themselves be compromised later. Use expiring entries in the Tenant Allow/Block List instead.
• Ignoring parked and legacy domains. The old trading name, the acquired company’s domain, the defensive registrations: none of them send mail, none of them have DMARC, and all of them are credible spoofing platforms because they genuinely belong to you. Publish a null SPF and a reject policy on every one.
• Unrestricted third-party application consent. An illicit consent grant survives a password reset and is unaffected by MFA. Restricting consent and enabling the admin approval workflow takes ten minutes and closes an entire attack class.
• Treating a gateway purchase as the programme. An additional filtering layer in front of an unconfigured tenant leaves identity, authentication, detection and process untouched — which is to say, it leaves the BEC exposure almost entirely intact while creating the impression that it has been addressed.

The twelve-point Microsoft 365 email security checklist

Work through these in order. The sequence is deliberate: the early items are low-risk and high-impact, and the later items depend on evidence gathered by the earlier ones. Each is achievable within a Business Premium licence and most are achievable on Business Basic.

1. Enforce MFA on every account, including administrators, with no permanent exclusions. Block sign-in on shared mailboxes and access them by delegation. Document and time-limit any exception you genuinely cannot avoid.
2. Block legacy authentication with an explicit Conditional Access policy and disable SMTP AUTH at tenant level, enabling it per-mailbox only for devices that demonstrably require it.
3. Restrict user consent to third-party applications and enable the admin consent workflow. Review the existing enterprise application list and remove anything nobody can account for.
4. Create and protect a break-glass administrator account with an offline credential, exclusion from Conditional Access, and an alert that fires on every sign-in.
5. Require a compliant or Entra-joined device for privileged and payment-authorising accounts, or where device management is not in place, restrict sign-in to the countries you operate in.
6. Publish DMARC at p=none with a monitored rua address on every domain you own, then work the aggregate reports weekly until every legitimate sender aligns.
7. Correct SPF for the ten-lookup limit and enable DKIM for every custom domain in the tenant and at every third-party service that sends on your behalf.
8. Move DMARC to p=quarantine and then p=reject, set an explicit sp= tag for subdomains, and publish null SPF plus reject policies on parked and non-sending domains.
9. Apply the Standard preset security policy to all users and Strict to executives and finance, then populate the anti-phishing impersonation list with named individuals and key trading domains.
10. Enable alert policies for inbox forwarding rules and suspicious sending patterns, route them to a mailbox with a named owner, and test each path by triggering it deliberately.
11. Enable external sender tagging and deploy the built-in Report button, and nominate a person responsible for reviewing submissions and replying to the reporter.
12. Write down the payment verification process — callback to a number already on file, second authoriser above a threshold, no exceptions for seniority — brief finance and HR specifically, and rehearse the mailbox compromise runbook.

A mini case study — how a mandate fraud attempt actually unfolds

A Birmingham-based engineering firm of fifty-four people ran a well-managed Microsoft 365 tenant on Business Premium. MFA was enabled, the spam filtering was untouched from the defaults and working well, and there had never been a security incident. The compromise did not begin in their tenant at all. It began at a materials supplier they had traded with for nine years, where an account manager entered credentials into an adversary-in-the-middle phishing page, completed a genuine MFA prompt, and unknowingly handed over a session cookie.

For five weeks nothing visible happened. The attacker read the account manager’s mailbox, created a rule that filed messages from the engineering firm’s accounts payable address into an unused folder, and waited. When a genuine invoice for just over £41,000 was issued with thirty-day terms, they replied to the real thread — from the real supplier mailbox, quoting the real invoice number, in the account manager’s established tone — advising that the supplier had changed banking provider and attaching amended remittance details. Every technical signal was correct. SPF passed, DKIM validated, DMARC aligned, the sender was a nine-year correspondent, the message contained no link and no attachment beyond a plausible PDF, and the invoice being referenced was genuinely outstanding.

The payment was not made. The accounts payable clerk followed a one-line procedure introduced four months earlier: bank detail changes are confirmed by telephone to the number held on the supplier record. She rang the supplier’s switchboard — not the mobile number in the email signature — and asked for the account manager, who was entirely unaware of any change of bank. The supplier discovered their own compromise as a direct result of that call, and the engineering firm reported the attempt to Action Fraud and briefed the rest of the finance team the same week.

The instructive part is what did not stop it. Not the filtering, which had no grounds to act. Not DMARC, which passed because the mail was genuine. Not MFA, which had been correctly completed at the supplier. Not user awareness training, because there was nothing observably wrong with the message. A single process step, costing nothing and taking four minutes, was the entire defence — and the organisation had introduced it not after an incident but after a routine review recommended it.

We had spent two years being told the answer was better filtering, and the thing that actually saved us was a phone call to a number we already had. The email was perfect. There was nothing to spot. The only reason we did not pay it is that we had a rule that meant we did not have to spot anything.

Two footnotes worth carrying away. First, the firm’s own tenant was never compromised, which is the point: your exposure includes every supplier mailbox with your invoices in it, and you have no control over any of them. Second, the five-week dwell time is typical rather than exceptional. Had the supplier been alerted when that inbox rule was created, the fraud attempt would never have been sent at all.

At a glance — Microsoft 365 email security summary

The reference table below condenses the guide into the decisions and figures most likely to be needed in a planning conversation or a board paper.

How Cloudswitched approaches Microsoft 365 email security

Cloudswitched works with UK businesses on the configuration side of this problem: assessing an existing tenant against the controls set out above, building the Conditional Access baseline in report-only mode before enforcing it, taking domains from a monitoring DMARC record through to enforcement without disrupting legitimate mail, configuring detection so that alerts reach a person rather than a dashboard, and helping finance and HR teams put a payment verification process in place that survives a busy month-end. The emphasis is on finishing the work rather than starting it — most tenants we assess have already begun several of these and completed none.

Frequently Asked Questions

What is business email compromise in simple terms?

Business email compromise is a fraud in which someone is persuaded by email to make a payment or change a payment detail that benefits an attacker. It differs from ordinary phishing because there is usually no malicious link, attachment or malware for a security filter to detect — the message is plain text and asks a person with payment authority to do something they are entirely authorised to do. It frequently arrives from a genuine, fully authenticated mailbox belonging to a supplier who has themselves been compromised, which is why technical email filtering alone cannot reliably prevent it and why a payment verification process matters so much.

Is Microsoft 365 email security good enough on its own?

Exchange Online Protection, which is included with every Microsoft 365 plan, handles commodity spam and known malware very effectively. What is not sufficient is the tenant as it arrives, because the controls that address targeted fraud — enforced multi-factor authentication with no exclusions, blocked legacy authentication, restricted application consent, an enforcing DMARC policy, anti-phishing impersonation protection and alerting on inbox rules — all require deliberate configuration. A properly configured Microsoft 365 tenant is a strong position. An unconfigured one is not, regardless of which licence tier it sits on.

Do I need SPF, DKIM and DMARC if I already have MFA?

Yes, because they address a different problem. Multi-factor authentication protects your accounts from being used by someone else. SPF, DKIM and DMARC protect your domain from being impersonated in mail sent to other people — your customers, your suppliers, your staff. Without an enforcing DMARC policy, anyone on the internet can send mail that appears to come from your domain, and the recipient has no reliable way to tell. The two controls are complementary and neither substitutes for the other.

What does DMARC p=reject actually do?

It instructs receiving mail servers to refuse messages that claim to come from your domain but fail both SPF and DKIM alignment checks. In practice the fraudulent message is rejected during the SMTP conversation and never reaches the recipient’s mailbox or junk folder. The important qualifier is scope: p=reject protects your exact domain only. It has no effect on a lookalike domain registered by an attacker, on a free webmail account using your executive’s name as a display name, or on mail sent from a supplier’s genuinely compromised mailbox.

How long does it take to get from p=none to p=reject?

Sixty to ninety days is a realistic and comfortable timeline for most organisations. The DNS changes themselves take minutes; the time is spent discovering every legitimate service that sends mail using your domain and making sure each one authenticates properly before you start rejecting failures. That discovery is done by reading DMARC aggregate reports weekly, and it reliably turns up senders nobody in IT knew about — marketing platforms, accounting software, e-signature services and survey tools procured directly by departments.

Can multi-factor authentication be bypassed?

Standard MFA can be defeated by adversary-in-the-middle phishing, in which a proxy sits between the user and the genuine Microsoft sign-in page, relays the real credentials and the real MFA prompt, and captures the resulting session cookie. The attacker replays that cookie and has mailbox access without needing the password again. MFA remains essential and materially reduces risk. For privileged accounts and anyone with payment authority, pair it with Conditional Access device compliance requirements or phishing-resistant methods such as FIDO2 keys or passkeys, which cannot be relayed by a proxy.

How do I tell whether a mailbox has been compromised?

The most reliable indicator is an inbox rule the user did not create, particularly one that moves messages containing words like invoice, payment or bank into an unused folder, or that forwards mail to an external address. Others include sign-ins from unfamiliar locations or unusual user agents in the sign-in logs, unexpected mailbox permissions or delegates, consented enterprise applications nobody recognises, and counterparties reporting messages you did not send. Enable the Purview alert policy for new forwarding rules and route it to a monitored mailbox — it is the single highest-value detection available.

What should I do first if a mailbox is compromised?

Revoke the account’s active sessions before anything else. A password reset on its own does not invalidate an existing session token, so an attacker holding a valid cookie retains access straight through the reset. After revoking sessions, reset the password, re-register multi-factor authentication methods from scratch, remove any malicious inbox rules and forwarding, review delegates and consented applications, search the audit log to scope what was accessed, and notify affected counterparties by telephone rather than email. Then assess whether the incident requires an ICO notification.

Which Microsoft 365 licence do I need for proper email security?

Microsoft 365 Business Premium is the sensible default for most UK organisations up to 300 seats. It includes Defender for Office 365 Plan 1 for Safe Links, Safe Attachments and impersonation protection, and Entra ID P1 for full Conditional Access, which is what makes granular identity policy possible. That said, the highest-impact controls — enforced MFA, blocking legacy authentication, restricting application consent, DMARC enforcement and inbox rule alerting — are available on lower tiers. Configuration matters more than licence tier, and an unconfigured E5 tenant is weaker than a well-configured Business Premium one.

Do we still need a third-party email security gateway?

It depends entirely on what your tenant configuration already covers. A gateway adds an inbound filtering layer and, in some products, additional BEC-specific analysis. It does not enforce multi-factor authentication, block legacy authentication, publish DMARC, restrict application consent or alert on inbox rules — which is to say it does not address most of the exposure described in this guide. Configure the tenant first, measure what is still getting through, and then evaluate a gateway against that specific residual gap rather than as a general-purpose answer.

Does email spoofing prevention stop lookalike domains?

No, and this is the most commonly misunderstood limitation of domain authentication. SPF, DKIM and DMARC govern mail claiming to come from a domain you control. A domain such as your-company-uk.com or a character-substituted variant belongs to the attacker, who will configure perfect authentication records on it, and every check will pass. The defences against lookalike domains are different: anti-phishing impersonation protection configured with your key domains, external sender tagging so the recipient sees the message is not internal, defensive registration of the most obvious variants, and monitoring for newly registered similar domains.

How often should this configuration be reviewed?

Quarterly is a reasonable cadence and it should be a specific review rather than a general one. Check that no new permanent exclusions have appeared in Conditional Access policies; that no mail flow rule bypassing filtering has been added to resolve a deliverability complaint; that the enterprise application list contains nothing unrecognised; that DMARC aggregate reports are still clean and still being read; and that alert destinations still point at a mailbox with a current owner. Configuration decay is gradual and almost always well-intentioned, which is exactly why it needs a scheduled check.

Related reading

These guides cover the adjacent areas most often reviewed alongside a Microsoft 365 email security programme — certification, network containment, telephony verification and the leadership capacity to see the work through.

• Cyber Essentials Certification: A Step-by-Step Guide for UK Businesses
• Network Segmentation for UK SMEs: Containing a Breach Before It Spreads
• When Does a UK SME Actually Need a Virtual CIO?
• The PSTN Switch-Off: A UK Business Guide to VoIP Migration
• Business Broadband Failover and Redundancy: A UK Guide