security operations

Filter Bypass

Updated October 16, 2026

Filter bypass occurs when a message reaches a user despite a security control that was expected to stop or isolate it. The cause may be attacker evasion, incomplete coverage, a policy exception, or a configuration error. “Delivered” describes an outcome; it does not explain why the control allowed it.

2 min. read

What do I need to know about Filter Bypass?

A malicious message can evade checks by abusing trusted infrastructure, changing its destination later, or presenting a deceptive request without a known malicious payload.
Broad allowlists and mail-flow exceptions can create avoidable gaps. Record why an exception exists, who owns it, and when it should expire.
Read the delivery verdict and applicable policy before assuming the detection engine failed.
Post-delivery review and account investigation matter because an initially allowed message may later be recognized as harmful.

An illustrative example

A phishing message arrives from a domain a team previously allowed for a campaign. An investigation finds that the exception was broader than intended. The corrective action is to narrow or remove that exception and search for other delivered messages—not simply add one new sender to a blocklist.

Practical checks

Record the message identifier, delivery time, recipient, verdict, and policy applied.
Review connector configuration, allowlists, transport rules, and any user-specific exceptions.
Contain the message, assess user interaction, report a false negative where supported, and test the corrected policy with safe samples.

Five FAQs about Filter Bypass

Does one missed message mean the filter is useless?

No. Evaluate the cause, impact, and repeatability. A policy exception calls for a different fix from a new attack technique or an integration that does not cover a mailbox.

Can a phishing email contain no malicious link?

Yes. A fraudulent request to change bank details or send confidential records can be harmful without a link or attachment. Workflow context matters alongside technical scanning.

Should we allowlist a whole domain to fix delivery problems?

Avoid treating that as the default remedy. Investigate the false positive and use the narrowest supported correction. Broad exceptions may allow unrelated malicious messages through.

Why can a link become dangerous after delivery?

A destination, redirect, or hosted file may change after the original inspection. Controls that reassess links and messages later can help, but their coverage and policy behavior need verification.

How should we measure improvement?

Track recurrence, time to investigate and contain, affected recipients, user interaction, and false positives. Counting blocked messages alone does not reveal whether the important gaps were closed.