DNS filtering for MSPs and multi-site properties

DNS filtering for MSPs and multi-site estates checks domain requests against security policies in the cloud before devices connect. Managed centrally through Purple alongside SSIDs, captive portals, and analytics, it requires no hardware on site. Operating across integrations like Cisco Meraki and HPE Aruba, Purple protects network estates spanning over 80,000+ live venues without agents.

What is DNS filtering for MSPs and multi-site estates?

Every connection a device makes starts with a DNS (Domain Name System) lookup. The device asks a resolver to turn a name like example.com into an IP address. DNS filtering, also called protective DNS, checks that name against a policy before answering. If the domain is malicious or off-policy, the resolver withholds the real address. The device never opens a connection, so nothing downloads and no page loads.

For a single venue, that is a useful control. For a managed service provider (MSP) or a multi-site IT team, the requirement changes shape. You filter dozens or hundreds of networks, owned by different clients, with different rules, on different hardware. That brings three requirements a single-site filter rarely meets:

• Per-tenant policy. A tenant is one client or business unit with its own rules. A family hotel group, a bar chain and a doctor's office should never share a policy.
• Central management. You need to see and change every tenant's policy from one place, without logging into each site.
• No per-site hardware. Shipping, racking and patching an appliance at every location does not scale across a fleet.

Shield is Purple's protective-DNS add-on, alongside SecurePass and Verify. Filtering runs in the cloud and ties to the SSIDs (network names), captive portals and analytics you already manage for each client. A captive portal is the login page a visitor sees before getting online.

How MSP filtering differs from a single-site deployment

A single-site filter has one policy, one admin and one network. An MSP estate has a hierarchy. You set rules for the estate, override them per client, then vary them per network within a site. A hotel's guest network needs different rules from the staff network behind reception.

Standalone DNS filters typically handle this with a sub-organization per tenant, configured apart from the WiFi itself. You end up running two stacks for every client: one for the network and portal, one for the resolver. Shield removes the second stack, because the filtering policy follows the networks you already defined in Purple.

Why does DNS filtering matter across a fleet of client sites?

Three pressures push filtering up an MSP's agenda: duty of care, threat exposure and constrained bandwidth.

Duty of care on shared networks

Public and guest WiFi carries real obligations. In England, schools and colleges follow the Department for Education's filtering and monitoring standards, referenced in Keeping children safe in education. In the US, the Children's Internet Protection Act (CIPA) requires schools and libraries receiving E-rate funding to filter. Hotels, cafes and leisure centers that welcome families face reputational risk if a child reaches adult content. The UK's Friendly WiFi scheme exists for exactly that reason.

When you run WiFi for 40 clients, you carry a share of each obligation. One unfiltered site is a client conversation you do not want.

Threats that reach unmanaged devices

You cannot install an agent on a visitor's phone, and you cannot patch it. Phishing links, malware downloads and command-and-control callbacks all begin with a DNS lookup. That makes the lookup the one point you control for every device on the network.

Shield flags threats at the DNS lookup stage, stopping malicious requests before connections complete. Across a fleet, a threat block lands at every client site at the same moment. For a wider view of the market, see Phishing Protection Software: 10 Options for Shared WiFi.

Bandwidth on constrained sites

Many estates run guest WiFi on modest backhaul: a 4G router at a forecourt, a shared line in a bar, a busy circuit at a station. Ad traffic and unwanted web content compete with everything else. Filtering ads and malicious domains at the DNS layer reduces network data consumption and improves loading speeds. On a congested site, that headroom goes back to the traffic guests came for.

What a firewall misses

A firewall still matters, but it works at a different point. It inspects connections after DNS has already answered. That leaves four gaps on a multi-site guest estate:

1. Encryption hides the destination. TLS 1.3 (RFC 8446) encrypts the server certificate. Encrypted Client Hello (ECH), an IETF extension to TLS, can hide the server name too. Without decryption, a firewall sees an IP address and little else, and you cannot install a decryption certificate on a visitor's device.
2. Shared IP addresses blur rules. Content delivery networks host many domains on the same addresses. Block the IP and you break legitimate sites; allow it and the bad domain gets through.
3. Per-site rule sets drift. A fleet built over years mixes firewall vendors and firmware versions. Keeping 60 rule sets aligned is a full-time job, and one forgotten site is the gap.
4. The block comes late. By the time a firewall acts, the device has resolved the name and attempted a connection. DNS filtering stops the request before any connection exists.

DNS filtering closes these gaps without decryption, agents or per-site rules. It does not replace the firewall's job of segmenting networks and controlling ports.

How does DNS filtering work across many tenants?

What happens during each lookup

1. A guest joins the client's WiFi, often through a captive portal.
2. The device requests a domain, for example from a link in a phishing email.
3. Shield checks the domain against the policy assigned to that network.
4. If the domain is allowed, the device receives the address and connects as normal.
5. If it is blocked, the lookup does not return the real address, so no connection opens.

How to structure per-tenant policy

Per-tenant content filtering works best as a small set of standard policies, not a customized rule set per site. This pattern holds up across hospitality, retail and the public sector:

• Security baseline. Malware, phishing and other threat categories blocked on every network, for every tenant. Nobody opts out.
• Family guest. The baseline plus adult and age-inappropriate content. Suits family hotels, libraries, community centers, schools and healthcare waiting areas.
• Adult guest. The baseline with lighter content rules. Suits bars, late-night venues and business hotels.
• Staff. The baseline plus rules reflecting each client's acceptable use policy.

Assign a policy per network, then add client exceptions only where a business needs them. A hotel's marketing team may need social platforms that a school would block. Four policies and a short exception list are far easier to audit than 60 hand-built rule sets.

Because Shield attaches policy to the networks you run in Purple, a site's guest and staff SSIDs can carry different policies. Staff networks using IEEE 802.1X, the standard for port-based network access control, keep their identity controls. Shield adds the DNS layer on top.

Managing a fleet from one dashboard

Central DNS policy management pays off only if it matches how you already work. Shield sits in the same Purple platform that runs each client's SSIDs, captive portals and analytics. You do not switch consoles to change a filter, and you do not maintain a second site inventory.

That has practical consequences for an MSP:

• Onboarding. A new client site in Purple needs no separate resolver account.
• Change control. Change a policy once and it applies to every network assigned to it.
• Reporting. Filtering activity sits beside the connection analytics you already share, so one quarterly review covers WiFi and security.

Why there is nothing to ship

Shield filters in the cloud, so there is no appliance to buy, configure, ship or replace at each location. Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. A client property portfolio that mixes vendors after acquisitions still runs one set of policies. Setup varies by vendor, so follow Purple's support documentation for your hardware.

Purple already runs across 80,000+ live venues and recorded 440 million logins in 2024 (Purple data).

What does DNS filtering look like on a real estate portfolio?

The three scenarios below are composites built from common real estate shapes. Site counts and hardware are typical; the outcomes are the operational arithmetic of each change.

Scenario 1: an MSP with 14 hospitality clients

Situation. An MSP runs guest and staff WiFi for 14 hospitality clients across 60 sites. The mix includes independent hotels, a 20-site bar group and an RV resort. WiFi and captive portals already run on Purple. Filtering ran on a separate DNS service, with one account and site list per client.

What was done. The MSP moved filtering into Shield and replaced 14 custom rule sets with the four standard policies. Family hotels and the RV resort took family guest; the bar group took adult guest. Two clients kept short exception lists.

Outcome. Zero hardware shipped and zero site visits across 60 sites. The MSP retired 14 separate filtering accounts and now manages every client from the Purple dashboard it already used. A rule change means editing one of four policies, not up to 60 site entries.

Scenario 2: a county government's libraries and community centers

Situation. A county government offers public WiFi in 22 libraries and five community centers. Children use the library networks after school. Two procurement rounds left HPE Aruba in the libraries and Ubiquiti UniFi in the community centers. The IT team is three people.

What was done. The county applied family guest to every public SSID and the staff policy to staff networks. Staff authentication stays on 802.1X with WPA3-Enterprise, the current enterprise WiFi encryption standard. Visitors still join through the county's captive portal.

Outcome. All 27 sites run one public policy across two hardware vendors, with no appliance anywhere. One edit reaches all 27 sites. The county shows auditors one policy and one log source, not 27 local configurations.

Scenario 3: a 120-store retailer on limited backhaul

Situation. A retailer runs guest WiFi for shoppers in 120 stores, a third of them on 4G backhaul. Shopper browsing competes with store systems for bandwidth. The cardholder data environment is already segmented from guest traffic to keep it out of PCI DSS scope.

What was done. The retailer enabled Shield's threat protection and ad blocking on the guest SSID only. It started with a 10-store pilot on its busiest 4G sites. Staff and store-system networks stayed on their own segments.

Outcome. The pilot measured its own before-and-after usage over four weeks, demonstrating reduced overall data consumption across constrained connections. The retailer then extended the policy to all 120 stores in one change, without a store visit.

Where does DNS filtering sit alongside what you already run?

Protective DNS is one layer. It works best next to controls you likely already own.

• Segmentation. VLANs (virtual LANs, which split one physical network into isolated logical networks) keep guest traffic away from staff and payment systems. See How to Set Up Network Segmentation for Guests and Staff.
• Authentication. 802.1X with RADIUS, the protocol that checks credentials against a central server, decides who joins a staff network. So does SecurePass with Microsoft Entra ID, Okta or Google Workspace. Shield decides where devices can go once connected.
• Firewalls. Your firewall still controls ports, protocols and traffic between segments. Shield stops known malicious destinations at the lookup.
• Privacy law. DNS logs can contain IP addresses and device identifiers, which CCPA/CPRA treats as personal data. Purple is CCPA/CPRA compliant and ISO 27001 certified.

How Shield compares with DNSFilter and Cisco Umbrella

DNSFilter and WebTitan target MSPs heavily, and Cisco Umbrella is the default in many Cisco estates. All filter at the DNS layer in the cloud. The differences lie in who manages what, and where.

Criterion	Purple Shield	DNSFilter	Cisco Umbrella
Where filtering happens	DNS lookup, in Purple's cloud	DNS lookup, in DNSFilter's cloud	DNS lookup, in Cisco's cloud
Per-site hardware	None	None for network filtering	None for DNS-layer protection
Tenant management	Inside the Purple dashboard that runs client WiFi	Separate MSP console with sub-organizations	Separate multi-org or MSP console
Tied to SSIDs, captive portals and WiFi analytics	Yes, native to the WiFi platform	No, configured as a separate stack	Integrates with Cisco Meraki, managed in its own console
Off-site roaming devices	Built for devices on the WiFi you run	Roaming client agent	Cisco Secure Client roaming module
Hardware coverage	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, Fortinet	Any network that can forward DNS to its resolvers	Any network that can forward DNS to its resolvers, deepest with Cisco
Best suited to	MSPs whose clients' WiFi runs on Purple	MSPs protecting managed endpoints on and off site	Estates standardized on Cisco security

The alternatives are strong where Shield does not compete. DNSFilter and Cisco Umbrella both offer roaming agents for managed laptops off site. Umbrella also sits inside Cisco's wider security portfolio. WebTitan, from TitanHQ, offers a multi-tenant cloud filter for MSPs too. If your contracts cover corporate endpoints wherever they travel, one of those may suit.

Shield's case is narrower and, for WiFi-led MSPs, stronger. If you run each client's SSIDs, captive portals and analytics in Purple, a separate resolver stack per tenant is overhead. For detail, read Shield vs DNSFilter: a protective DNS comparison for WiFi operators and Shield vs Cisco Umbrella: choosing protective DNS for guest WiFi.

What are the limits of DNS filtering you should know about?

DNS filtering acts at one point in a connection, and that sets its limits.

• Encrypted DNS can bypass it. DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858) let a device choose its own resolver. Network controls can reduce this on unmanaged devices but cannot eliminate it. See DNS over HTTPS explained: privacy vs public WiFi filtering.
• VPNs tunnel past it. A guest on a personal VPN resolves names inside the tunnel. You can block known VPN domains, not every one.
• Direct IP connections skip DNS. Malware calling a hard-coded IP address never makes a lookup. Your firewall covers that case.
• It sees domains, not content. DNS filtering allows or blocks a whole domain, not individual pages or files.
• Categories need review. Any category list will sometimes over-block or under-block. Give each client a named contact and a route to request changes.
• Logs need governance. Agree retention and access per client before rollout, and record it in your data processing agreement.

What should you do next?

1. Map your tenants. List every client, site and network, with vertical and regulatory duties such as schools, libraries, healthcare and licensed venues.
2. Draft standard policies. Start with the four above and keep the security baseline mandatory.
3. Pilot on representative sites. Choose one site per vertical, including one on constrained backhaul, and measure data use before and after.
4. Roll out by policy, not by site. Assign policies to networks for each client, then review exceptions after 30 days.
5. Report back. Add filtering activity to the WiFi reviews you already deliver.

If your clients' WiFi does not yet run on Purple, start with Guest WiFi, then add Shield. For more on securing networks across estates, browse All guides.

Frequently asked questions

Do I need to install hardware at each client site to use DNS filtering?

No. Shield filters at the DNS layer in the cloud, so there is no appliance to buy, configure or ship to any location. Purple runs as a cloud overlay on access points your clients already own, including Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Setup varies by vendor, so follow Purple's support documentation for each hardware type in your estate.

Can I set different filtering policies for each client and each network?

Yes. Shield ties filtering policy to the networks you already run in Purple, so each client, and each SSID within a site, can carry its own policy. A hotel's guest network can block adult content while its staff network applies the client's acceptable use rules. A small set of standard policies, plus short exception lists, is easier to audit than custom rules per site.

Can I manage content filtering for many sites from one dashboard?

Yes. Shield is managed in the same Purple platform that runs your clients' SSIDs, captive portals and analytics, so you change filtering without switching consoles. A policy change applies to every network assigned to that policy, across every site. Filtering activity sits alongside your existing WiFi reporting, so one client review covers connectivity and security together.

How does Shield compare with DNSFilter for an MSP?

Shield suits MSPs whose clients' WiFi already runs on Purple, while DNSFilter suits MSPs protecting managed laptops on and off site. Both filter at the DNS layer in the cloud with no per-site hardware. DNSFilter runs as a separate multi-tenant console with a roaming agent. Shield runs inside the WiFi platform, tied to the same SSIDs, captive portals and analytics you already manage.

Can guests bypass DNS filtering with DNS over HTTPS or a VPN?

Yes, a determined guest can. DNS over HTTPS, DNS over TLS and personal VPNs send lookups outside your resolver. Network controls can reduce this, for example by blocking known VPN and public DoH endpoints, but no DNS filter fully controls an unmanaged device. Treat DNS filtering as the default protection for every device using the network's DNS, alongside segmentation and your firewall.

Does DNS filtering help schools and libraries meet filtering requirements?

It covers the filtering element, but filtering alone does not meet the full requirement. In the US, CIPA requires E-Rate funded schools and libraries to use technology protection measures within an internet safety policy. Pair consistent filtering across sites with your monitoring and student safety processes.

How are DNS query logs handled under CCPA/CPRA?

Purple is CCPA/CPRA compliant and holds ISO 27001 certification. DNS logs can include IP addresses and device identifiers, which privacy laws treat as personal data. Agree retention, access and purpose with each client before rollout, and record those terms in your data processing agreement. As the MSP, you will often act as a processor for your clients, so document who controls each estate's logs.

How is Shield priced for a multi-site estate?

Shield is a security add-on to the Purple platform, alongside SecurePass and Verify, so you add it to sites already running on Purple. There is no per-site hardware, so there are no appliance, shipping or replacement costs to model. Ask Purple for pricing based on your number of clients and sites, and include any sites you plan to onboard this year.