Email Security for Business: What an Assessment Actually Tests

Almost every email security conversation starts with a product and should start with a number. In the 2025 Internet Crime Report the FBI complaint centre recorded 24,768 business email compromise complaints and 3.046 billion US dollars in reported losses for that single crime type - a category that has held near the same complaint volume for three years while the money involved keeps climbing, and in 2025 the report noted more than 30 million dollars of BEC losses with a confirmed artificial-intelligence element. Spoofing is cheap, the failure is financial, and the controls that prevent it are mostly records in DNS rather than appliances in a rack.

That is the useful framing for a business: email is the one attack surface where a large part of the protection is public, verifiable from outside the organisation, and free to inspect. Anyone can query a domain SPF, DKIM and DMARC records, its MTA-STS policy and its TLS reporting address, and reach a defensible conclusion in an afternoon. What cannot be seen from outside - mailbox rules, forwarding, delegated access, consent grants, what the gateway actually blocks - is where most of the remaining risk sits, and that is the half of the assessment that requires cooperation rather than a DNS query.

This guide covers both halves for a business audience in 2026. It explains the four identities inside a message and why only one of them is visible, how the authentication stack fits together after the DMARC specification was republished as RFC 9989 in May 2026, what an adversary-in-the-middle kit does to a second factor the organisation believes is protecting it, which mailbox configurations hand an attacker a mailbox without a single credential, and what a five-day assessment should be able to put on the table at the end. It is written for the person who owns the domain, the administrator who inherited the tenant, and the buyer who has been quoted for email security and wants to know what is being sold.

Why an email security assessment still starts with the From line

Email was designed to move a message between systems that trusted each other, and the address a recipient sees was never authenticated by the protocol itself. Everything that follows - SPF, DKIM, DMARC, ARC, MTA-STS - is a retrofit around that gap. The retrofit works when it is complete and fails in a specific, predictable way when it is partial, which is why a domain at p=none can feel protected while a stranger sends mail as its chief financial officer.

The measurement problem is now a public one, and the published numbers are the best argument for doing the work. Valimail's 2026 State of DMARC report puts awareness at 78 per cent while enforcement has plateaued at 42 per cent - a 36-point gap between organisations that know about the standard and organisations that have asked receiving servers to act on it. A June 2026 scan of the Fortune Global 500 by SimpleDMARC found 63 per cent enforcing quarantine or reject, 48 per cent at full reject, 16.4 per cent publishing a monitor-only record and 20.6 per cent with no record at all. A February 2026 census of 5,499,028 domains on the Tranco list by DMARCguard found 30.4 per cent publishing a record and only 12.8 per cent enforcing one.

Read those three together and the pattern is not that nobody does this. It is that the largest and best-resourced organisations mostly do, the long tail mostly does not, and the middle publishes a record that satisfies a mailbox provider's bulk-sender rule while providing no protection against someone else using the domain. A monitor-only record is not a half-measure towards protection; it is a reporting mechanism, and it blocks nothing.

There is a commercial reason the gap persists. A monitor-only record is cheap, invisible to the board, and passes every audit question that asks whether DMARC exists. Reaching reject requires someone to find every application that sends mail in the company's name, name an owner for each, and fix the ones that break alignment - work that lands on a small team and produces no visible feature. The organisations that finish are the ones where that work was written into a project with a deadline, and the ones that stall are the ones where it was assigned to nobody in particular.

The four identities in a message, and the one the user reads

Every message carries several claims about who sent it, and confusing them is the root of most misconfiguration. The header From is the address displayed in the inbox and is what DMARC evaluates through alignment. The envelope sender, or MAIL FROM, is what SPF validates and where bounce messages travel. The DKIM domain is whatever domain signed the message, which may be yours, your marketing platform's, or a shared signing service's. The HELO domain is the sending server's name and matters mainly for reputation and for transport policy checks.

Two rules follow, and both are routinely missed. First, a message can pass SPF on a domain the recipient never sees, and can pass DKIM on a domain unrelated to the visible sender; passing is not the same as being aligned. Second, the DMARC revision changed which identity SPF is evaluated against: RFC 9989 restricts SPF validation to MAIL FROM, which removes an older ambiguity but means an environment that relied on a different identity being checked must confirm alignment still holds after the transition.

The practical test is to take a real message, open the raw headers and write the four values side by side. If the visible From domain and the DKIM signing domain differ, the message can still be legitimate - a bulk sender signing as itself on your behalf is normal - but alignment decides whether DMARC can credit that as you. An assessment that does not walk several real headers, from each sending platform the business uses, is not measuring this at all.

DMARC posture: the ladder from p=none to reject

DMARC asks a receiving server to do one thing: compare the authentication results against the visible From domain, and where they do not align, apply the policy the domain owner published. The policy has three useful values. none asks for reports and nothing else. quarantine asks for the message to be treated as suspicious, which at most providers means the spam folder. reject asks for it not to be delivered at all.

Almost every domain starts at none, correctly, because a reject policy published before the organisation knows all of its legitimate senders will block real mail - invoices, applicant tracking systems, the payroll platform nobody documented, the website contact form. The migration is a discovery exercise disguised as a DNS change: run at p=none; rua= long enough to see every source, reconcile each against a named business owner, fix the ones that fail alignment, and only then move to quarantine and eventually reject. The NCSC's mail-related guidance and every credible vendor describe the same sequence, and organisations stall at none because nobody was assigned the reconciliation work, not because the final step is technically hard.

Two settings decide whether the policy means anything. Subdomain policy, the sp tag, controls mail from subdomains; when it is absent, subdomains inherit the organisational policy - either what you want or a surprise, depending on whether anyone knows how many subdomains send mail. Alignment, set by adkim and aspf, decides whether a subdomain of your domain counts as aligned (relaxed) or must match exactly (strict). Relaxed is the common default and the usual reason a sending platform on a delegated subdomain passes while a lookalike domain does not.

Aggregate reporting is the other half of the record and the part most organisations ignore. The rua address receives daily XML reports from participating providers describing what was seen and what failed, which is how a domain owner learns that a marketing platform sends unaligned mail, that a third party is spoofing the domain, or that a legacy application still sends as the bare domain from an IP nobody recognises. Without a reporting destination the record is a policy with no feedback, and the move to reject becomes guesswork. The reports contain sending addresses and counts rather than message contents, but they are still records about traffic, so the mailbox that receives them should be chosen with the privacy owner rather than by default.

One more property is worth stating plainly because it is the most misunderstood: DMARC protects the domain, not the brand. It stops a stranger sending mail that claims to be from yourdomain.com. It does nothing about mail from yourdomain.co, your-domain.com, a lookalike with a swapped character, or an attacker using your display name over their own domain - and those are the techniques that reach an inbox most often, because registering a cousin domain costs less than the effort of spoofing one that publishes a reject policy.

What changed when DMARC became RFC 9989

After a decade of drafts the revised specification was published in May 2026 as three documents: RFC 9989 for the core policy, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. They obsolete RFC 7489 and its extension, and the important point for a business is that nothing must be republished immediately - v=DMARC1 did not change and existing records remain valid.

Three changes affect how a record should be written from now on. The pct tag, which sampled a percentage of messages and was widely mistaken for a safety dial, is retired in favour of a boolean t testing tag; policies that used pct for a gradual rollout should be rewritten rather than assumed to keep behaving as intended. A new np tag covers non-existent subdomains, closing a gap attackers exploited by inventing subdomains that inherit nothing. And discovery moved from a Public Suffix List lookup to a DNS tree walk, which makes organisational-domain handling deterministic instead of dependent on an external list that changes.

The engineering consequence is that any tooling which parsed DMARC records and assumed pct, or used the suffix list to decide where policy lives, needs review. The commercial consequence is subtler: a vendor selling "DMARCbis readiness" as a migration project is selling a transition the standard deliberately made non-breaking, while a vendor that can show which of your sending sources still fail alignment is selling the thing that decides whether you ever reach reject.

SPF: a ten-lookup budget and the flattening trade

SPF publishes a list of systems authorised to send mail as a domain, and the receiving server evaluates it against the envelope sender. The mechanism is simple; the operational trap is arithmetic. Evaluating a record may require DNS lookups, and the specification caps those at ten. Each include, a, mx, ptr, exists or redirect costs at least one lookup, and an include pulls in the whole nested record of the domain it names. A business that has accumulated a CRM, a marketing platform, a ticketing system, a payroll provider and a website form handler can reach ten without noticing, and the result is a permanent error that receivers treat as no SPF at all.

The second limit is size. A single TXT string is capped at 255 characters, multiple strings are concatenated by the resolver, and the practical guidance is to keep the whole record comfortably inside 512 octets. A record past the limit is not partially honoured; it fails.

Flattening - resolving includes into literal addresses - is the usual answer and a trade rather than a fix. It removes the lookup cost and converts a maintained third-party record into a snapshot that goes stale the moment the provider adds or retires an address, which for a large cloud sender happens without notice; a flattened record also grows past the size limit quickly. The alternatives are to route mail through fewer sending domains, to give high-volume platforms their own subdomain with their own SPF and DKIM and an alignment that still holds at the apex, or to accept a managed flattening service and monitor it. What is not an option is leaving a permanently broken record in place, because the failure is silent: mail still arrives when the sending address happens to appear in the record before the error, and is rejected by strict receivers when it does not.

Subdomains deserve their own sentence. SPF is not inherited: a subdomain without its own record has no SPF unless it falls back to a wildcard or the organisational domain is configured to cover it, while DMARC policy is inherited. That asymmetry is how a domain can sit at reject for its apex and still carry real traffic from an unprotected mail. or info. subdomain.

DKIM: selectors, key size, and the length tag that undoes it

DKIM signs the message with a key whose public half lives in DNS at a selector address, and receiving servers verify that the body and selected headers were not altered in transit. It is the control that survives forwarding, which is why alignment on DKIM matters more than alignment on SPF for any organisation whose mail is relayed.

The first thing to check is what your selectors actually publish. A 1024-bit key is not adequate in 2026; 2048-bit RSA is the floor for anything new, and the key should be unique per sending service so that a single compromise does not taint every stream. Selectors also accumulate: retired providers, old marketing tools and forgotten test domains leave valid keys in DNS that can still sign mail for the domain years after the relationship ended. An assessment lists every selector it can find, records the key size and the date last seen in a signature, and flags the ones that nobody claims.

The second thing is the l= tag, the body length limit, which tells the verifier to hash only the first N bytes of the body. It appears in some mailing list and ticketing software as a workaround for signatures broken by appended footers, and it is a gift to an attacker: anything can be appended after the signed prefix and the signature still verifies. A domain whose outbound signatures carry a length tag is effectively signing a header claim rather than the message, and phishing that rides on a replayed signed body has been demonstrated repeatedly against exactly this pattern.

Rotation is the third. Keys should be rotated on a schedule and immediately after any staff change that touched DNS, and rotation should be a two-record overlap rather than a swap, so that mail in flight still verifies. Canonicalisation settings matter too, though less than vendors imply: relaxed/relaxed is the interoperable default, and strict canonicalisation breaks more legitimate mail than it stops.

The most common DKIM finding in a mid-size business is not a weak key but a split signing estate: the Microsoft 365 tenant signs with one selector, the marketing platform signs with its own shared domain, and the application that sends invoices signs with nothing. The first two are visible in the headers of a received message; the third is visible only when someone looks at the sending path, which is why header walking and source inventory have to happen together.

Alignment, forwarding and what ARC is for

Alignment is the join between authentication and identity: does the domain that passed SPF or DKIM share an organisational domain with the visible From. That is a policy decision, and it is why a mailing list that forwards your message to thousands of subscribers can break DMARC at the subscriber without anyone changing a thing. The list rewrites the envelope sender, so SPF fails; if the message was signed by a platform whose domain does not align, DKIM fails too, and a strict receiver drops otherwise legitimate mail.

ARC - Authenticated Received Chain, RFC 8617 - is the mitigation: intermediaries seal the authentication results they observed, so a final receiver can see that the message did authenticate before it was forwarded. It works when every hop in the chain is honest and sealing, and it is a meaningful improvement for list traffic and for mail that passes through a gateway before reaching the mailbox. It is not a licence to ignore alignment in outbound mail, and a receiver that does not implement ARC will still evaluate the message the old way.

The practical rule for an assessment: if the business forwards mail through a mailing list, a helpdesk ticketing system that sends on behalf of staff, or a shared mail relay, test it with a real message to a real external mailbox and read the authentication results the receiving provider recorded. Those headers, not the diagram, are the evidence.

Transport security: MTA-STS, TLS-RPT and DANE

Authentication proves who wrote a message. It does not protect the channel, and SMTP will happily fall back to plaintext when a TLS negotiation fails, which is what makes opportunistic downgrade attacks practical. Three mechanisms close that hole, and their deployment order in the UK's national guidance is instructive because it reflects how organisations actually get this wrong.

MTA-STS, RFC 8461, publishes a policy at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt announcing that mail for the domain must be delivered over validated TLS with a certificate matching the recipient host. The policy has modes - none, testing and enforce - a max_age that decides how long a sending server should cache it, and MX patterns that scope which hosts it covers. The significant operational catch is that a policy naming a mail host that later changes will cause hard delivery failures rather than quiet fallback, so the record and the mail routing have to be maintained together.

TLS-RPT, RFC 8460, publishes a reporting address where sending servers describe TLS negotiation failures. It is the visibility layer, and the National Cyber Security Centre's mail guidance recommends enabling reporting before switching a policy to enforcement, running in testing mode for at least two weeks, and only then moving to enforce. Skipping that order is how an organisation discovers an old certificate, an appliance that cannot negotiate TLS 1.2, or a partner's mail server that has been quietly talking plaintext for years - after the mail stops.

DANE, RFC 7671, is the stronger option that requires DNSSEC: TLSA records pin the recipient certificate in DNS, so the sending server does not depend on a certificate authority it does not control. It is excellent where both parties support it - government, some European mail providers, and technical organisations - and irrelevant where DNSSEC is not deployed on either side. The honest finding for most businesses is that MTA-STS with enforcement plus TLS reporting delivers most of the benefit at a fraction of the operational cost, and DANE is a decision for later.

The other transport question is the one that predates all of this: is TLS 1.0 or 1.1 still accepted anywhere in the path? Modern gateways can report cipher and version per peer, and a scan that shows legacy TLS in use is a more concrete finding than a policy document.

The spoofing that DMARC does not stop

Four techniques reach inboxes without ever touching your domain's DNS, and each needs a different control. Display-name spoofing sends from an attacker domain with your chief executive's name in the friendly name field; the address is wrong and the name is right, and on a phone the name is what the user sees. The only durable control is a mail client and gateway that flag external senders and a culture that reads the address - plus, at some organisations, a rule that quarantines external mail using internal display names.

Cousin and homoglyph domains register a name that looks like yours - a doubled character, a different top-level domain, a hyphen, or a Unicode lookalike rendered in a different script. DMARC says nothing about them because they are not your domain. The controls are defensive registration of the obvious variants, certificate transparency monitoring for lookalikes that obtain TLS certificates, and takedown processes that actually run.

Internal-domain spoofing is the gap that survives a mature deployment: mail arriving from the internet with a From address at your own domain. If the inbound path does not apply your own reject policy to itself, that message lands in an internal mailbox looking entirely native. Every major platform has a setting for this, and it is unset by default at more organisations than will admit it.

Compromised legitimate accounts defeat all of it, because the message is genuinely from a real mailbox with correct authentication. That is the category the IC3 numbers describe, and it is where the rest of this guide spends its effort.

The mailbox review: where an account is lost without a credential

Authentication stops forgery. It does nothing about an authorised person granting access, and a large share of business email compromise never involves a password being stolen twice. The mailbox settings below are the ones an assessment should read, because each can hand over correspondence or persistence while leaving every login control intact.

Forwarding to an external address. A single auto-forward rule sends every inbound message to an attacker's mailbox, typically for months, and it survives password resets because it is a setting rather than a credential. Most platforms can block external forwarding centrally; many tenants have it enabled because someone once needed it.

Inbox rules that hide replies. Attackers create a rule that moves messages containing words like invoice, payment or fraud into an archive folder and marks them read, so the victim never sees the recipient asking why the bank details changed. The rule is invisible in the normal mail view and is the single most reliable persistence mechanism in a BEC.

Delegated and shared mailbox access. A mailbox granted to a former contractor or an unmanaged account is standing access. The review is a list of every delegation and shared membership, with an owner and a business reason for each.

Application passwords and legacy protocols. An app password is a long-lived credential that bypasses the second factor entirely, and legacy authentication protocols do the same. Where a tenant still accepts them, the MFA deployment is decorative for anyone who can obtain one of those secrets.

Illicit consent grants. In Microsoft 365 and Google Workspace, an attacker whose application a user consents to can read mail through the API with no password at all, and the grant survives a credential reset. Reviewing enterprise applications and third-party OAuth grants is a five-minute task that almost never happens.

Device-code phishing. A newer variant where the attacker asks the user to enter a short code at a real sign-in page, which authenticates the attacker's session rather than the user's. There is no lookalike page to detect, which is why it has become a standard step in the kits described below.

Phishing-resistant MFA and the session-token reality

The second factor an organisation believes it has is usually the weakest part of the story. Adversary-in-the-middle kits put a reverse proxy between the user and the real sign-in page, relay every step including the second factor, and copy the session cookie that the identity provider issues after a successful login. The attacker then replays the cookie and is inside the account without knowing the password and without defeating any factor, because the victim performed the MFA themselves.

The scale is no longer anecdotal. Proofpoint's 2026 analysis reported that 59 per cent of the accounts it saw taken over had MFA enabled, and SpyCloud's 2026 identity exposure report described 8.6 billion stolen cookies and session artefacts recaptured from malware and phishing, within a recaptured datalake that grew 23 per cent in a year to 65.7 billion records. KnowBe4's 2026 phishing trend report measured toolkit-based phishing at 29.2 per cent of malicious mail in the third quarter of 2026, up from 18.9 per cent in 2024, with three reverse-proxy kits accounting for 90.2 per cent of kit-driven volume. A Microsoft investigation published in May 2026 described a campaign that relayed the genuine sign-in page to more than 35,000 users at over 13,000 organisations in 26 countries between 14 and 16 April - figures Microsoft characterised as targeting estimates rather than confirmed compromises, which is the right way to read them.

The control that changes this is a credential bound to the origin: FIDO2 security keys and passkeys, where the browser proves possession to the real domain and a proxy cannot relay the assertion. CISA's joint phishing guidance with the NSA, FBI and MS-ISAC lists FIDO or PKI-based MFA as the phishing-resistant option and number matching as the fallback where it cannot be deployed yet, and NIST's SP 800-63B-4 formalises the same distinction for authenticator assurance levels. For most organisations the practical sequence is: phishing-resistant factors for administrators, finance and executives first, conditional access that refuses legacy protocols and unfamiliar devices, token protection and short session lifetimes after that, and number matching as an interim rather than a destination.

What a secure email gateway cannot see

Filtering is the control buyers expect, and its limits are structural rather than a matter of product choice. A gateway sits in the inbound path and inspects messages as they arrive, which means it sees nothing of internal-to-internal mail, nothing of a message sent directly between two cloud tenants that bypasses your MX record, and nothing of the API path a compromised OAuth grant uses to read a mailbox. It also sees an attacker's message before the attacker knows whether the organisation is a target, which is why detonation and reputation work well against commodity campaigns and poorly against a two-message conversation with a named person.

The controls that do pull their weight are unglamorous. Blocking executable and script attachments by type rather than by detection, including the container formats that smuggle them. Rewriting and detonating links, accepting that user-visible rewriting has its own costs and that a determined attacker will use a legitimate host. Enforcing external-sender banners so a display-name spoof is at least visibly external. Blocking newly registered domains at the perimeter, which stops a large share of credential-phishing pages. And logging that is actually retained and searchable, because the value of a gateway in an incident is the ability to answer what else arrived from the same infrastructure.

The finding that recurs is a gateway deployed in front of one tenant while a second business unit, subsidiary or acquired company routes mail directly to its own provider. The gateway is doing exactly what it was configured to do for the traffic it sees, and the assessment's job is to establish what it does not see.

Business email compromise: the controls that actually stop a payment

A BEC is not a malware incident; it is a conversation. The attacker reads the real thread, learns the cadence, and inserts a request that is plausible because it arrives in context and from a real mailbox. Technical controls reduce how often that happens, and the controls below are what decide whether it turns into a transfer.

Verify a change of bank details by a route you already had. Not the phone number in the email, not the number on the new invoice - the number in the supplier record, dialled by the person who normally deals with that supplier. This single control defeats the most expensive variant of the crime, and it fails whenever it is treated as a formality to be skipped when the requester is senior or the deadline is tight.

Two approvals, one of them independent. A payment that requires two people in different reporting lines, with the second seeing the request rather than a summary, makes a single compromised mailbox insufficient. Where the volume of payments is too high for that, apply the rule to changes in standing data - new payee, changed account, first payment to a new supplier - rather than to every invoice.

Callback on executive requests. A culture where a request from a director to move money or buy gift cards is confirmed in person or by a known number is worth more than a policy document, because the alternative is a junior employee weighing a rule against an instruction from their boss.

Out-of-band confirmation for payroll changes. Payroll diversion - a request to change an employee's bank details - is the variant that repeats monthly and is often discovered a year late. It needs its own control: a change request that requires identity verification through HR, not through email.

Reconciliation that looks at the supplier, not just the total. Diverted payments are frequently invisible in a control-total check because the amount matches the invoice exactly; what changes is who received it.

The first hour after a BEC, in order

When a mailbox is confirmed compromised, the sequence matters more than the completeness of the response. Revoke the sessions first - not just the password - because a stolen token survives a password reset, and resetting the password while the attacker still holds a session is how a response becomes a loop. Then remove the forwarding rules, inbox rules, delegations, app passwords and OAuth grants, in that order, and record what each was, because the rules describe what the attacker was watching.

Next, establish what left: search sent items, deleted items and the audit log for the period the session was active, and list every external recipient. Then tell the counterparties, because the attacker's next move is usually a message to the same thread from the same mailbox. Only after those steps is a forensic review of how the token was obtained worth doing - the answer informs the next incident, and it does not change the current one.

If money has moved, the clock is the control. Domestic wire recalls, real-time payment reversals and correspondent-bank requests are all time-sensitive, and the practical window is measured in the first day or two rather than the first week. Report to the relevant financial crime authority promptly - in the United States the IC3 channel is the one that routes to asset recovery - and give the bank the exact transaction references rather than a narrative.

The written record matters as much as the actions. A timeline with timestamps, the rules that were found, the recipients that were contacted and the decisions that were taken is what an insurer, a regulator or a client will ask for, and it is much easier to produce in the first hour than in the third week. Our corporate email compromise investigation guide covers the evidence sequence in detail, and the incident response plan guide covers how to have the roles assigned before this happens.

What a five-day assessment measures

A useful engagement produces evidence rather than a rating. The structure we use runs five working days for a single domain family, and the deliverables are the artefacts below - each of which a reviewer can check independently.

Day one: external posture. Every DNS record that affects mail, exported verbatim: SPF with its resolved lookup count and the flattened include chain, every DKIM selector found with key size and last-seen date, DMARC with its policy, subdomain policy and reporting destinations, MTA-STS policy with its mode and max age, TLS reporting address, BIMI record and certificate chain where present, and the presence or absence of DNSSEC. Plus the results of a real spoofing test, sent from an external address to a mailbox the client controls, showing exactly what the receiving provider did with it.

Day two: sending-source inventory. A reconciliation of every system that sends mail as the domain, obtained from the DMARC aggregate reports rather than from a conversation, with an owner named for each, an alignment result per source, and the list of sources that cannot be accounted for. This is the artefact that makes the move to reject possible, and it is usually the most valuable thing in the report.

Day three: tenant configuration. Forwarding rules and their central policy, external-sender marking, inbound enforcement of your own domain, attachment policy, link handling, quarantine and release process, audit log retention, and the authentication methods enabled - including anything legacy.

Day four: identity and access review. MFA coverage by group with the factor type per group, conditional access or equivalent policy, legacy protocol status, admin role assignments and their permanence, session lifetime and token protection, and the list of third-party applications with mail access.

Day five: process and people. The payment-change control as practised rather than as documented, tested with a scripted scenario; the reporting path for a suspicious message and how long it takes to reach someone who can act; and a sample of recent campaigns with what the organisation actually did about them.

The report is then a short list of findings with severity, evidence and a specific fix, plus the residual risks that remain after the fixes. What it should not be is a maturity score out of five, because a score cannot be tested and a finding can.

What the assessment cannot prove

Honesty about limits is what separates an assessment from a sales document. Four things are outside what an external and cooperating review can establish. It cannot prove that the gateway blocks a novel campaign, because detection is probabilistic and a single test message proves one sample. It cannot prove that no mailbox is currently forwarding mail to an unknown address unless the audit log retention covers the whole period since the last review - and in most tenants it does not, because default retention is short. It cannot prove that staff will follow the callback rule, only that the rule exists and that the last three payments were checked. And it cannot prove the absence of an illicit consent grant that was created and removed between reviews.

Each of those gaps is a monitoring requirement rather than a finding: ongoing alerting for new forwarding rules, for new OAuth grants, for impossible-travel sign-ins and for mass-download behaviour. An assessment that ends with a static report and no monitoring recommendation has answered a question about last Tuesday.

Mapping the work to frameworks you already report against

Most organisations do not need a new control set; they need the email work to land in the framework the auditor already uses. The mapping is straightforward and worth stating, because it turns a technical project into a compliance deliverable with a deadline.

ISO/IEC 27001:2022 Annex A 5.14 covers information transfer and is where mail protection, policy and agreements belong; 8.23 covers web filtering, which most auditors read alongside mail filtering; and 5.7 covers threat intelligence, which is where DMARC aggregate reports and campaign samples belong. The certification question is whether the controls are evidenced, and the artefacts above are that evidence.

NIST SP 800-177 Revision 1 remains the reference architecture for trustworthy email: it walks SPF, DKIM, DMARC, SMTP TLS, MTA-STS and DANE in deployment order and is the document to cite when justifying the sequence to a technical audience. CISA's Cross-Sector Cybersecurity Performance Goals put DMARC at reject and phishing-resistant MFA in the same list, which is useful when a board asks why the two are one project rather than two.

PCI DSS v4.0.1 requirement 5 covers anti-malware and phishing defences for the cardholder environment, and requirement 12 covers awareness training; a business that handles card data and answers those two with email hygiene rather than endpoint antivirus is answering them better than most.

UK Cyber Essentials asks for SPF, DKIM and DMARC with a policy of quarantine or reject on domains used for email, which is a lower bar than this guide but a real one, and NCSC mail guidance supplies the TLS reporting and MTA-STS sequence described earlier.

Cost bands and how to scope the work

Pricing in this market is opaque, so here is what our own engagements cost, stated plainly. A focused external posture review of one domain family - the day-one and day-two artefacts, a written findings note and a spoofing test - sits at roughly GBP 1,500 to 2,500. A full five-day assessment for a mid-size organisation, including the tenant and identity review, the process interview and a remediation plan, runs about GBP 4,000 to 9,000 depending on mailbox count and the number of sending platforms. A multi-domain migration to enforced DMARC across subsidiaries, with reporting infrastructure and 90 days of support, is an engagement in the GBP 12,000 to 25,000 range and is priced by the number of domains and legacy senders rather than by headcount.

What moves the number is not size but discovery. Ten domains with three senders each are cheaper than one domain with a decade of accumulated marketing tools, because the work is reconciliation. A buyer should therefore ask for the sending-source inventory to be scoped as a deliverable with a count, and should be suspicious of a fixed price quoted before anyone has looked at the DMARC reports.

For organisations that cannot fund an engagement, the sequence to run internally is the same and costs nothing but time: publish a reporting address, read the reports for thirty days, reconcile every source, fix alignment, move the policy to reject, then start on the mailbox review. The security hardening service page describes where that work overlaps with the wider infrastructure review, and the phishing awareness training guide covers the human half that no record in DNS replaces.

Lawful scope: authorisation, test phishing and lookalike domains

An email assessment touches systems you may not own and people who did not ask to be tested, so the scope has to be written down before anything is sent. Three constraints apply to every engagement we run.

Written authorisation for the domain. Testing a domain means sending mail that claims to be from it and, in some tests, publishing records for it. That requires the domain owner's written instruction, and where the domain belongs to a subsidiary or a client, the authority to act on it. A letter of authorisation naming the domains, the test window and the permitted techniques is the minimum.

Consent for simulated phishing. Sending test messages to staff is a people experiment, not just a technical one. It needs an agreed target population, an agreed exclusion list - the finance team during month-end close, anyone under an active disciplinary process, new starters in their first fortnight - a defined stop condition, and a reporting route for anyone who clicks. Where there is a works council or union, the campaign goes through it first. This is the same standard we apply to awareness programmes, and it is why we do not run "gotcha" campaigns whose only output is a leaderboard of who failed.

No interference with third parties. Registering lookalike domains to prove a point is a trademark question as well as a security one: register only variants you have a legitimate interest in defending, never configure them to impersonate anyone, never send mail from them, and document the defensive purpose. Sending test spoofs to addresses outside the client's control is out of scope in every case, and the practical alternative is a mailbox the client owns at a third-party provider, which is enough to prove what a receiving server does.

The same discipline applies to data. DMARC aggregate reports, mail headers and audit logs are records about individuals, and an engagement that exports them to a laptop and forgets them has created the incident it was hired to prevent.

The findings that recur, ranked by what they cost

Across the engagements behind this guide the same problems appear, and the order below is by the cost of the failure rather than the effort of the fix. A reviewer who finds these first is spending their time well.

A DMARC record at none, treated as done. The domain is spoofable, the reports nobody read are full of evidence, and the audit answer is technically true. Fix: assign an owner, reconcile the sources, move to reject - and date the move.

MFA that a proxy defeats. Codes and push notifications stop credential stuffing and do nothing against an adversary-in-the-middle kit. Fix: FIDO2 or passkeys for administrators, finance and executives, before anyone else.

External forwarding enabled tenant-wide. One compromised session exfiltrates every future message, indefinitely. Fix: block external auto-forward centrally, with an exception process that has an owner.

Inbound mail from your own domain not treated as spoofing. The gap survives a mature outbound deployment because nobody tested the inbound path. Fix: apply the reject policy to your own domain at the mail edge and prove it with a test message.

No callback rule for changes of bank details. The single control that defeats the most expensive variant of the crime, and the one most often documented and not practised. Fix: write it into the accounts payable procedure, test it quarterly, and give staff explicit permission to slow a payment down.

Short audit log retention. A fourteen-day window cannot answer what a session did last month, and every escalation of a compromise starts with that question. Fix: extend retention for mailbox audit and sign-in logs, and put the cost in front of whoever owns the budget.

Selectors nobody owns. Retired platforms leave working keys in DNS that still sign mail as the domain. Fix: enumerate selectors, confirm each against a live sender, and remove the orphans after a quiet period.

The first 30, 60 and 90 days

Most organisations cannot do all of this at once, and a plan that tries will stall. The sequence below is ordered so that each stage produces something that holds even if the next one slips.

Days 1 to 30. Publish DMARC with a reporting address on every domain and subdomain family that sends mail; enable TLS reporting and an MTA-STS policy in testing mode; block external auto-forwarding; turn on external-sender marking and inbound enforcement of your own domain; extend audit log retention; and enable phishing-resistant MFA for the administrators. None of these needs a procurement, and together they remove the cheapest attacks.

Days 31 to 60. Reconcile the aggregate reports into a sending-source inventory with an owner per source; fix alignment on everything that fails; add DKIM to the senders that have none; move MTA-STS to enforcement after the testing period; remove orphaned selectors; extend phishing-resistant MFA to finance and executives; and write the change-of-bank-details control into the accounts payable procedure with a named approver.

Days 61 to 90. Move DMARC to quarantine and then reject, with a defined rollback if a legitimate source breaks; review delegations, app passwords and OAuth grants and remove what has no owner; run one scripted BEC scenario end to end, including the callback and the reporting route, and record how long each step took; and set the monitoring that closes the gaps the assessment cannot cover - alerts for new forwarding rules, new consent grants, impossible travel and mass downloads.

What is deliberately absent from that plan is a product purchase. Every item is a configuration change, a record or a procedure, and the organisations that finish are usually the ones that resisted buying a platform to avoid doing the reconciliation.

The short version

Email security in 2026 is two problems wearing one name. The first is forgery, and it is solved by published records that anyone can check: SPF within its lookup budget, DKIM with keys you can account for, DMARC at reject with a reporting address you actually read, MTA-STS enforced with TLS reporting behind it. The second is account takeover, and it is not solved by those records at all - it is solved by phishing-resistant authentication, a mailbox configuration nobody can quietly change, and a payment process that assumes the request is fraudulent until a known number confirms it.

The organisations that get caught are rarely the ones with no controls. They are the ones with a monitor-only DMARC record, a second factor a proxy can relay, an external forward nobody noticed, and a finance team that was told to move fast. Each of those is fixable in a week, and the reason they persist is that none of them shows up as an outage.

If the work is being bought rather than run internally, the test of a supplier is simple: ask what they will put in the report that you could not have obtained yourself, and ask to see a sending-source inventory from a previous engagement with the client details removed. A supplier who can produce those has done the work before. One who answers with a maturity score is selling the appearance of it.

For the parts of this that overlap with the wider estate, our security hardening engagement covers the tenant, the endpoint and the network controls that decide whether a stolen session becomes a business interruption, and our email hacking investigation guide covers the forensic path when a mailbox has already been accessed. The zero trust security guide explains why identity, not network position, is the boundary that matters once an attacker is inside a mailbox.