Setting up Sophos DNS Protection with Sophos Firewall

Sophos DNS Protection secures DNS queries via a cloud-based DNS service with policies and reporting in Sophos Central. The feature can block malicious domains, phishing, command-and-control targets, and unwanted categories before a client even connects to the actual website or infrastructure.

With Sophos Firewall, the cleanest standard setup is usually: clients use the firewall as a DNS resolver, the firewall forwards public DNS queries to DNS Protection, and internal domains are sent to internal DNS servers via DNS Request Routes. This keeps internal name resolution stable while public DNS queries are centrally controlled and logged.

DNS Protection does not replace Web Protection, Threat Feeds, or NDR. It is a separate protection point at the DNS level. Therefore, the function should be planned consciously and not just replace public DNS servers.

Video Guide

Avanet Assessment: Use DNS Protection Consciously

DNS Protection is technically interesting but not automatically the best choice in every environment. In many projects, we deliberately do not use DNS Protection as a standard but prefer fast, highly available DNS resolvers and additionally block known malicious targets via Sophos Firewall Threat Feeds or comparable threat intelligence sources on the firewall.

The reason is simple: DNS is a basic function. If DNS is slow, not redundant, or generates too many false positives, users quickly feel that the entire network is defective. DNS protection must therefore not only be secure but also stable, fast, understandable, and well manageable.

The decision depends on the goal:

• Fast and highly available DNS resolvers: Very good performance, robust name resolution, and low operational risk. However, there is no central DNS policy and no DNS reporting in Sophos Central.
• Threat Feeds on the Sophos Firewall: Known malicious targets can be blocked at the perimeter without rebuilding the DNS path. However, this is not the same as DNS category filtering; quality, tuning, and the false-positive process remain important.
• Sophos DNS Protection: DNS policies, categories, locations, logs, and Endpoint DNS Protection are managed in Sophos Central. However, this creates an additional dependency in the DNS path; rollout, certificates, exceptions, and monitoring must be well planned.

DNS Protection is particularly suitable when DNS logs in Sophos Central, location-based DNS policies, category filtering, or endpoint DNS protection for roaming clients are explicitly desired. If the primary goal is fast and highly available name resolution with additional blocking of known bad targets, good DNS resolvers plus threat feeds are often the more pragmatic solution.

When DNS Protection Makes Sense

DNS Protection is particularly strong when many clients access the internet through a central firewall or a local DNS resolver.

Typical use cases:

• Clients should not use arbitrary public DNS resolvers.
• Malware, phishing, and C2 domains should be blocked early.
• DNS queries should be visible in Sophos Central.
• Different locations should have their own DNS policies.
• Internal DNS names should continue to work via local DNS servers.
• Web Protection should be complemented by a pre-stage DNS control.

However, DNS Protection is not a substitute for content inspection. If an allowed domain later delivers harmful content or HTTPS traffic needs to be inspected more closely, Web Protection, TLS Inspection, IPS, endpoint protection, and logging remain relevant.

DNS Protection is not ideal if only a fast external DNS forwarder is sought or if a very stable DNS operation with separate threat feeds, Web Protection, endpoint protection, and clean monitoring already exists. In such cases, it should first be checked what additional value DNS Protection specifically brings and who manages the policy, exceptions, and false positives.

Architecture with Sophos Firewall

For Sophos Firewall, this setup is usually the clearest:

1. Sophos Central recognizes the location as a Location.
2. Sophos Central provides two DNS Protection IP addresses.
3. Sophos Firewall uses these IP addresses as DNS forwarders.
4. Internal domains are sent to internal DNS servers via DNS Request Routes.
5. DHCP distributes the firewall as a DNS resolver to clients.
6. Optionally, a NAT rule enforces that outgoing DNS traffic is redirected to the firewall.
7. DNS Protection logs and reports are evaluated in Sophos Central.

This setup ensures that clients do not need to be configured directly to the Sophos DNS service. The firewall remains the central resolver in the LAN and can better handle internal special cases.

It is important to distinguish between Traditional DNS and Secure DNS:

• Traditional DNS over IPv4: For firewall sites, routers, local DNS servers, or networks with a fixed public IP or DDNS FQDN. Sophos Central assigns DNS queries to the location via the public source IP or FQDN.
• Secure DNS: For Endpoint DNS Protection via Sophos Endpoint. Sophos Central creates a unique DNS-over-HTTPS path for the location.

For a Sophos Firewall as DNS forwarder, Traditional DNS over IPv4 is normally the correct path. Secure DNS belongs to the endpoint path and should not be confused with the firewall’s DNS forwarder settings.

Prerequisites

Before the rollout, these points should be clarified:

• Sophos Central access with permission for DNS Protection.
• Appropriate licence: Xstream Protection for standalone DNS protection or Workspace Protection for endpoint DNS protection.
• Public WAN IP or a stable FQDN/DDNS name for the location.
• Decision on whether the location is used for Traditional DNS or Secure DNS.
• Sophos Firewall is used as a DNS resolver for the affected networks or is intended to be.
• Internal domains, Active Directory zones, and reverse lookups are known.
• DHCP servers for client networks are identified.
• Exceptions for internal domains and critical services are planned.
• For Endpoint DNS Protection: supported endpoint platforms and rollout group are checked.
• Responsible parties for DNS policy, false positives, and logging are defined.

If the public IP address changes frequently, it should be clarified before the rollout whether a DDNS configuration is stable enough. Sophos DNS Protection can also identify locations via an FQDN, but an IP change can still lead to temporary interruptions.

For large environments, the location structure should be planned deliberately. Locations are operational and policy objects, not a replacement structure for every VLAN, floor, or small special group. The predefined Default location is reserved and cannot be used as a custom site location. Site, firewall, or tenant logic is often a better fit than very fine technical subdivisions.

Sophos DNS Protection allows a maximum of 50 locations. Several public IP addresses or FQDNs can be stored per Traditional DNS location; Sophos states a maximum of 100 entries for this. That sounds generous, but it is still an argument against an overly granular location structure. For policies, it is better to split by site, internet egress, and responsibility than by every individual VLAN.

1. Create Location in Sophos Central

In Sophos Central, the location is created first:

My Products > DNS Protection > Locations

Practical steps:

1. Select Add.
2. Enter location name and description.
3. Use Traditional DNS over IPv4 for firewall sites.
4. Enter the public WAN IP of the Sophos Firewall.
5. For multiple WAN interfaces, enter all relevant public IP addresses or a suitable range.
6. Use a DDNS FQDN if the design is based on dynamic IP.
7. Save the location.

The location is important because DNS Protection must assign incoming DNS queries to the correct customer account and policy. If the location is missing or the public IP does not match, Sophos Central does not see the location correctly.

Private IP addresses do not belong in a DNS Protection location. Sophos Central must see the public source IP used when DNS queries reach the service. If Central automatically detects a public IP, still check whether this address is really the planned egress path of the firewall. If the IP changes later, the location must be maintained; automatic detection does not replace operational monitoring.

2. Copy DNS Protection IP Addresses

The DNS Protection IP addresses can be found in Sophos Central under:

My Products > DNS Protection > Installers

Two IP addresses are provided there. These are used on the Sophos Firewall as the primary and secondary DNS servers. Do not enter other public DNS servers as fallback if the traffic is to run entirely through DNS Protection. Otherwise, DNS servers may be used bypassing DNS Protection depending on the resolver’s behaviour, and protection and visibility are lost.

With Secure DNS, the process is different: the endpoint component works with a DNS-over-HTTPS target, not with the classic DNS forwarder IP addresses of the firewall. If you expect IP addresses for the firewall here but created a Secure DNS location, the wrong location type was probably selected.

3. Configure Sophos Firewall DNS Forwarder

On the Sophos Firewall:

Network > DNS

Recommended steps:

1. Select Static DNS.
2. Set DNS 1 to the first DNS Protection IP address.
3. Set DNS 2 to the second DNS Protection IP address.
4. Leave DNS 3 blank unless there is a specific exception.
5. Under IPv6, also select Static DNS, do not enter IPv6 DNS servers, and select Choose IPv4 DNS server over IPv6 if the site should use the IPv4-based DNS Protection servers.
6. Save and apply the settings.

DNS Protection operates as an IPv4-based DNS service but can also resolve IPv6 addresses. Therefore, a separate IPv6 DNS server is not automatically needed.

If a firewall uses several WAN paths, the location must match the actual outgoing source IP. SD-WAN, failover, policy routing, or another NAT design can cause DNS queries to leave through a different public address than expected. This should be tested deliberately in the pilot.

4. Protect Internal Domains with DNS Request Routes

DNS Protection does not resolve internal domains. If Active Directory, internal applications, local zones, or reverse lookups are used in the network, these queries must go to internal DNS servers.

For this, use on the Sophos Firewall:

Network > DNS > DNS request route

Example:

• Host/domain name: company.local or corp.example.com
• Target servers: internal domain controllers or DNS servers

Without these routes, internal names would be sent to DNS Protection and not resolved correctly there. The exact procedure is described in Configure DNS Request Routes on Sophos Firewall.

For productive environments, internal domains should also be considered in DNS Protection as a domain list if the domain could be blocked by a category. Typical examples are internal sites or services that might otherwise fall under problematic categories like parked domains.

5. Use DHCP to Point Clients to the Firewall

Clients should use the Sophos Firewall as a DNS resolver, not directly arbitrary external resolvers.

If the Sophos Firewall provides DHCP:

Network > DHCP

Practical steps:

1. Edit the DHCP server of the affected interface.
2. Distribute the IP address of the firewall interface as the primary DNS server.
3. Make a deliberate decision on secondary DNS.
4. Renew DHCP lease or reconnect test client.
5. Check with a test client which DNS server is actually used.

Sophos often shows the firewall interface IP as the primary DNS server and a DNS Protection IP as secondary DNS in the official example configuration. That can work as a fallback, but it is not the best variant in every environment. If clients directly use the secondary DNS, they bypass the firewall as resolver. Internal DNS Request Routes, local special zones, and individual control points on the firewall then do not apply to these queries as expected.

If a Windows DNS server or another internal resolver is in use, this resolver can forward to DNS Protection instead of the clients. However, it must be clear where internal domains are resolved and which server forwards public queries.

6. Prevent Direct DNS Bypass

Many clients use the DNS server distributed via DHCP. However, some devices, browsers, IoT systems, or deliberately configured clients can use their own DNS servers.

A possible countermeasure is a NAT rule that redirects outgoing DNS traffic from internal networks to the firewall. Practically, this means: DNS traffic from the internal source networks is redirected via DNAT to the internal firewall address so that the query can be evaluated via DNS Protection.

Important:

• Only capture internal source networks.
• Do not use WAN interfaces as inbound interface.
• Set the rule position consciously very high.
• Document exceptions for internal DNS servers and special cases.
• Expect only classic DNS traffic on UDP/TCP 53; DoH and DoT must be handled separately via client, browser, MDM, or Web Policy controls.
• Then test whether internal DNS resolution, DNS Protection, and logs are still correct.

The NAT basics are explained in Understanding NAT on Sophos Firewall. DNS enforcement should not be activated blindly, as it can affect internal resolvers, VPN clients, DoH/DoT behaviour, or special devices.

Plan Rollout in Phases

DNS Protection should not be enforced for all networks at once. DNS is a basic function: if internal names, certificate checks, software updates, or SaaS services are no longer resolved cleanly, it quickly feels like a general internet outage.

A controlled rollout looks like this in practice:

1. Select a pilot network or small test group.
2. Document internal domains, reverse zones, and search domains.
3. Set up DNS Request Routes for internal zones.
4. Distribute the firewall as a DNS resolver via DHCP.
5. Set DNS Protection IP addresses on the firewall.
6. Install block page certificate on test clients.
7. Check logs in Sophos Central.
8. Only then include further networks, guest network, server networks, or VPN networks.

For server networks, one should be particularly cautious. Some systems use DNS for licence checks, updates, CRL/OCSP, backup, monitoring, or cluster communication. There, a test window with rollback is more important than in normal client networks.

Acceptance Test Before Broad Rollout

Before the productive rollout, it should be clear how to recognize a functioning DNS Protection implementation. The Sophos test link alone is not enough.

• Resolve public domain: Client queries the firewall or the intended internal resolver.
• Resolve internal AD domain: Query goes via DNS Request Route to internal DNS servers.
• Test reverse lookup: Internal PTR zones continue to work.
• Open blocked test domain: DNS Protection blocks and logs the hit.
• Check Sophos Central logs: Hits appear at the correct location.
• Test guest network: Guests use the planned DNS path and no internal DNS servers.
• Test VPN client: Split DNS, internal domains, and public domains behave as planned.
• Check browser DoH: Browser or operating system does not unexpectedly bypass control.

If any of these tests fail, the policy should not be opened immediately. First, it must be clear whether the problem lies with DHCP, DNS Request Routes, location assignment, client profile, browser DoH, VPN split tunnel, or domain categorization.

7. Plan Policies and Domain Lists

DNS Protection can block security-relevant domains even without its own policy if SophosLabs classifies them as a threat or security risk. Own policies complement this baseline with company guidelines.

Typical policy questions:

• Which locations get which policy?
• Which categories should be blocked?
• Which categories are only problematic for certain locations?
• Which domains must be explicitly allowed?
• Who decides on false positives?
• How long do exceptions remain valid?

Domain lists should be managed tightly. A broad allow list can reduce protection effectiveness. A broad block list can disrupt business processes. Each list needs a purpose, owner, and review date.

Filtering Policy or Endpoint DNS Protection Policy?

In Sophos Central, there are two policy levels that should not be confused.

• Filtering policy: Location-, firewall-, or network-based DNS filtering. Use for offices, firewalls, DNS servers, server networks, guests, IoT, and devices without Sophos Endpoint.
• Endpoint DNS Protection policy: Endpoint-based DNS Protection via Sophos Endpoint. Use for managed clients, laptops, and users who should also be protected outside the corporate network.

A Filtering policy is created under DNS Protection > Policies > Filtering policies and assigned to one or more locations or firewalls. Only one filtering policy can be active per location. In this policy, categories, domain lists, and additional options like Safe Search are defined.

An Endpoint DNS Protection policy uses Sophos Endpoint. The endpoint intercepts DNS traffic on the device and securely forwards it via HTTPS to DNS Protection. This means the client does not need to be manually configured to the DNS Protection IP addresses. The devices are assigned to a DNS Protection location in the endpoint policy and are then controlled by the filtering policy appropriate to that location.

Practically, this means:

• For an office with Sophos Firewall, the location plus filtering policy is the normal network path.
• For roaming clients, the endpoint DNS protection policy is sensible because protection can also apply outside the corporate network.
• Endpoint DNS Protection is not automatically available for every operating system in the company. Sophos currently supports Windows endpoints for this; Windows Server and macOS endpoints are not supported for this policy. Servers, macOS, Linux, mobile devices, and special devices must therefore still be assessed via network DNS, VPN design, or other controls.
• For mixed environments, both approaches are combined: firewall locations via locations, managed endpoints additionally via endpoint DNS protection.
• For internal domains, domain exclusions should be maintained in endpoint policies. Sophos recommends explicitly excluding internal zones rather than relying solely on an NXDOMAIN retry.
• Block pages on endpoints require the DNS Protection Root Certificate. With Sophos Endpoint, the certificate can be distributed automatically.

Which Categories Can Be Blocked?

DNS Protection offers categories organized into groups in Sophos Central. Some categories are more productivity-related, while others are clearly security-relevant. The names remain deliberately in English, as they are also displayed in Sophos Central.

• Productivity-related categories: Includes Advertisements, Auctions & classified ads, Dynamic DNS & ISP sites, Entertainment, Fashion & beauty, Gambling, Games, Hobbies, Hunting & fishing, Kid’s sites, News, Online chat, Online shopping, Personal sites, Photo galleries, Portal sites, Religion & spirituality, Restaurants & dining, Sports, Stocks & trading, Surveillance, Travel, Society & culture, and Vehicles. Allow, block, or restrict only for certain networks depending on company policy.
• Social networking: Includes Blogs & forums, Personals & dating, and Social networks. Usually not purely a security issue; decide consciously for productive networks rather than blocking across the board.
• Adult and potentially inappropriate categories: Includes Alcohol & tobacco, Controlled substances, Criminal activity, Download freeware & shareware, Extreme, Intellectual piracy, Intolerance & hate, Legal highs, Marijuana, Militancy & extremist, Nudity, Plagiarism, Pro-suicide & self harm, Sex education, Sexually explicit, Swimwear & lingerie, and Weapons. Block in many corporate environments, with exceptions only for a clear reason.
• Categories likely to cause excessive bandwidth usage: Includes Live audio, Live video, Peer-to-peer & torrents, Radio & audio hosting, Video hosting, and Voice & video calls. Often relevant for guest and client networks. Check collaboration tools beforehand to ensure legitimate calls are not disrupted.
• Business-relevant site categories: Includes General business, Business networking, Educational institutions, Financial services, Government, Health & medicines, Information technology, Job search, Reference, Search engines, Software updates, and Translators. Usually allow. Individual categories can be restricted in high-security networks.
• Infrastructure: Includes Content delivery, CRL, and OCSP. Normally allow because these categories can be important for updates, certificate checks, and many cloud services.
• Threats and liabilities: Includes Anonymizers, Hacking, Newly registered websites, Parked domains, Phishing & fraud, Spam URLs, Spyware & malware, and Unauthorized software stores. Generally block. For false positives, work specifically with domain lists, not by opening entire groups.
• Data loss: Includes Business cloud apps, Personal cloud apps, Personal network storage, and Web E-mail. Strongly dependent on DLP, cloud, and compliance requirements. Often treat server and admin networks more strictly than normal users.
• Uncategorized: Do not block blindly. Evaluate first, as legitimate new or internal services can be uncategorized temporarily.

Domain lists take precedence over categories. An allowed domain in a domain list remains allowed even if the category would be blocked. A blocked domain remains blocked even if the category would be allowed. Therefore, domain lists should be documented and regularly reviewed.

8. Block Pages and Certificates

For blocked domains, DNS Protection can display an HTTPS block page. For users to see this block page correctly, the DNS Protection Root Certificate must be installed as trusted on the affected devices.

If TLS Inspection or web filtering is also active on the firewall, the certificate and exception planning must match. For the firewall CA, see Distribute Sophos Firewall CA Certificate for TLS Inspection.

The certificate and the block page test are located in Sophos Central under DNS Protection > Installers. In addition, blockpage.dnsprotection.sophos.com should be reachable. If this domain is affected by Web Protection, TLS Inspection, DNS policy, or another control, the actual DNS Protection decision may be correct while the block page still appears incorrectly or not at all.

If block pages are not displayed, do not immediately adjust the policy. Often certificates are missing, the client uses a different DNS path, or blockpage.dnsprotection.sophos.com is disrupted by another control.

Test DNS Protection

Sophos Central provides a test link under DNS Protection > Installers. If the configuration is correct, the browser displays a confirmation.

Additionally, practical testing should include:

• Client uses the firewall as a DNS server.
• Public domain is resolved via DNS Protection.
• Internal domain is correctly resolved via DNS Request Route.
• Blocked test domain is blocked.
• Logs appear in Sophos Central.
• DNS queries appear at the correct location.
• Alternative DNS servers are not used.
• VPN or guest network behaves as planned.

For real error analysis, do not only test the browser. nslookup, dig, firewall logs, DHCP leases, and Sophos Central logs together provide a better picture.

Test Commands for Clients

On a test client, first check which DNS server is actually used. A successful browser test is not enough if the client is simultaneously using another resolver, DoH, or a VPN profile.

Windows:

ipconfig /all
nslookup example.com
nslookup example.com <firewall-ip>
Resolve-DnsName example.com

macOS:

scutil --dns
dig example.com
dig @<firewall-ip> example.com

Linux:

resolvectl status
dig example.com
dig @<firewall-ip> example.com

Replace <firewall-ip> with the internal interface address of the Sophos Firewall that should serve as the DNS resolver in the respective network. If the query against the firewall works, but the normal query uses another resolver, the problem usually lies with DHCP, operating system profile, VPN client, browser DoH, or a local DNS configuration.

For internal domains, an additional test with an internal zone should be conducted:

dig @<firewall-ip> internal-host.corp.example.com

This test must land at the internal DNS server via the appropriate DNS Request Route. If public domains work but internal names do not, DNS Protection is rarely the actual cause. Then DNS Request Routes, internal DNS servers, search domains, and client DNS suffixes should be checked.

Troubleshooting

Location Does Not Appear in Sophos Central

Check whether the public WAN IP or the DDNS FQDN in the location is correct. For multiple WAN lines, all relevant outgoing addresses must be considered. With dynamic IP addresses, there may be short delays until DNS Protection recognizes the change.

Also check whether the location type matches the design. A firewall that sends classic DNS queries to the provided IP addresses belongs in the Traditional DNS path. Endpoint DNS Protection, by contrast, uses Secure DNS via the endpoint component.

If the location is maintained using an FQDN, also check whether the FQDN really points externally to the current public IP. Sophos Central can show an automatically detected address, but later changes must be monitored during operation.

If no location assignment is visible despite correct firewall configuration, also check My Environment > Alerts in Sophos Central. Problems can occur if an FQDN does not point to a valid public IP, or if the same public IP is already used in another DNS Protection location of another customer account. This is especially relevant with CGNAT, shared provider addresses, central proxy or VPN exits, or incorrectly maintained DDNS names.

Internal Names No Longer Work

Then DNS Request Routes are usually missing, or the clients are not querying the expected resolver. Internal AD domains, reverse zones, and application domains should be explicitly forwarded to internal DNS servers.

DNS Protection Blocks an Internal or Legitimate Domain

First, clarify whether the domain is internal, public, miscategorized, or actually risky. Then check the domain list and policy. Do not set a broad allow rule before the cause and affected users are known.

Logs Remain Empty

If no logs appear in Sophos Central, the client may not be using DNS Protection. Check: DHCP, client DNS, firewall DNS, NAT redirection, alternative resolvers, VPN profile, and whether the location is correctly recognised in Sophos Central.

For deeper analysis, Threat Analysis Center > Live Discover can also be used if the environment uses the required Central functions. DNS Protection data can be queried there more granularly than in the standard reports, for example by domain, policy action, location, user, or device. For normal acceptance, however, start with logs and reports, a test client, and resolver checks.

Block Page Does Not Appear

Then often the DNS Protection Root Certificate is not installed, the client uses a different DNS path, or another security control affects the connection. Also, check TLS Inspection and Web Protection.

Also check whether the block page domain is reachable and is not blocked by an upstream policy. If a browser uses DoH, a VPN profile, or Apple Private Relay, you may not see a Sophos block page even though the normal network DNS path would be correct.

DoH or Private DNS Bypasses Control

Browsers and operating systems can use DNS over HTTPS or private DNS functions. Depending on the environment, these functions must be controlled via browser, MDM, or operating system policy. DNS Protection on the network path only helps if the queries actually run through the intended resolver.

VPN Clients Behave Differently Than LAN Clients

For VPN clients, behaviour strongly depends on the profile. Full tunnel, split tunnel, DNS suffixes, search domains, and local resolvers of the client can influence name resolution. If DNS Protection works in the LAN but not over VPN, first check VPN profile, assigned DNS servers, DNS suffixes, and firewall rules. For remote access environments, additionally see Sophos Connect or SSL VPN: Which Remote Access Solution Fits?.

Operational Recommendation

DNS Protection should be operated like a security control, not like a one-time DNS server swap.

From Avanet’s perspective, one should honestly decide beforehand whether DNS Protection is actually the right tool for the environment. For many classic firewall installations, fast, redundant DNS resolvers plus well-maintained threat feeds on the firewall are the more robust operational variant. DNS Protection is especially worthwhile if the operation also actively uses the Central policies, logs, categories, domain lists, and endpoint component.

Regularly check:

• Locations and WAN IP addresses are correct.
• DHCP continues to distribute the correct DNS servers.
• Internal DNS Request Routes are up to date.
• Policies and domain lists have owners and review dates.
• Logs are evaluated.
• Blocked top domains are checked for false positives.
• New locations, VPN networks, and guest networks are considered in the design.

For detection topics, Operate Sophos Firewall NDR and Active Threat Response can complement. For known malicious IPs, domains, and URLs at the firewall level, Sophos Firewall Threat Feeds remain relevant.

Checklist

• Checked Sophos Central DNS Protection licence.
• Location created as a location.
• Correct location type selected: Traditional DNS for firewall sites, Secure DNS for Endpoint DNS Protection.
• Public WAN IP or DDNS FQDN correctly entered.
• Location limit and IP/FQDN entries planned deliberately.
• Copied DNS Protection IP addresses from Central.
• Sophos Firewall uses DNS Protection as a DNS forwarder.
• Internal domains covered with DNS Request Routes.
• DHCP distributes the firewall as a DNS resolver.
• Secondary DNS on clients deliberately decided and not accidentally built as a bypass.
• Checked and redirected direct DNS bypass via NAT if necessary.
• DoH, DoT, VPN profiles, and browser policies checked separately.
• Planned DNS Protection Root Certificate for block pages.
• Endpoint platforms and unsupported devices assessed separately.
• Successfully checked test link from Sophos Central.
• Controlled logs and reports in Sophos Central.
• Defined false-positive process and domain list review.

FAQ