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.
Hi Bree,
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
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.
Best regards,
Cristi
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?
Hi Bree,
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.
Thank you again for the clarifications.
Regards,
Cristi