The email attacks that succeed against Microsoft 365 and Google Workspace tenants today are mostly not malware. They are business email compromise, OAuth consent phishing, and adversary-in-the-middle login pages that relay a one-time code in real time. Each defeats a different control, and the defences are configuration rather than purchase: phishing-resistant authentication, app consent governance, DMARC at enforcement, and alerting on mailbox rules.
The threats, and what each one defeats
| Threat | How it works | What it defeats |
|---|---|---|
| Business email compromise / invoice fraud | A convincing message, often from a genuinely compromised supplier mailbox, changing payment details | Every email filter, because the mail is legitimate and authenticated |
| OAuth consent phishing | A real Microsoft or Google consent screen for an attacker-controlled app requesting mail read and send scopes | Password resets and MFA — the token persists afterwards |
| Adversary-in-the-middle phishing | A proxy login page that captures credentials and relays the one-time code, then steals the session cookie | SMS and app-based one-time codes |
| Lookalike domain impersonation | examp1e.com or example-invoices.com, correctly authenticated for the attacker's own domain | SPF, DKIM and DMARC, all of which pass for the attacker's domain |
| Mailbox rule abuse | After compromise, rules that forward externally and delete replies | User awareness — the victim sees nothing |
| Malicious links and attachments | Still present, now usually a second stage | Little, if filtering is configured |
Note the pattern: four of the six are unaffected by content filtering. That is why "we have advanced threat protection" is not an answer.
Do these first
1. Phishing-resistant authentication. Passkeys or hardware security keys for administrators, finance, executives and anyone handling payments. One-time codes from SMS or an authenticator app can be relayed by a proxy in real time; a passkey is bound to the origin and cannot be. Number matching and push approval are an improvement over codes but are not equivalent.
2. Disable legacy authentication. Microsoft retired basic authentication for Exchange Online in 2022, but check your tenant for exceptions, SMTP AUTH usage and app passwords still in circulation. In Google Workspace, turn off less secure app access and require OAuth. Legacy protocols bypass conditional access and multi-factor entirely.
3. Govern OAuth app consent. Turn off user consent for applications that request sensitive scopes, and route requests through an admin consent workflow. Then audit what is already granted: any app with mail read, mail send or full mailbox scopes that nobody recognises. This is the most commonly skipped control and the one that most often turns a single phish into months of access, because revoking a password does not revoke a token.
4. Alert on mailbox rule and forwarding changes. Block automatic external forwarding by policy, and alert on new forwarding rules, new delegation and new "move to RSS Feeds" style rules. Attacker-created rules are the standard follow-up to a compromise.
5. Conditional access that matches your risk. Block legacy protocols, require compliant or managed devices for administrative roles, and restrict access from countries you do not operate in. Keep a break-glass account excluded from conditional access, with a long password, a hardware key and monitoring on it.
Then these
6. DMARC at enforcement, plus MTA-STS and TLS-RPT. DMARC at p=reject stops exact-domain spoofing of your domain — the attack that lands in your own staff's inboxes as a message from the CEO. Add np=reject for non-existent subdomains. MTA-STS and TLS-RPT cover inbound transport: MTA-STS tells sending servers to require TLS for your domain, TLS-RPT tells you when that fails. These protect inbound mail to you, where SPF/DKIM/DMARC protect your outbound identity.
7. Impersonation protection for your own people and your top suppliers. Both platforms can flag display-name impersonation and lookalike domains. Configure it with your actual executive names and your highest-value supplier domains, because the default lists are empty.
8. External sender warnings on messages from outside the tenant, and a stronger banner on first-contact senders. Keep the wording short; a banner on every message is a banner nobody reads.
9. Outbound protection. Outbound spam policies and per-mailbox sending limits mean a compromised mailbox cannot send 50,000 messages before anyone notices — which is also what protects your domain's reputation. This is where email security and deliverability are the same problem: a compromise that sends spam from your domain produces blocklist listings that outlast the incident.
10. Audit logging and retention. Confirm logs are enabled, confirm the retention period covers your realistic detection lag, and confirm someone can actually query them. An incident investigated with 30 days of logs against a 90-day compromise produces no answers.
Encryption and data loss, briefly
Opportunistic TLS covers mail in transit between competent providers and is the baseline. For content that must not be readable by the provider or by an interceptor, the options are S/MIME (key distribution is the hard part), portal-based secure messaging (the recipient collects the message from a web page), or end-to-end encrypted mail between participating systems. Data loss prevention rules on outbound mail — card numbers, national identifiers, bulk personal data — catch mistakes rather than attackers, which is still worth having because mistakes are more common.
Process controls that beat technical ones
- Payment-detail changes are confirmed by phone, to a number already on file, never to a number in the email. This single rule stops most invoice fraud.
- A one-click internal report path and no blame for using it. The value of a report is finding out who else received the same message.
- Offboarding that revokes tokens, not just passwords.
- A tested restore and eDiscovery path. Retention policies are not backups.
What not to do
- Do not rely on one-time codes for privileged accounts.
- Do not leave user app consent enabled for sensitive scopes.
- Do not allow automatic external forwarding by default.
- Do not add a security product before configuring the controls your platform already includes.
- Do not leave DMARC at
p=noneindefinitely — monitoring without enforcement protects nobody. - Do not block a reported sender and consider the incident closed; look for the token, the rule and the session.
- Do not treat lookalike-domain attacks as a DMARC failure. DMARC cannot help you there; impersonation protection and user training can.
MailPilot sits on the deliverability side of this boundary: it checks SPF, DKIM and DMARC on your domains as delivered, warms mailboxes over OAuth or SMTP/IMAP, and tracks per-mailbox reputation and per-provider inbox placement daily — so if a compromise or a spoofing campaign damages your sending reputation, you see it in placement data rather than in a customer telling you their invoices stopped arriving.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial