Aggressive Impersonation Filtering Collides With Operations
Contoso Health (contoso.example) enabled a new cloud email filtering policy with aggressive impersonation protection, DMARC quarantine for all unauthenticated mail, and a block list of 300 lookalike domains. Within 48 hours, the help desk logs 600 tickets: appointment reminders from a scheduling SaaS are quarantined; a partner hospital's legitimate invoices are blocked because their domain is on the lookalike list; and 30 users received a BEC message from a Gmail account displaying the CFO's name, asking for gift-card purchases. The CISO demands the filter be tuned down to restore operations, while the SOC wants to keep the block list. The scheduling SaaS sends via its own domain but uses the hospital's From address without DKIM. Only 2 of 12 analysts can review quarantine. Mail volume is 90,000/day.
1. How would you triage the three failure modes without simply tuning the filter down?
Read the worked answer
Keep the block list and fix the specific failures, because a global tune-down would reopen the BEC gap. Triage by business impact.
- Partner hospital invoices: verify the partner's sending domain and infrastructure out-of-band, then remove the domain from the lookalike list if it was a false match. Add an exact-domain allow entry, not a wildcard, and confirm the partner's SPF/DKIM/DMARC posture.
- Scheduling SaaS: the vendor uses contoso's From without DKIM, so DMARC cannot align. Have the vendor add DKIM with d=contoso.example via a selector CNAME, or create a narrowly scoped connector/transport rule based on its sending IPs and sender address. Adding its IPs to SPF alone will not fix DKIM alignment.
- Gift-card BEC: DMARC will pass at gmail.com, so the message is authenticated but impersonates the CFO by display name. Keep impersonation protection and add display-name similarity rules, external-sender banners, and mailbox intelligence.
For 600 tickets with two reviewers, enable end-user quarantine notifications and auto-release for verified senders so analysts focus on high-risk messages.
2. Why can't DMARC stop the Gmail CFO impersonation, and what controls would you add?
Read the worked answer
The message is sent from a Gmail account, so SPF, DKIM, and DMARC authenticate gmail.com, not contoso.example. Contoso's DMARC policy has no authority over gmail.com, and the attacker did not spoof the contoso domain; the deception is in the display name. DMARC is therefore the wrong control for this attack.
Add impersonation protection that evaluates display name and sender reputation: a policy that quarantines external mail whose display name matches executives, with similarity thresholds; a transport rule that tags or quarantines external messages claiming to be the CFO; mailbox intelligence and first-contact safety; external-sender banners; and a prominent user-report button. Also add payment-change verification procedures outside email. Tune thresholds using the 30 messages and prior false positives, and test that ordinary Gmail senders are not broadly blocked.
3. Design a quarantine review workflow that can handle this volume without weakening security.
Read the worked answer
Use a risk-tiered queue instead of a single undifferentiated quarantine. High-risk messages (external sender, finance/payment language, executive name, new domain) go to a senior analyst queue; low-risk bulk notifications go to end-user quarantine with self-service release for known senders. Enable quarantine notifications and auto-release for domains that passed verification.
Operationally, 600 tickets in 48 hours with two reviewers is unsustainable. Temporarily reassign two more analysts, create saved views by sender domain and rule hit, and publish an exception form that requires out-of-band verification. Do not disable impersonation protection to reduce ticket count; instead, reduce noise by fixing the SaaS DKIM alignment and removing the partner's false-positive domain entry.
Document every exception with owner and expiry, review the top rule hits weekly, and track false-positive rate as a metric. This preserves the SOC's block list while restoring business mail flow.