I85PREP
⌘ K
CCNP Security study materials
CCNP Security study resources

Email Gateway False Positives, an Allow-List Bypass, and a Full Disk

CCNP Security · Put your knowledge to work in context.

All case studies

Email Gateway False Positives, an Allow-List Bypass, and a Full Disk

A company with 22,000 Exchange Online mailboxes routes inbound and outbound mail through a pair of ESAs in HA. Inbound volume is about 1.4 million messages per day, of which roughly 71% is rejected. Three problems surfaced in one week: a partner's invoice PDFs are quarantined as malware because their signing certificate chains to a private CA; a phishing campaign from a lookalike domain reached inboxes because an administrator had allow-listed the 'from' domain after an earlier complaint; and the ESA quarantine disk is at 78% while Legal requires 90-day retention of all quarantined messages. Outbound DLP for PII is mandated, and TLS is contractually required for 12 partner domains.

1. How would you resolve the false positives without re-creating the allow-list problem?

Read the worked answer

Principle: allow-listing by sender domain bypasses all checks, including anti-spoofing - that is exactly why the lookalike campaign succeeded. Fixes must be scoped to the specific check that is wrong, not to the sender.

For the partner PDFs (false positive on the private CA):

  • The real issue is that the ESA cannot validate the partner's signing chain. Rather than trusting the domain, import the partner's CA certificate into the ESA's trusted list (or add the signer to a content-filter exception), so signature validation is fixed rather than bypassed.
  • Add a content filter exception scoped to sender + recipient group + attachment type, applied above the malware rule, with a note and an expiry date.
  • Verify with message tracking on a retained sample and by having the partner send a test message.

For the allow-list:

  • Remove the domain-wide allow-list entry immediately.
  • Replace it with sender verification: require SPF pass plus DMARC alignment with a DMARC policy of quarantine/reject for the domain, and use per-sender skip rules only for a specific, named check.
  • Add lookalike detection (domain similarity / SBRS) and alerting on the lookalike pattern that got through.
  • Document that 'never bypass anti-spoofing' is the standing rule, and log every skip rule for review.

2. Reconcile the 90-day retention requirement with a disk at 78% capacity.

Read the worked answer

Analysis first: the constraint is not retention - it is the volume of what is being retained. With 1.4M messages/day inbound and 71% rejected, the overwhelming majority of quarantine volume is spam, not evidence the Legal team needs to preserve for 90 days.

Options, in order of preference:

  1. Tier retention by quarantine type. Set spam/policy quarantine to 14-30 days, and keep virus/outbreak/DLP quarantine at 90 days. Legal almost never needs 90 days of spam; get this in writing from Legal.
  2. Stop quarantining bulk spam at all - delete at SMTP after the spam verdict, keeping only a hash/summary record. This is the single biggest disk win.
  3. Offload quarantine to external storage (centralized or cloud quarantine) for the categories that truly need 90 days, so the appliance holds only a rolling window.
  4. Add disk / expand only if 1-3 are rejected - it buys time, not a fix.

Also check: quarantine size limits per user, whether the ESA is quarantining messages that are later released repeatedly, and whether retention is being applied to already-expired messages. Confirm disk pressure (showstatus, disk usage per quarantine) after each change rather than assuming the numbers moved.

3. The 12 partner domains require TLS. How would you enforce it, and what would you need to verify first?

Read the worked answer

Do not enforce by assuming everyone supports it. Enforcing TLS on a destination the peer cannot negotiate silently queues or bounces legitimate business mail.

Verification first, per domain:

  • Check the ESA destination controls / TLS connectivity table for each of the 12 domains: is TLS 'required', 'opportunistic', or 'not available' as observed?
  • Confirm the peer's MX actually offers STARTTLS and with a valid certificate. A domain can support STARTTLS and still fail certificate verification - decide explicitly whether you require verified TLS (TLS support: required, certificate verification on) or merely encryption without verification.
  • Test with a real message and read message tracking for the TLS status detail.

Enforcement design:

  • Set the 12 domains to TLS: required in destination controls, verified, with a domain-level exception list for any that can only do opportunistic.
  • Add an outbound content filter that bounces or quarantines messages to those 12 domains when the TLS status is not 'TLS success', so policy is visible rather than silent.
  • Notify each partner's IT contact and give a defined window before enforcing, so mail does not disappear.
  • Monitor the TLS failure counter per domain - a sudden increase usually means a peer's certificate expired.