What is a one sentence summary of your feature request?
Flexibility in email domain blocks
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
As an engineer, I need to be able to sensitive data to certain email domains while still allowing non sensitive data to pass to these domains so that we can accommodate business use cases while still protecting critical assets.
I would like the ability to block both the content of an email message as well as attachments strategically through CAP.
How do you currently solve the challenges you have by not having this feature?
We are not able to address this use case in Netwrix EPP, limiting our defense in depth strategy. Instead, we are relying solely on our email server to block the traffic.
Thank you for the detailed feature request. After reviewing it with our engineering team, we’re glad to confirm that this use case is already supported in Netwrix EPP through the Content Aware Protection (CAP) policy engine.
Here’s how to achieve the behavior you described:
Important: How whitelisting works in CAP
When a destination domain is added to the whitelist of a policy, emails sent to that domain will pass through even if they contain content that the policy would normally block. The whitelist effectively exempts that domain from the policy’s enforcement — the content is still scanned and reported, but the action is overridden to allow.
This means whitelisting should only be applied to policies where you intentionally want to permit traffic to that domain regardless of content matches.
How to configure your use case: Per-policy domain whitelisting
EPP’s CAP evaluates emails against multiple policies independently, and whitelisting is scoped per policy — a domain whitelisted in one policy is not exempt from another.
You can leverage this to build the following setup:
Create a policy for sensitive data (e.g. PII, financial records, confidential file types)
Define your content and file type rules as needed
Do not add the partner/vendor domain to the whitelist in this policy
Result: any email to that domain containing sensitive content will be blocked
If you have a policy for non-sensitive content rules
Add the partner/vendor domain to the whitelist in this policy
Result: emails matching this policy’s rules will be allowed through to that domain
The combination gives you exactly what you need: routine communication passes freely, while sensitive data is blocked at the endpoint — without relying on your email server.
Summary table:
Scenario
Policy with sensitive rules
Policy with non-sensitive rules
Outcome
Email to partner domain, no sensitive content
No match → passes
Whitelisted → passes (even if content matched)
Allowed
Email to partner domain, sensitive content
Not whitelisted → blocked
-–
Blocked
If you need help designing the exact policy structure for your environment, our support team can walk you through it.
This looks like instructions for allow listing specific domains. Does this also work for strategically deny listing specific domains? For instance, I want to block ONLY sensitivite data to ONLY personal domains.
Today, our rule is built with regex patterns that target sensitive data and a list of specific personal domains that we want to block messages to. There are non personal domains that this traffic is expected to flow freely to…vendor partners, external collaboration contracts, agents…but we dont want messages to go to an individuals private email address. Does this make sense?
Thank you so much for the additional info you provided here.
Unfortunately, this type of granularity is not something we cover at the moment, but I am pleased to announce that a revamp of our Denylist/Allowlist is already on our mid-term roadmap. This revamp will cover the use case you are currently facing.
As soon as we will have more info regarding the timeline, we will let you know.
Thanks for the detailed explanation above — I have a use case that seems to match the basic whitelisting principle you described (not the two-policy scenario for Bree’s case), but I’m seeing different behavior in testing and wanted to check if this is expected.
Our use case:
We want to allow a specific sensitive content pattern (files prefixed D2_) to be sent by email only to one specific domain (e.g. mydomain.com), and blocked to every other domain — using a single CAP policy containing both the Denylist (File Name D2_*) and the Allowlist (E-mail Domain containing mydomain.com).
The rule we built:
Single active CAP policy, Policy Action: Block & Report
Exit Point: E-mail → Outlook (Attachments) only
Denylist: File Name D2_*
Allowlist: E-mail Domain list containing mydomain.com
Scoped entities to one test computer/user, all other CAP policies disabled to avoid priority conflicts
What we observed on the endpoint:
Sending a D2_test.pdf file as an Outlook attachment is blocked even when the recipient is on the allowlisted domain (mydomain.com) — regardless of whether the recipient is entered before or after the attachment. Tested on both the classic desktop Outlook (COM add-in “EPP Mail Addin” confirmed present and active in COM Add-ins) and the new Outlook — same result on both.
This seems to contradict the principle you described: “when a destination domain is added to the whitelist of a policy, emails sent to that domain will pass through even if they contain content that the policy would normally block.”
Could you confirm:
Is this whitelisting behavior expected to work on the Outlook (Attachments) exit point specifically, for both classic and new Outlook?
If yes, is there a configuration step we might be missing, given the setup above closely follows your description?
If this exit point isn’t currently covered, is it part of the Denylist/Allowlist revamp you mentioned is on the mid-term roadmap?
Happy to share screenshots of the policy config and the block messages if useful.
Allowed
Blocked