Email Security — Stopping BEC, Phishing and Domain Spoofing

BEC is a fraud in which an attacker uses email to persuade someone to move money or data, typically by impersonating an executive, a supplier or a colleague. The distinguishing feature is that it usually carries no malware and no malicious link — frequently it is sent from a real, already-compromised mailbox belonging to a genuine business contact. It is consistently among the most financially damaging categories of attack precisely because there is nothing technical to detect.

With a process, owned by finance rather than IT: any change to bank details, and any payment above a threshold, is verified out of band using a phone number already on file — never a number from the email requesting the change. That single rule stops the overwhelming majority of BEC losses and costs nothing. Technical controls help around the edges: external-sender banners, lookalike-domain monitoring, anomaly detection on unusual requests. None of them substitute for the callback.

SPF lists which servers may send mail for your domain. DKIM cryptographically signs your mail so a receiver can verify it was not altered and genuinely came from you. DMARC ties them together: it tells receivers what to do when a message claiming to be from your domain fails those checks, and asks them to report back. All three are DNS records and all three cost nothing but configuration time.

The destination is p=reject. The route there is deliberately gradual: publish p=none first and read the reports for several weeks to discover every legitimate sender — and there are always more than expected, because marketing platforms, invoicing systems and helpdesk tools all send as your domain. Then move to p=quarantine, watch, then to p=reject. Moving faster than your sender inventory bounces legitimate mail, which is how DMARC projects get abandoned at p=none permanently.

Both platforms sign outbound mail with DKIM once enabled — it is not on by default in every configuration, so check rather than assume. SPF must list the platform’s sending infrastructure along with every third-party service that sends on your behalf. DMARC is then a single TXT record at _dmarc.yourdomain, starting at p=none with a reporting address. The work is not the records; the work is finding every legitimate sender before you enforce.

Not necessarily, and this is worth assessing honestly rather than assuming either way. Built-in protection has improved substantially, and what you get depends heavily on your licence tier — organisations frequently assume capabilities their tier does not include. The gap most worth closing is internal mail: gateways inspect what crosses the boundary, so an attacker already inside a mailbox is invisible to them. API-based tools address exactly that, which is why they are often a better addition than a second filter in front.

Integrated cloud email security connects to your mail platform through its API and inspects messages after delivery rather than in the delivery path. That means it can see internal mailbox-to-mailbox mail, it can retract a message from every mailbox once a campaign is identified, and it deploys without changing MX records. The trade-off is the window between delivery and inspection, usually short but real.

It works for the thing it can affect. Training will not make people infallible, and any programme sold on that basis is overselling. What it reliably improves is reporting — how quickly somebody tells you something looks wrong. That matters enormously, because a campaign identified within minutes can be retracted from every other mailbox before it is opened. Optimise for report rate rather than click rate, and never make reporting feel risky.

Regularly, realistically, and without punishment. Measure the report rate and the time to first report rather than the click rate, because those are the numbers that change outcomes. Publish results as an organisational metric rather than an individual one. Programmes that name and shame reliably produce staff who stay silent when they click, which is considerably more dangerous than clicking.

Register the obvious variants of your own domain where it is economic, and monitor for newly registered domains resembling yours — new registrations are a common precursor to a targeted campaign. Flagging external senders visually in the mail client helps, because a lookalike domain relies entirely on the reader not examining the address closely.

Yes. Mail platform audit logs, authentication events and reported phishing feed the same 24×7 operations centre as the rest of your estate, so a reported message reaches an analyst rather than a shared mailbox. That connection matters most during an actual mailbox compromise, when the question shifts quickly from “is this email bad” to “what else has this account done” — see managed SOC services.

Speed matters more than anything else. Terminate active sessions rather than only resetting the password, because an existing token survives a password change. Then check what was altered while the attacker had access: forwarding rules, delegate permissions, inbox rules that move messages to obscure folders, MFA methods added. Those persistence mechanisms routinely outlive the password reset, and they are how a “resolved” incident quietly continues.

Yes, and it matters more than it sounds. Investigating a compromise means reconstructing who received what, who else was targeted and what left the organisation. Without retained, searchable mail that reconstruction is guesswork, and it is needed at exactly the moment nobody has time to build it.

By mailbox count and by which components you take — authentication work is a fixed piece of consulting, gateway or API tooling is licensed per mailbox, and simulation and training run per user per year. We will tell you honestly which parts your existing platform licence already covers before quoting anything on top of it.