Hardening Microsoft 365 against phishing: the controls that actually matter
Phishing remains the favourite way in: it is cheap, it scales, and it targets the person, not the firewall. Microsoft 365 has an overwhelming number of switches to flip. This is the order I would apply them in, from highest to lowest return.
1. Block legacy authentication (always first)
Old protocols like POP3, IMAP or SMTP AUTH do not support MFA. While they remain open, your second factor is optional for the attacker: a legacy client plus a stolen password is enough.
Create a Conditional Access policy blocking "Other clients" for all users — but first review sign-in logs filtered by Client app = Other clients so you do not break a service mailbox still using it.
2. Phishing-resistant MFA (not all MFA is equal)
SMS or simple push MFA can be defeated with MFA fatigue or AiTM phishing proxies (Evilginx) that steal the authenticated session cookie. Prioritise:
- Number matching in Microsoft Authenticator, as a minimum.
- FIDO2 / passkeys for privileged accounts: they are domain-bound, so an AiTM proxy cannot replay them.
- Conditional Access requiring a compliant or hybrid-joined device for admins.
3. Email authentication: SPF, DKIM and DMARC
- SPF: which servers may send on your behalf.
- DKIM: cryptographic signature proving the message was not altered.
- DMARC: what to do when SPF/DKIM fail, and where to send reports.
; Start in monitoring mode (breaks nothing) and collect reports
_dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1"
; Once reports confirm legitimate mail passes, tighten:
_dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com"
; End goal:
_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"
p=reject. Spend weeks at p=none reading reports: there is almost always a legitimate service (CRM, billing, newsletters) sending as you that you would knock offline.4. Defender for Office 365: the policies that matter
Anti-phishing: impersonation protection
This is the crown jewel and many organisations leave it at defaults. Manually add your protected users (CEO, CFO, HR, finance) and protected domains. Then an email from "Chief Financial Officer <gmail.com>" gets flagged even though the domain is not yours. Enable mailbox intelligence too, which learns who each user normally talks to.
Safe Links and Safe Attachments
Safe Links rewrites URLs and checks them at click time — crucial, because many campaigns weaponise the destination after delivery. Enable it for Teams and Office as well. Safe Attachments detonates attachments in a sandbox before delivery.
Safety tips and external sender banner
Native safety tips and a clear "external email" banner are cheap and genuinely help users hesitate at the right moment.
5. Auditing and detection (assume something gets through)
- Suspicious inbox rules: auto-moving to "RSS" or deleting mail containing "invoice" or "transfer" — the classic BEC fingerprint.
- Newly created external forwarding.
- Impossible travel and sign-ins from unusual ASNs.
- OAuth app consent with broad permissions: a vector that bypasses MFA entirely.
// Sentinel/Defender — external forwarding rule creation
OfficeActivity
| where Operation in ("New-InboxRule", "Set-InboxRule")
| where Parameters has_any ("ForwardTo", "RedirectTo", "ForwardAsAttachmentTo")
| project TimeGenerated, UserId, Operation, Parameters, ClientIP
Summary: where to start on Monday
- Block legacy authentication.
- Phishing-resistant MFA on privileged accounts.
- DMARC at
p=noneand start reading reports. - Protected users and domains in the anti-phishing policy.
- Alert on forwarding rule creation.
None of these require buying anything new if you already hold the licences: it is configuration and judgement. And that combination is almost always what removes the most attack surface.