What is the difference between a Secure Web Gateway and Protective DNS?
A secure web gateway and protective dns can both stop users from reaching dangerous places online, but they work at different points in the connection.
Protective DNS makes the earlier decision. When your device asks, "Where is this domain?", it can block the DNS lookup before a connection is made. A Secure Web Gateway works deeper in the session. It can inspect the web request, URL, application, and, depending on the product and configuration, files or data moving through the connection.
So the simplest distinction is this: Protective DNS decides whether a destination should be reachable. An SWG decides whether the web activity going to or coming from that destination should be allowed.
What a Secure Web Gateway Does and What Traffic It Is Built to Control
A Secure Web Gateway is built to control Internet and web activity between your users and external services.
Instead of letting a browser or application connect with no policy checkpoint, you route relevant traffic through the gateway. The SWG evaluates the request before allowing it through.
A typical Secure Web Gateway can apply:
- URL filtering
- Anti-malware controls
- Application control
- Content filtering
- Data loss prevention for web traffic
A Quick Capability Comparison
Both might stop a phishing site. Protective DNS can stop the domain from resolving. An SWG can stop the web request. To your employee, the result looks identical: the page does not load.
Why Domain-Level Context Is Not Enough
The difference appears when the domain alone is not enough information. A malicious file can sit on a legitimate storage service. DNS sees the legitimate domain. An SWG can potentially inspect the specific request or downloaded object. On the other hand, if malware quietly resolves a command-and-control domain, Protective DNS can stop the lookup even when the later traffic is not normal browser traffic.
The important word here is context. Depending on deployment, a gateway can consider:
- The full URL rather than only the domain
- The user or device making the request
- The web application in use
- The transferred file
- The content category
- The company's policy for that activity
Suppose your company uses a popular file-sharing platform. Blocking the whole domain makes no sense because people need it for work. The problem might be one malicious executable hosted there.
Protective DNS cannot normally distinguish that bad file from a safe one because both use the same approved domain. An SWG has a chance to make that distinction because it works on the web traffic rather than only the DNS lookup.
The same applies to data leaving your environment. An employee may be allowed to use a cloud application but attempt to upload a file containing customer records. DNS sees an approved domain. An SWG with suitable DLP capabilities may be able to inspect the transaction and enforce policy against that upload.
HTTPS Inspection Adds Depth and Tradeoffs
HTTPS inspection gives the SWG more context, but it also introduces:
- Certificate-management work
- Privacy considerations
- Compatibility issues
- Bypass rules for traffic that should not be decrypted
In other words, the SWG gets more visibility because you deliberately put it deeper into the traffic path.
Modern cloud web security platforms often combine SWG and DNS controls with other security services. The product boundary can look fuzzy, but the distinction remains: one control acts on DNS activity while another examines web traffic.
What Protective DNS Does and Where It Operates in the Stack
Protective DNS operates earlier.
Before your browser connects to example.com, it normally asks a DNS resolver for the address associated with that name. Protective DNS turns that resolution step into a security checkpoint.
The DNS Lookup Becomes the Checkpoint
Instead of automatically returning an answer, the resolver can evaluate the requested domain against:
- Threat intelligence
- Reputation data
- Policy rules
- Behavioral and newly observed infrastructure signals
Vercara's UltraDDR material describes Protective DNS as making security decisions during recursive DNS resolution and using DNS-layer intelligence to identify malicious or suspicious destinations.
This is the core idea behind dns filtering.
At the simple level, you allow or block domains and categories. More advanced services can use threat intelligence and behavioral signals to identify suspicious or newly observed infrastructure.
Coverage Extends Beyond the Browser
DNS coverage extends across many systems:
- Laptops and phones
- Servers and applications
- IoT devices
- Malware attempting to locate attacker infrastructure
Suppose malware is already running on an endpoint and tries to resolve its command-and-control server. The DNS request itself creates an opportunity to stop communication. Protective DNS can also help identify or block suspicious DNS activity associated with malicious infrastructure before the endpoint successfully establishes its later connection.
The later connection does not have to be a webpage. An SWG is strongest when activity passes through its web-control path, while Protective DNS can act whenever a covered device relies on your resolver. The tradeoff is depth.
Where Protective DNS Runs Out of Context
Protective DNS generally does not know that someone is downloading /files/invoice.exe from a legitimate domain. It does not inspect a PDF, see a form submission inside HTTPS, or decide that one upload to an approved SaaS application contains sensitive data.
It sees the DNS activity, decides what to do with the lookup, and its main job for that request is done.
Where the Two Overlap and Where They Protect Against Completely Different Threats
The overlap is mostly around malicious destinations and Internet-use policy.
Where Both Controls Can Stop the Same Threat
Take an obvious phishing domain. Protective DNS can block its resolution. An SWG can identify the destination or URL as malicious and block the web request. Either way, your user does not reach the page.
Where Their Capabilities Split
Now change the scenario.
A legitimate site gets compromised and serves a malicious file from one URL. Blocking the whole domain could break a service your business depends on. DNS has little context beyond the destination name. A Secure Web Gateway can potentially inspect the specific request, response, or file.
If malware quietly tries to locate an attacker-controlled server instead, Protective DNS may block the lookup before the connection begins.
Both Controls Have Bypass Risks
Both controls lose visibility when traffic bypasses their enforcement path:
- Protective DNS loses coverage when devices use unauthorized resolvers, unmanaged encrypted DNS, or hard-coded IP addresses
- An SWG loses coverage when web traffic does not pass through its inspection path
This is why layered controls make sense. The same principle applies to CDN security solutions protecting Internet-facing delivery infrastructure. They solve a different part of the security problem, and the security risks for CDN operations are not removed because employees have secure browsing controls.
Each control needs a clear job.
How to Decide Which One Your Architecture Needs or Whether You Need Both
If your main goal is broad protection against malicious destinations, phishing infrastructure, malware callbacks, and unwanted domain categories, Protective DNS is usually the simpler place to start.
Protective DNS is usually easier to deploy broadly because it can cover:
- Managed laptops and remote users
- Servers and background applications
- Mobile devices
- IoT systems
- Workloads that make DNS requests but are awkward to place behind a web proxy
If your requirements go deeper into what users actually do online, you need an SWG.
A Secure Web Gateway becomes the stronger fit when you need to:
- Control specific URLs on otherwise approved domains
- Inspect downloads and web responses
- Identify and govern individual web applications
- Apply policies by user, device, or group
- Inspect HTTPS traffic when policy and privacy requirements allow it
- Prevent sensitive data from being uploaded through web applications
I would frame the decision like this:
- Use Protective DNS when the important question is, "Should this device be allowed to find and connect to this destination?"
- Use a Secure Web Gateway when the important question is, "Should this user be allowed to perform this particular web action?"
Layer Both Controls When the Risks Overlap
For plenty of organizations, the real answer is both.
That does not necessarily mean buying two separate products. Many modern platforms combine DNS filtering and SWG functions. What matters is that both control points exist and that you understand which one is protecting you in each situation.
The Layered Flow
A simple layered flow looks like this:
The two controls work in sequence:
- The user or device asks Protective DNS whether the destination is allowed
- If DNS resolves it, the connection moves toward the Secure Web Gateway
- The SWG evaluates the request, application, file, or data transfer
- Allowed traffic continues to the Internet
Evaluate Visibility, Not Product Labels
When evaluating a product, ignore the broad "web security" label for a moment and ask what it can actually see.
Ask what the product can actually see:
- Only domain lookups, or full URLs too?
- Can it inspect downloads?
- Does it decrypt and inspect HTTPS when required?
- Can it apply policies to individual applications?
- Does it perform DLP?
- Does DNS protection remain active away from the office?
- Can it cover servers and devices that are poor candidates for a web proxy?
Map each device group to the enforcement path it will really use:
- Managed laptops may use both Protective DNS and the SWG agent
- Remote users need the controls to remain active outside the office network
- Servers and IoT devices may fit DNS enforcement better than proxy-based inspection
- Privacy-sensitive or certificate-pinned applications may need carefully documented TLS-inspection exceptions
- Logs from both layers should reach the same investigation workflow so analysts can connect a DNS block to later web activity
Those questions expose the difference quickly.
Protective DNS gives you broad, early, relatively lightweight control. A Secure Web Gateway gives you deeper control over the web session. If you need protection at both levels, using both is not unnecessary duplication. You are stopping bad destinations at the DNS layer and applying more precise web traffic filtering when actual web activity begins.