July 6, 2026

DNS filtering for MSPs: tenant isolation without policy sprawl

Managed service providers are asked to enforce DNS filtering across dozens of customer environments. The operational mistake is to manage all customers from a single shared console, with per-endpoint policy edits. The compliance mistake is not being able to prove which policies applied to which tenant during an incident or audit.

The sprawl trap: one console, many ad-hoc rules

Many MSP deployments start with one centralized filtering console managing all customer endpoints. When Customer A requests blocking for gambling, you add an exception rule in the console. When Customer B later says "we allow gambling but block video streaming," you add another rule — and now your policy set is context-dependent and unmaintainable. Auditing which rules applied to which customer becomes archaeology: you must trace endpoint IDs back to customers, then match endpoint IDs to rules in a single overloaded policy tree.

Worse, when an endpoint changes hands (employee moved between clients, or a managed device is reassigned), your console doesn't automatically know. You end up manually editing endpoint policies, creating audit gaps and audit-trail inconsistencies.

Tenant isolation: policy per customer

The architectural solution is per-tenant DNS filtering: each customer gets their own policy environment with their own enrollment keys. When Customer A's endpoint enrolls, it uses Customer A's key and inherits Customer A's policies (block gambling, allow video). Customer B's endpoint uses Customer B's key and inherits Customer B's policies. No cross-tenant pollution, no manual per-endpoint edits.

Per-tenant policies also map cleanly to customer contracts: your SLA says "we enforce your DNS policy across your endpoints." When the customer's auditor asks "what policies were enforced on my March 15 incident?" you pull the tenant's policy history and export audit events (domain, category, timestamp) scoped to that tenant alone. You don't have to argue that your shared console wasn't also enforcing rules for other customers.

Custom categories and contractual controls

Some customers require custom blocking beyond standard categories: a contractual exclusion list, a terminated vendor's portal, a domain their own compliance team flagged. With per-tenant policies, you define a named custom category — "Contractual exclusions", say — that applies only to that tenant's endpoints. The inverse case, a business app a public list incorrectly flagged, goes on that tenant's allowlist, which is equally tenant-scoped. When you audit the enforcement later, the category or allowlist entry is named and scoped; it doesn't pollute other tenants' policy audits.

Custom categories also reduce support friction: instead of granting the customer access to your shared console (a security risk and a support burden), you document the custom category as part of their service and update it yourself when they request additions. The customer sees their policy reflected in their own audit trail, endpoint by endpoint.

Clean offboarding

When a customer's contract ends, you deactivate their tenant. All endpoints with their enrollment key stop receiving policy updates and can be decommissioned or reassigned. You don't have to manually delete per-endpoint policies from a shared console or worry that an orphaned policy set is still blocking or allowing unintended traffic. Tenant deactivation is one operation: no sprawl, no manual cleanup.

Audit readiness

Tenant isolation also satisfies auditor expectations cleanly. When your customer's ISO 27001 auditor asks "can you prove this policy was enforced on our endpoints for the past six months?" you export the tenant's policy history and audit events — domain blocks, timestamps, categories — without noise from other customers. That evidence is tenant-native and unambiguous.

ClearScreen's model is per-tenant by construction: each tenant carries its own policies, enrollment keys, and audit trail, and Business-plan tenants add custom categories for the contractual cases. See the feature overview for the isolation model, and start with our DNS policy readiness checklist to map your current MSP architecture against these isolation and audit requirements.