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, and AI assistants that read mail add a new one. This guide covers domain authentication, mailbox and application access, detection, and the payment controls that stop BEC even when email is fooled. It is for email administrators, identity and security teams, and finance leaders who own payment processes.
Key takeaways
- Authenticate every domain you own: publish SPF, sign with DKIM and run DMARC with reporting, then move to an enforcing policy once every legitimate sender is known. RFC 9989 now replaces RFC 7489 as the DMARC standard.
- DMARC only protects your exact domain: many BEC attacks use real, compromised mailboxes or look-alike domains, which DMARC on your own domain cannot stop.
- Treat the mailbox as a high-value identity: phishing-resistant MFA, no legacy protocols, and alerts on new inbox rules, external forwarding and OAuth consent grants.
- Govern applications and agents with mail access: an OAuth app or AI assistant with full mailbox permissions is a non-human identity that attackers target and abuse.
- Stop the money, not just the message: out-of-band verification for bank detail changes, dual approval for new payees, and a rehearsed process to recall funds quickly.
How BEC works
The FBI's Internet Crime Complaint Center (IC3) defines BEC as a scam that targets businesses and individuals who make legitimate transfer-of-funds requests, frequently carried out by compromising real business or personal email accounts through social engineering or computer intrusion. According to the IC3 2024 Internet Crime Report, BEC accounted for 21,442 complaints and reported losses of $2,770,151,146 in 2024, the second highest loss figure of any crime type in that report. A 2024 IC3 public service announcement on BEC reports that the scam has been seen in all 50 US states and 186 countries, and that international banks in the United Kingdom and Hong Kong often acted as an intermediary stop for stolen funds.
Some techniques need no access to your systems; others start with a stolen password.
| 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 | Phishing-resistant MFA, session protection, anomaly detection, payment verification |
| Malicious inbox rules | Rules hide replies or forward mail to the attacker | Rule monitoring and blocking automatic external forwarding |
| Malicious or over-privileged mail app | An OAuth app with permission to read or send all mail | App consent governance and scoped application access |
| Manipulated AI assistant | A crafted email instructs an assistant with mailbox access to leak data | Least privilege for agents, approval for sensitive actions, content isolation |
MITRE ATT&CK records both rule techniques: T1114.003 Email Forwarding Rule and T1564.008 Email Hiding Rules, where rules hide messages containing words such as "phish" so the victim never sees warnings. See the Phishing Guide for the initial access side.
Authenticating your domain
Three DNS-published standards let a receiving server decide whether a message really comes from the domain in the visible From header. The NCSC describes them as complementary: SPF publishes the addresses trusted to send for your domain, DKIM cryptographically signs mail and, unlike SPF, survives forwarding, and DMARC sets the policy for mail that fails both and generates reports.
- SPF (RFC 7208) lists the hosts allowed to send for a domain. RFC 7208 caps evaluation at 10 DNS-querying terms and returns a permanent error if a record exceeds it, so a record that keeps growing with every new SaaS sender will eventually break.
- DKIM (RFC 6376) signs each message with a private key; receivers fetch the public key from DNS using the selector in the signature. Treat DKIM private keys as non-human identity credentials: keep them in a managed store, rotate them by publishing a new selector, and revoke old selectors. Google requires keys of at least 1024 bits for mail to personal Gmail accounts and recommends 2048 bits. See the Secrets Management Guide.
- DMARC requires that SPF or DKIM passes for a domain aligned with the From domain, tells receivers how to treat mail that fails, and asks them to send reports. In May 2026 the IETF published RFC 9989 as a Standards Track DMARC specification, obsoleting the informational RFC 7489.
- BIMI lets a domain publish a logo that supporting mailbox providers may display beside authenticated mail. According to the BIMI Group, it requires DMARC at quarantine or reject, and many providers also require a Verified Mark Certificate or Common Mark Certificate.
What changed in RFC 9989
RFC 9989 replaces the Public Suffix List with a "DNS Tree Walk" to find the organisational domain, removes the pct tag (which, the RFC notes, was rarely applied accurately except at 0 or 100) and adds a t test-mode tag, plus np for non-existent subdomains and psd for public suffix operators. Reporting moves to companion documents RFC 9990 and RFC 9991. Review any existing record that relies on pct.
| Tag | What it does (RFC 9989) | Practical guidance |
|---|---|---|
p | Policy for the domain: none, quarantine or reject. Treated as none if absent | Start at none with reporting; move to quarantine, then reject where safe |
sp | Policy for existing subdomains | Set explicitly so subdomains cannot be used as a gap |
np | Policy for non-existent subdomains | Set to reject: nobody legitimately sends from names that do not exist |
rua | Where aggregate reports go. No tag, no reports | Always publish and send reports to a tool someone reads |
adkim / aspf | Strict or relaxed alignment; relaxed is the default | Relaxed suits most organisations; strict for high-value or parked domains |
t | Test mode: asks receivers not to apply the stated policy | Use briefly when stepping up policy, then remove |
A path to enforcement
- Publish DMARC at
p=nonewith anruaaddress, and inventory every service that sends as your domain (marketing, ticketing, HR, finance, CRM and monitoring systems). - Fix SPF and DKIM for each legitimate sender, preferring aligned DKIM because it survives forwarding. RFC 9989 says domains publishing
p=rejectmust not rely on SPF alone and must apply valid DKIM signatures. - Move to
p=quarantine, thenp=reject, watching reports at each step. For domains whose staff post to Internet mailing lists, RFC 9989 advises caution withreject: runnonefor at least a month andquarantinefor as long again, compare the results, and consider sending bulk and transactional mail from dedicated subdomains held at reject. - Protect parked and unused domains. GOV.UK guidance sets out four DNS records for domains that never send: SPF
v=spf1 -all, DMARC withp=rejectandsp=reject, an empty wildcard DKIM record, and a null MX record.
Mailbox provider requirements
Since February 2024, Google has required anyone sending to personal Gmail accounts to set up SPF or DKIM, and senders of more than 5,000 messages a day to set up SPF, DKIM and DMARC (a policy of none is accepted), align the From domain with SPF or DKIM, support one-click unsubscribe and keep spam rates below 0.3%. Yahoo's sender requirements, enforced from February 2024, are similar: SPF and DKIM, a valid DMARC policy of at least p=none that passes, and one-click unsubscribe. See the DMARC, SPF and DKIM Guide and the Email Authentication for Developers Guide.
Protecting mailboxes and mail access
Domain authentication does nothing once an attacker holds a real mailbox: their messages pass SPF, DKIM and DMARC because they are genuine.
Human sign-in
- Phishing-resistant MFA: enforce it on every mailbox, starting with finance, executives, their assistants and anyone who can change supplier records. See the Phishing-Resistant MFA Guide.
- Legacy protocols: block protocols and clients that cannot perform modern authentication, because they bypass MFA.
- Sessions and tokens: adversary-in-the-middle phishing steals session cookies rather than passwords. Bind sessions where possible and detect token replay. See the AiTM Phishing Guide and the Token and Session Security Guide.
- Forwarding and delegation: block automatic forwarding to external recipients by default. Microsoft documents that disabling it in outbound spam policies also disables inbox rules and admin mailbox forwarding that redirect mail outside the organisation, and that new Microsoft 365 organisations have had it off by default since 2021.
Applications and service accounts
Applications that read or send mail are non-human identities, and often more powerful than any single user. In the Microsoft Midnight Blizzard Breach 2024, Microsoft reports that the attacker used a password spray to compromise a legacy, non-production test tenant account without MFA, then found a legacy test OAuth application with elevated access and used malicious OAuth applications to authenticate to Exchange Online and target corporate mailboxes. Microsoft advises defenders to review applications holding the EWS.AccessAsUser.All and EWS.full_access_as_app permissions, remove those no longer needed, audit identities with ApplicationImpersonation rights, and use role-based access control for applications in Exchange Online so an app reaches only the mailboxes it needs.
- Consent governance: restrict who may consent to applications requesting mail permissions. Microsoft's guidance on illicit consent grants describes attackers tricking users into granting a malicious app access to mail without needing an account in the organisation, and recommends weekly review of consent grants in large tenants. See the Entra ID Applications and Consent Guide and the SaaS and OAuth App Governance Guide.
- Sending services: give each system that sends mail its own scoped credential (SMTP relay account or email API key), store it in a secrets manager, and rotate it. See the Service Account Security Guide.
Stopping the payment
The most reliable BEC controls sit in the finance process, where they work however the message was sent. MITRE lists out-of-band verification (mitigation M1060) for critical actions initiated by email, including financial transactions, and the IC3 recommends using secondary channels to verify requests to change account information.
| Control | What it stops | Owner |
|---|---|---|
| Call back on a number already held on file before changing bank details | Supplier impersonation from spoofed, look-alike or compromised mailboxes | Accounts payable |
| Dual approval for new payees and payments above a threshold | A single deceived employee releasing funds | Finance controller |
| Cooling-off period for newly changed bank details | Urgent first payments to attacker accounts | Treasury |
| Written permission for staff to delay urgent or secret requests | Pressure tactics that impersonate executives | Leadership |
| Rehearsed recall procedure with your bank | Funds leaving reach before anyone acts | Treasury and security |
Speed matters after a fraudulent transfer. The IC3 advises contacting your financial institution immediately to request a recall and filing a complaint at ic3.gov regardless of the amount, and its 2024 report says most Financial Fraud Kill Chain freezes initiated by its Recovery Asset Team involve BEC. See the Authorised Push Payment (APP) Fraud Guide and the Payment Fraud Guide. The Deepfake and AI Impersonation Guide covers the same controls for voice and video impersonation.
Detection
Mailbox auditing has to be on before an incident: Microsoft notes that scoping an illicit consent attack depends on mailbox and admin activity auditing having been enabled beforehand.
- Sign-in then rule: a sign-in from unfamiliar infrastructure followed within minutes by a new inbox rule, forwarding change or delegation grant.
- Suspicious rules: rules that delete or move messages containing security or payment keywords, or that forward externally (ATT&CK T1564.008 and T1114.003). Microsoft's guidance on Outlook rules and custom forms attacks describes rules that launch applications as a persistence mechanism.
- Thread hijacking: replies inserted into invoice or payment threads, often with a changed reply-to address.
- Application behaviour: new consent grants with admin consent, apps granted full_access_as_app, and sudden increases in mailbox API calls after an app's credentials change.
- Domain signals: newly registered look-alike domains of your brand and key suppliers, and DMARC aggregate reports showing unknown sources using your domain.
Feed these signals into identity threat detection rather than leaving them in the mail console. See the ITDR Guide and the Phishing Incident Response Playbook.
Email and AI agents
AI assistants and agents that read and send email act with mailbox permissions and process content written by outsiders. OWASP's LLM01:2025 Prompt Injection describes indirect injection, where instructions hidden in external content change a model's behaviour, and lists an LLM-powered email assistant among its example scenarios. The EchoLeak 2025 flaw (CVE-2025-32711) showed the pattern: according to BleepingComputer, a crafted email carried a hidden prompt that, once retrieved into Microsoft 365 Copilot's context, could make it exfiltrate internal data without user interaction. Microsoft fixed it server-side and reported no evidence of exploitation.
- Least privilege: give agents only the mail scopes and mailboxes their task needs, using their own identity rather than a user's full delegation. See the AI Agent Authorisation Guide.
- Human approval: require approval before an agent sends external mail, creates rules or forwarding, or acts on payment instructions. OWASP recommends human-in-the-loop controls for privileged operations.
- Content isolation: separate and label untrusted inbound content, and consider excluding external mail from retrieval for assistants that do not need it.
- Logging: record every agent action against a named agent identity so it can be investigated like a user. See the Enterprise AI Copilot Security Guide and the Prompt Injection Guide.
Common failure patterns
- DMARC parked at p=none: organisations publish a monitoring policy to meet mailbox provider rules and never move on, so spoofed mail is still delivered and reports go unread.
- Forgotten senders: a marketing platform or ticketing tool sends as the main domain without aligned DKIM, so the move to enforcement is delayed indefinitely for fear of breaking it.
- Parked domains left open: defensively registered or legacy domains carry no SPF or DMARC record and become a clean spoofing source.
- MFA with exceptions: a test tenant, legacy protocol or service account without MFA becomes the way in, as Microsoft reported for the initial access in the Microsoft Midnight Blizzard Breach 2024.
- Password reset without cleanup: the user's password is changed but inbox rules, forwarding, OAuth grants and active sessions stay in place. ATT&CK notes forwarding rules can keep access after credentials are reset.
- Bank details changed by email: accounts payable accepts a change request and verifies it by replying to the same thread or calling the number in the message.
- Agents with user-level mail access: an assistant inherits a user's full mailbox and send rights, so a single injected message can trigger data leakage or outbound mail.
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 |
|---|---|---|---|---|
| Domain authentication (SPF, DKIM, DMARC) | PR.DS-02, PR.PS-01 | SI-08, SC-08 | A.5.14, A.8.9 | 9.5 |
| Mailbox authentication and MFA | PR.AA-01, PR.AA-03 | IA-02(01), IA-02(02), IA-05 | A.5.17, A.8.5 | 6.3, 6.5 |
| Mail applications and service accounts | PR.AA-05 | AC-02, AC-06 | A.5.15, A.5.18, A.8.2 | 5.5, 6.1, 6.8 |
| Rule, forwarding and consent monitoring | DE.CM-03, DE.AE-03 | AU-02, AU-06, SI-04 | A.8.15, A.8.16 | 8.2, 8.11 |
| Payment verification and staff awareness | PR.AT-01, PR.AT-02 | AT-02(03) | A.6.3 | 14.2, 14.9 |
| Supplier relationships | GV.SC-04, GV.SC-07 | SR-06 | A.5.19, A.5.20 | 15.1, 15.4 |
| BEC incident response and fund recall | RS.MA-01, RS.MI-01 | IR-04 | A.5.24, A.5.26 | 17.3, 17.4 |
| AI assistants with mail access (also OWASP LLM01:2025) | PR.AA-05 | AC-06 | A.5.15 | 6.8 |
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Share of owned domains (sending and parked) at DMARC quarantine or reject | Spoofing exposure across the estate | Up, towards all parked domains at reject |
| Share of DMARC-passing mail authenticated by aligned DKIM | Resilience to forwarding and readiness for reject | Up |
| Unknown sources in DMARC aggregate reports | Unmanaged senders or active spoofing | Down |
| Mailboxes without phishing-resistant MFA, by role | Takeover exposure for finance and executives | Down, to zero for high-risk roles |
| Applications holding tenant-wide mail permissions | Non-human identity blast radius | Down |
| Mailboxes with external forwarding allowed | Silent exfiltration paths | Down, with documented exceptions |
| Bank detail changes verified by call-back | Whether the payment control is followed | Up, to 100% |
| Time from suspicious payment report to bank recall request | Readiness to recover funds | Down |
Implementation roadmap
| Phase | Domain and mail | Identity and access | Finance and response |
|---|---|---|---|
| First 30 days | Inventory domains and senders; publish DMARC at none with reporting; lock parked domains with the GOV.UK records | Phishing-resistant MFA for finance and executives; block legacy protocols; turn off automatic external forwarding | Call-back rule for bank detail changes; confirm the bank recall contact and IC3 reporting route |
| Days 31 to 90 | Fix SPF and aligned DKIM for each sender; move main domains to quarantine; set np=reject | Review consent grants and apps with mail permissions; scope app access to named mailboxes; alerts on rules and forwarding | Dual approval and cooling-off period; BEC scenario in the incident response plan |
| Days 91 to 180 | Move to reject where reports support it; dedicated subdomains for bulk mail; DKIM key rotation schedule | Extend MFA to all mailboxes; agent identities with least-privilege mail scopes and approval steps | Exercise a BEC incident end to end, including recall; report metrics to finance leadership |
See the Identity Incident Response Playbook for the response steps and the Third-Party Risk Management (TPRM) Guide for supplier verification.
Practitioner checklist
- Inventory every domain and every service that sends as it.
- Publish SPF within the 10-lookup limit, sign all mail with aligned DKIM keys of 2048 bits where supported, and rotate keys.
- Run DMARC with reporting, move to quarantine and then reject where reports support it, and set
spandnpexplicitly. - Lock parked domains with null SPF, reject DMARC, an empty DKIM record and a null MX record.
- Enforce phishing-resistant MFA on mailboxes and block legacy protocols.
- Block automatic external forwarding and alert on new inbox rules and delegation changes.
- Review OAuth consent grants and remove unneeded full-mailbox permissions such as full_access_as_app.
- Give sending systems scoped credentials held in a secrets manager.
- Require call-back verification, dual approval and a cooling-off period for bank detail changes.
- Agree a recall procedure with your bank and rehearse it.
- Limit, approve and log AI assistant actions over email.
Standards and references
- IETF: RFC 9989 Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
- IETF: RFC 7208 Sender Policy Framework (SPF)
- IETF: RFC 6376 DomainKeys Identified Mail (DKIM) Signatures
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- CIS: Control 9 Email and Web Browser Protections
- NCSC: Email security and anti-spoofing
- GOV.UK: Protect domains that do not send email
- Google: Email sender guidelines
- Microsoft: Midnight Blizzard guidance for responders on nation-state attack
- MITRE ATT&CK: T1114.003 Email Forwarding Rule
- FBI IC3: 2024 Internet Crime Report
- FBI IC3: Business Email Compromise public service announcement
Related NHI Mgmt Group resources: Email Security Guide · Deepfake and AI Impersonation Guide · SaaS and OAuth App Governance Guide · Phishing-Resistant MFA Guide · Identity Fraud Prevention Guide