Chapter 72 — Email security, phishing resilience, and BEC
In one sentence
Email security is not just spam filtering; it is identity, authentication, brand protection, user workflow, payment controls, and incident response.
The controls
| Control | What it does | What it does not do |
|---|---|---|
| SPF | Says which servers may send for a domain | Does not authenticate the visible From by itself |
| DKIM | Cryptographically signs mail | Does not prove the sender is trustworthy |
| DMARC | Aligns visible From with SPF/DKIM and publishes policy | Does not stop lookalike domains |
| MTA-STS/TLS-RPT | Improves SMTP transport security | Does not secure mailbox content after delivery |
| User reporting | Turns users into sensors | Needs fast triage and feedback |
| Payment controls | Stops BEC impact | Must be out-of-band and enforced |
BEC scenario
An attacker compromises a vendor mailbox and replies in an existing invoice thread:
Please use our updated bank details for this month's payment.
All technical signals may look legitimate because the mailbox really is the vendor's. The defense is business-process control:
- payment-detail changes require out-of-band verification;
- finance workflows flag first-time or changed bank accounts;
- high-value payments require dual approval;
- mailbox rules/forwarding changes are monitored;
- vendor compromise playbooks exist.
Incident response checklist
- preserve message headers and original
.eml; - check mailbox sign-ins, impossible travel, OAuth grants, inbox rules, forwarding;
- revoke sessions and rotate credentials;
- search for similar messages across the tenant;
- notify affected counterparties;
- if money moved, involve bank/legal immediately.
Common mistakes
- Believing DMARC stops all phishing.
- Training users but not fixing payment workflows.
- Ignoring malicious OAuth consent grants.
- Deleting messages before preserving headers.