Flexibility in email domain blocks

Products Endpoint Protector Ideas
,
1

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.

2

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:

  1. 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

  2. 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) :white_check_mark: Allowed
Email to partner domain, sensitive content Not whitelisted → blocked -– :cross_mark: Blocked

If you need help designing the exact policy structure for your environment, our support team can walk you through it.

Best regards,

Cristi