Email is still the easiest place to impersonate someone. Business email compromise (BEC), where attackers pose as executives, suppliers or colleagues to trigger payments or steal data, relies on two identity weaknesses: domains that anyone can spoof, and real mailboxes that attackers take over. SPF, DKIM and DMARC let receiving servers check whether a message genuinely comes from your domain, and large mailbox providers now require them from bulk senders. Mailbox takeover, malicious inbox rules and over-privileged mail applications are an identity and access problem. This guide covers both, and the payment controls that stop BEC even when email is fooled.
Key takeaways
- SPF, DKIM and DMARC authenticate your domain. Move DMARC to enforcement (quarantine or reject) once you know all legitimate senders.
- Many BEC attacks use real, compromised mailboxes or look-alike domains, which DMARC on your own domain cannot stop.
- Protect mailboxes with phishing-resistant MFA, and watch for new inbox rules, forwarding and OAuth app grants.
- Restrict application access to mail. OAuth apps with full mailbox access are high-value targets.
- Stop the money, not just the message: out-of-band verification for bank detail changes and payments.
How BEC works
| Technique | Example | Main control |
|---|---|---|
| Exact domain spoofing | A message forged to appear from your own domain | DMARC enforcement |
| Look-alike domain | A domain one character different from a supplier's | Domain monitoring, external sender warnings, payment verification |
| Display name deception | A free webmail account using the CEO's name | External tagging, user awareness |
| Compromised mailbox | Attacker signs in to a real supplier or employee mailbox and replies in existing threads | MFA, session protection, anomaly detection, payment verification |
| Malicious inbox rules | Rules hide replies or forward mail to the attacker | Rule monitoring and restrictions on external forwarding |
| Malicious or over-privileged mail app | An OAuth app with permission to read or send all mail | App consent governance |
Authenticating your domain
- SPF (RFC 7208) lists servers allowed to send mail for your domain.
- DKIM (RFC 6376) signs messages with a key published in DNS, so receivers can check they were not altered and came from an authorised sender. Treat DKIM keys as NHI credentials: rotate them and protect the private keys.
- DMARC (RFC 7489) tells receivers what to do when SPF or DKIM fail alignment with the visible From domain, and sends you reports.
- BIMI can display your logo in supporting mail clients, but requires DMARC enforcement.
A path to enforcement
- Publish DMARC at
p=nonewith reporting, and inventory every service that sends as your domain (marketing, ticketing, HR, finance systems). - Fix SPF and DKIM for each legitimate sender.
- Move to
p=quarantine, thenp=reject, watching reports at each step. - Protect parked and unused domains with a reject policy and a null SPF record.
Since 2024 Google and Yahoo have required bulk senders to authenticate with SPF, DKIM and DMARC, and Microsoft introduced similar requirements for high-volume senders to its consumer mail services in 2025.
Protecting mailboxes and mail access
- Enforce phishing-resistant MFA on email accounts, especially for finance, executives and their assistants. See the MFA Guide.
- Block legacy protocols that bypass MFA.
- Alert on new inbox rules, external forwarding and mailbox delegation changes.
- Protect sessions and detect token replay. See the Token and Session Security Guide.
- Restrict which OAuth apps may be granted mail permissions, and prefer scoped permissions over tenant-wide full mailbox access. The Midnight Blizzard breach abused an OAuth application with full access to mailboxes. See the SaaS and OAuth App Governance Guide.
- Scope service accounts and applications that send mail, and protect SMTP and email API credentials. The Gravity SMTP vulnerability exposed email service API keys and SMTP passwords from WordPress sites.
Stopping the payment
- Verify every change of supplier bank details by calling a number already held on file, never one in the email.
- Require dual approval for new payees and payments above a threshold.
- Apply a cooling-off period to newly changed bank details.
- Treat urgency and secrecy in payment requests as warning signs, and give finance staff explicit permission to delay.
The Deepfake and AI Impersonation Guide covers the same controls for voice and video impersonation.
Detection
- Sign-ins to mailboxes from unfamiliar locations or infrastructure, followed by rule creation.
- Replies inserted into existing threads about invoices or payments.
- Newly registered look-alike domains of your brand or key suppliers.
- DMARC reports showing unknown senders using your domain.
Email and AI agents
AI assistants that read and send email act with mailbox permissions and can be manipulated by content in the messages they process. The EchoLeak vulnerability showed how a crafted email could make an assistant leak data. Limit agent mail permissions, require approval before agents send external mail or change settings, and log agent actions. See the Enterprise AI Copilot Security Guide.
Practitioner checklist
- Inventory senders, fix SPF and DKIM, and move DMARC to reject on all domains.
- Protect parked domains and monitor for look-alike registrations.
- Enforce phishing-resistant MFA on mailboxes and block legacy protocols.
- Alert on inbox rules, forwarding and delegation changes.
- Govern OAuth apps and service accounts with mail access; rotate DKIM keys and protect SMTP credentials.
- Require out-of-band verification and dual approval for payment and bank detail changes.
- Limit and log AI assistant permissions over email.
Standards and references
- RFC 7489: DMARC
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- Google: Email sender guidelines
- FBI Internet Crime Complaint Center (IC3): BEC reporting and public service announcements
Related NHI Mgmt Group resources: Deepfake and AI Impersonation Guide · SaaS and OAuth App Governance Guide · MFA Guide · Identity Fraud Prevention Guide
