Email Security Beyond the Spam Filter

Spam filtering is a solved problem in the sense that mass unsolicited mail mostly does not reach inboxes. The attacks that cost businesses money now are a different shape, and filtering is a weak defence against them.

The expensive attack is a plain text message, from a real mailbox, with no attachment and no link, asking for something that sounds routine. There is nothing for a filter to detect, because there is nothing malicious in the message — the malice is in the context.

The attack that actually takes the money

The pattern, repeatedly:

1. Credentials are obtained — phishing, reuse, or an infostealer on a home machine
2. The attacker signs in and watches, often for weeks, learning how the business communicates
3. They create a mailbox rule to hide their activity — moving replies to an obscure folder, or deleting mail containing certain words
4. They wait for a transaction: an invoice, a property settlement, a payroll change
5. At the right moment, they send updated payment details, in the right tone, in a real thread
6. The money is sent to an account that is emptied within hours

No malware, no attachment, no suspicious link. The message comes from a legitimate mailbox, passes every authentication check, and arrives in an existing conversation.

The controls that match this threat

1. Verbal verification for payment changes

The highest-value control, and it costs nothing.

Any change to payment details is verified by voice, using a number already on file — never a number from the email requesting the change. No exceptions for urgency, seniority or inconvenience.

This stops the attack even when every technical control has failed. Write it down, train everyone who can initiate a payment, and make it explicit that nobody will be criticised for applying it to the chief executive.

2. MFA, with the gaps closed

Necessary and not sufficient, but still the control that prevents most initial access. The gaps worth checking:

• legacy authentication protocols that bypass it entirely — block them
• MFA registration itself, which should require MFA or a trusted location
• recovery methods pointing at phone numbers of departed staff
• service accounts excluded "temporarily" years ago

Prefer phishing-resistant methods where possible. Push fatigue and real-time relay attacks defeat simple approve/deny prompts; number matching helps, passkeys help more.

3. Monitor mailbox rules

The step attackers take that legitimate users rarely do: a rule that moves or deletes mail based on keywords like "invoice", "payment" or "bank", or that forwards externally.

Alert on:

• creation of forwarding rules to external addresses
• rules that delete or move mail to obscure folders
• rules created shortly after a sign-in from an unusual location

This is one of the highest-signal, lowest-noise detections available in a mail platform, and it catches the attack during the reconnaissance phase — before money moves.

4. Email authentication, configured properly

SPF, DKIM and DMARC do not stop a compromised account, but they do stop impersonation of your domain from elsewhere.

The common failure is deploying DMARC at p=none and never moving. At none you get reports and no protection. Work through the reports, fix the legitimate senders, and progress to quarantine and then reject. The sending systems that break are usually a marketing platform or an application server nobody had documented — which is worth finding anyway.

5. External sender marking

A banner on mail from outside the organisation. Simple, effective against display-name impersonation, and it degrades with familiarity — so pair it with something stronger for high-risk actions.

6. Impersonation protection

Most platforms can flag mail where the display name matches an executive but the address does not, or where the domain is a lookalike. Configure it for your actual executives and your common vendors rather than leaving it generic.

7. Detect the sign-in, not just the message

Impossible travel, unfamiliar sign-in properties, sign-ins from anonymising services. The compromise is the event worth catching, because everything after it looks legitimate.

Pair detection with an automated response: revoke sessions and require re-authentication rather than raising an alert somebody reads tomorrow.

What to do when it happens anyway

Have this written before you need it:

1. Revoke all sessions for the account, not just reset the password. A password reset without session revocation leaves the attacker signed in
2. Reset credentials and re-register MFA
3. Check mailbox rules and forwarding — and remove them
4. Check for added MFA methods and app passwords, which are a persistence mechanism
5. Review sent items and deleted items to see what was sent in the user's name
6. Identify who was contacted, and warn them directly by phone
7. If money moved, contact the bank immediately. The window for recall is hours, not days
8. Preserve logs before they age out

Step seven is time-critical and routinely delayed while people establish what happened. Make the call first, investigate second.

The training that works

Generic phishing awareness has limited effect against this attack, because the message is not suspicious.

What works is specific: we will never change bank details by email; every change is verified by phone on a number we already hold; if anyone asks you to bypass that, including me, the answer is no.

That is a rule people can apply under pressure, which is the only kind worth teaching.