Beyond Email Tracking in Dynamics 365: A Client Story on Securing Internal & Board Communications

Introduction

Dynamics 365 doesn’t offer native recipient-based email blocking. We built a configurable plugin that blocks emails based on flexible rules (competitors, compliance, internal-only, etc.) with server-side enforcement that can’t be bypassed. Used in production by financial services clients.

This is Part 2 of our blog series, following “Email Tracking Dilemma in Dynamics 365: When You Need to Block, Not Just Track”.While the scenarios above represent common industry challenges, we recently implemented this solution for a client who needed to combine several of these patterns.

The Client

A financial services organization needed to ensure their Dynamics 365 CRM tracked external customer and prospect communications but explicitly exclude internal staff communications and board member correspondence.

The Requirements

Block all emails sent exclusively to internal company domains
Block all emails involving board members (specific email addresses)
Continue tracking all customer-facing communications
Ensure compliance with corporate governance policies
Provide clear audit trail of what’s blocked

The Implementation

Using the Email Blocking Handler plugin, we configured: – “All Recipients” rules for internal domains (only blocks when all recipients are internal) – “Any Recipient” rules for board member email addresses – Custom blocking table managed by their compliance team.

The Results

Zero internal/board communications tracked in CRM
Customer communications tracked seamlessly
Compliance team has full visibility and control
No user training required – enforcement is automatic
Clean separation between operational and governance data

This real-world implementation validated the approach and demonstrated the flexibility of the two-strategy blocking model.

The Gap: What’s Missing from Dynamics 365

Microsoft Dynamics 365 offers powerful email capabilities out of the box:

Server-Side Synchronization
Email tracking and correlation
Email templates and automation
Activity timeline views

But when it comes to selective blocking, the options are severely limited:

No recipient-based filtering
No domain-level blocking rules
No conditional tracking logic
Only folder-level exclusions (very crude)

Common workarounds organizations attempt (and why they fail):

Workaround	Why It Fails
User Training	“Please don’t track competitor emails”
Client-Side JavaScript	Block tracking via custom scripts
Post-Creation Workflows	Delete emails after they’re created
Separate Email Accounts	Use different accounts for different purposes
Multiple CRM Instances	Separate environments for different needs

The reality is: You need server-side enforcement that can’t be bypassed, with flexible rules that work across all email creation scenarios.

Our Solution: The Email Blocking Handler Plugin

To address these gaps, we developed a configurable Dynamics 365 plugin that elegantly solves this problem. Our recent implementation for a financial services client validated the approach, and we’ve designed it to be reusable across diverse scenarios.

Here’s how it works:

The Architecture

The Email Blocking Handler is a server-side plugin that intercepts email creation at the platform level – before the email record is committed to the database. It evaluates recipients against configurable blocking rules and prevents creation if blocking conditions are met.

Key Design Principles:

Server-Side Enforcement – Runs in the Dynamics 365 platform pipeline, cannot be bypassed
Configuration-Driven – No code changes needed for different customers or rule updates
Flexible Rule Engine – Supports both “any recipient” and “all recipients” blocking strategies
Clear User Feedback – Provides meaningful error messages when emails are blocked
Performance-Optimized – Minimal overhead, cached queries, efficient evaluation

How It Works: Two Blocking Strategies

The plugin supports two distinct blocking strategies to handle different business requirements:

Strategy 1: “Any Recipient” Blocking

Use Case: Block emails if ANY single recipient matches a rule (e.g., competitors, banned domains)

Logic: Evaluates immediately – if any recipient matches, block the email

Example:

Rule: Block @competitor.com (Any Recipient)

Email To: john@client.com, sales@competitor.com
Result: ❌ BLOCKED - Contains competitor recipient

Email To: jane@client.com, mary@client.com
Result: ✅ ALLOWED - No competitor recipients

Perfect for: – Competitor blocking – Compliance restrictions – Spam/banned addresses – Privacy exclusions

Strategy 2: “All Recipients” Blocking

Use Case: Block emails ONLY when ALL recipients match a rule (e.g., internal-only communications)

Logic: Evaluates collectively – only blocks if every recipient is covered by at least one rule

Example:

Rule: Block @internal.com (All Recipients)

Email To: user1@internal.com, user2@internal.com
Result: ❌ BLOCKED - All recipients are internal

Email To: user@internal.com, client@external.com
Result: ✅ ALLOWED - Has external recipient

Perfect for: – Internal communication filtering – Department-specific restrictions – Test environment isolation – Multi-recipient validation.

The Configuration: No Code Changes Required

Here’s the beauty of our solution – it’s completely configurable via plugin registration settings. Each customer can customize table names, field names, and option set values without touching code.

Example Configuration:

{
  "prefix": "nw",
  "blockingTable": "blockemailtrackinglist",
  "fields": {
    "pattern": "pattern",
    "patternValue": "name",
    "matchingRule": "domainmatchrule"
  },
  "optionSets": {
    "patternEmail": 206300000,
    "patternDomain": 206300001,
    "matchingRuleAny": 206300000,
    "matchingRuleAll": 206300001
  }
}

Different customer? Different prefix? No problem:

{
  "prefix": "contoso",
  "blockingTable": "emailblockinglist",
  ...
}

This makes the solution truly reusable across multiple customer environments without recompilation.

Managing Blocking Rules: Simple & User-Friendly

Administrators manage blocking rules through a custom Dynamics 365 table – no technical knowledge required:

Field	Purpose	Example Values
Pattern Value	Email or domain to block	spam@example.com or @competitor.com
Pattern Type	Exact email or domain match	Email / Domain
Matching Rule	Blocking strategy	Any Recipient / All Recipients
Status	Enable or disable rule	Active / Inactive

Creating a new rule is as simple as:

Navigate to the blocking rules table
Click “New”
Enter the pattern (email or domain)
Select pattern type and matching rule
Save and activate

No development required. No deployment needed. Changes take effect immediately.

Recipient Resolution: Smart & Comprehensive

The plugin handles both resolved and unresolved recipients intelligently:

Resolved Recipients (linked to CRM entities):

Automatically queries Contact, Account, Lead, System User, and Queue records
Retrieves actual email addresses from the appropriate field
Groups queries by entity type for performance

Unresolved Recipients (plain email addresses):

Evaluates directly from the activity party’s “addressused” field
No additional queries needed

Evaluation Includes:

To recipients
From sender
CC recipients
BCC recipients

All recipients are evaluated – nothing slips through.

How This Solution Addresses Each Scenario

Let’s see how the Email Blocking Handler would address each of the use cases we outlined:

Consulting Firm – Competitive Intelligence

Rules Configuration: – Block @competitor1.com (Any Recipient) – Block @competitor2.com (Any Recipient) – Block @competitor3.com (Any Recipient)

Expected Impact: Sales team cannot accidentally track competitor communications. CRM data quality improves. Pipeline reports become accurate. Zero training required.

Healthcare Provider – HIPAA Compliance

Rules Configuration: – Block @clinical-system.health.org (Any Recipient) – Block phi-team@healthcare.com (Email, Any Recipient)

Expected Impact: Protected health information automatically prevented from entering CRM. Compliance team gains audit trail of blocked attempts. HIPAA violation risk eliminated

Manufacturing Company – Internal Communication

Rules Configuration: – Block @company-internal.com (All Recipients) – Block @hr.company.com (All Recipients)

Expected Impact: Internal-only emails no longer clutter CRM. External customer communications tracked perfectly. Storage costs reduced. User experience improved.

Rules Configuration: – Block specific individual emails as requested (Email, Any Recipient) – Maintain dynamic blocklist updated by compliance team

Expected Impact: “Right to be forgotten” requests honored automatically. No manual cleanup needed. Audit reports show compliance enforcement. Legal team satisfied.

Recruiting Firm – Data Quality

Rules Configuration: – Block @job-notifications.com (Domain, Any Recipient) – Block @newsletter-service.net (Domain, Any Recipient) – Block automated-noreply@jobboard.com (Email, Any Recipient)

Expected Impact: CRM data quality dramatically improved. Duplicate detection works properly. AI insights more accurate. User adoption increased.

The Technical Elegance: Why This Works

For the technical readers, here’s why this solution is architecturally sound:

1. Pipeline Stage: Pre-Validation

The plugin registers on the Pre-Operation stage of the email Create message. This means:

Executes before database transaction begins
Minimal rollback complexity
Immediate feedback to user
No orphaned records

2. Exception-Based Blocking

Rather than deleting records or setting flags, we throw an

InvalidPluginExecutionException:
throw new InvalidPluginExecutionException(
    "Email creation blocked: recipient 'blocked@example.com' matches blocking rule."
);

This provides: – Clear error message to user – Transaction rollback automatically – Proper error logging – No side effects.

3. Optimized Query Pattern

We group recipient queries by entity type to minimize database calls:

// Instead of 10 individual queries for 10 contacts
// We run 1 query with IN clause for all contact IDs
QueryExpression query = new QueryExpression("contact")
{
    ColumnSet = new ColumnSet("emailaddress1"),
    Criteria = new FilterExpression
    {
        Conditions = { new ConditionExpression("contactid", ConditionOperator.In, allContactIds) }
    }
};

4. Separation of Concerns

The codebase is cleanly organized:

EmailModels.cs – Configuration data structures
EmailPluginHelper.cs – Reusable business logic (recipient extraction, rule evaluation, validation)
EmailBlockingHandler.cs – Orchestration only (thin plugin class)

This makes it:

Easy to unit test
Simple to extend
Maintainable long-term
Reusable for other plugins

5. Configuration Validation

All configurations are validated at plugin initialization (not runtime):

public EmailBlockingHandler(string unsecureConfig, string secureConfig)
{
    // Validate configuration during plugin load
    // Fail fast if misconfigured
    EmailPluginHelper.ValidateConfiguration(_config);
}

This means configuration errors are caught immediately during plugin registration, not when users create emails.

Why Organizations Love This Solution

Here’s what makes this approach special:

Business Benefits

For Compliance Officers:

Automated enforcement of blocking policies
Audit trail of blocking rules and blocked attempts
Easy to demonstrate compliance to auditors
No reliance on user behavior

For Sales Leadership:

Clean CRM data for accurate reporting
No competitor data skewing metrics
Improved pipeline visibility
Better AI/insights accuracy

For IT/CRM Administrators:

No code changes per environment
Simple configuration via JSON
User-friendly rule management
Low maintenance overhead

For End Users:

Clear error messages when blocked
No training required
Works across all email creation methods
Consistent experience

Technical Benefits

For Developers: – Clean, documented, maintainable code – Separation of concerns – Unit testable components – Extensible architecture

For Solution Architects: – Server-side enforcement (secure) – Configuration-driven (flexible) – Performance-optimized – Works in sandbox mode (cloud-compatible)

For ISVs: – Multi-tenant ready – No customer-specific code branches – Easy to package as managed solution – AppSource ready

Beyond the Basics: Future Enhancements

While the current solution is production-ready and solves the core problem elegantly, here are potential enhancements that could address additional scenarios we see in the market:

1. Time-Based Rules

Use Case: Block certain communications only during specific periods

Block @contractor.com after project end date
Block @seasonal-vendor.com outside of season

2. User/Team-Based Rules

Use Case: Different blocking rules for different teams

Sales team: Block competitors
Support team: Allow all communications
Marketing team: Block unsubscribed addresses

3. Override Capability

Use Case: Authorized users can override blocks when needed

Manager approval required to track competitor email
Compliance officer can whitelist specific communications

4. Analytics Dashboard

Use Case: Visibility into blocking patterns

How many emails blocked this month?
Which rules are most frequently triggered?
Who is attempting to track blocked addresses?

5. Integration with Microsoft 365 DLP

Use Case: Sync blocking rules with organizational DLP policies

DLP policy blocks @competitor.com in Outlook
Dynamics 365 automatically blocks tracking
Unified policy management

6. Whitelist Mode

Use Case: Only allow specific domains (reverse blocking)

Only track emails to approved customer domains
Block everything else by default
High-security environments

Getting Started: Implementation Overview

Want to implement this in your organization? Here’s the high-level process:

Step 1: Create the Blocking Rules Table

Create a custom table in Dynamics 365 with: – Pattern Value field (text) – Pattern Type field (choice: Email/Domain) – Matching Rule field (choice: Any/All Recipients) – Status field (active/inactive)

Step 2: Register the Plugin

Upload the plugin assembly to Dynamics 365
Register a step on the Email entity, Create message
Configure the JSON in the unsecure configuration
Enable the step

Step 3: Create Blocking Rules

Navigate to your blocking rules table
Add rules for your use cases
Test in a non-production environment first

Step 4: Monitor & Refine

Review trace logs for blocked emails
Refine rules based on user feedback
Add new rules as needs evolve

Total implementation time: 6-8 hours for most organizations

The Bottom Line

Email tracking in Dynamics 365 is powerful, but tracking everything creates real problems:

Compliance risks
Data quality issues
Competitive intelligence concerns
Privacy violations
User experience degradation

The Email Blocking Handler solves this elegantly by:

Enforcing server-side blocking that can’t be bypassed
Providing flexible rule strategies for different scenarios
Requiring zero code changes per customer
Offering user-friendly administration
Delivering clear feedback to users
Maintaining performance and scalability

Whether you’re dealing with competitor communications, compliance requirements, internal email overload, privacy regulations, or data quality issues – this solution handles it gracefully.

Want to Learn More?

We believe email blocking is a capability every Dynamics 365 organization needs. If you’re facing similar challenges, we’d love to help:

Contact us to discuss your specific use case Request a demo to see the solution in action Get implementation assistance for your environment.

About the Solution

The Email Blocking Handler is a production-ready, configurable Dynamics 365 plugin developed by Netwoven. It’s designed to be deployed as a reusable solution across multiple customer environments without code modifications.

Technical Specifications: – Target: Dynamics 365 – Framework: .NET 4.6.2 – Deployment: Managed or Unmanaged Solution – Execution: Synchronous, Pre-Operation Stage – Isolation: Sandbox Mode (cloud-compatible)

Have questions or want to share your own use cases? Leave a comment below or reach out to our team. We’re always interested in hearing how organizations are solving email tracking challenges!