What are the best practices for using DNS filtering to reduce phishing and malware exposure?

Use DNS filtering as a policy layer, not a standalone control. Prioritise blocking malicious, phishing, and unwanted destinations, then supplement that with content category rules, custom allow and block lists, and encrypted DNS transport. Keep rule design simple enough for teams to manage centrally, and review exceptions regularly so the control remains effective as business needs evolve.

Why This Matters for Security Teams

DNS filtering matters because it blocks a large share of phishing, malware delivery, and command-and-control lookups before a browser, endpoint, or user action can fully engage with the threat. That makes it a useful policy layer for reducing exposure, especially where endpoint coverage is uneven or users work outside the perimeter. It is not a substitute for email security, EDR, or web gateway controls, but it can reduce the blast radius when those layers miss something.

The main mistake is treating DNS filtering as a set-and-forget blocklist. In practice, teams that over-rely on static categories, poorly governed exceptions, or inconsistent resolver enforcement end up with gaps that attackers can exploit through newly registered domains, compromised legitimate sites, and fallback resolvers. The control is strongest when paired with logging, tuning, and incident workflows that actually use the telemetry it produces. For baseline control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a solid reference point for operationalizing filtering as part of a broader defensive architecture.

In practice, many security teams encounter DNS filtering gaps only after a phishing page or malware callback has already been reached, rather than through intentional policy design.

How It Works in Practice

Effective DNS filtering starts with clear policy intent. Teams should decide what categories are blocked by default, what business exceptions are allowed, and which lookups must be logged for hunting and investigation. The control should be enforced as close to the user and workload as possible, whether through managed endpoints, secure resolvers, network appliances, or cloud-managed DNS enforcement. Where possible, organizations should prevent bypass paths such as alternate resolvers, split tunneling exceptions, or unmanaged devices using external DNS.

Operationally, the best programs combine several layers:

• Block known malicious, phishing, and newly registered domains where the signal is high confidence.
• Use category-based filtering for malware, command-and-control, anonymizers, and other high-risk classes.
• Maintain tightly governed allow lists for business-critical services that would otherwise be blocked.
• Log denied and allowed queries so SOC teams can investigate suspicious lookups and trends.
• Validate encrypted DNS transport policies so filtering is not bypassed through unmanaged channels.

DNS filtering works best when it is integrated into detection and response, not just access control. Query logs can expose early indicators of compromise, including repeated lookups to low-reputation domains or unusual resolution patterns from a small set of hosts. That operational use aligns well with broader control hygiene described in CIS Controls v8, especially where teams are trying to standardize preventive and detective coverage.

Current guidance also suggests that DNS filtering should be tested against realistic user journeys, because a policy that is technically sound but too disruptive will be bypassed informally. These controls tend to break down when remote users, guest networks, or unmanaged devices can resolve DNS outside the approved path because enforcement is no longer consistent.

Common Variations and Edge Cases

Tighter DNS filtering often increases administrative overhead, requiring organisations to balance stronger exposure reduction against business continuity and exception management. That tradeoff is especially visible in environments with heavy SaaS use, software development activity, or third-party integrations, where overblocking can interfere with legitimate workflows.

There is no universal standard for this yet on how aggressively organisations should block low-reputation or newly registered domains. Some teams prefer a conservative deny-by-default posture for high-risk user groups, while others adopt a more permissive model with stronger monitoring. Best practice is evolving toward risk-based policy tiers rather than one uniform rule set for every user and device.

DNS filtering also has limits in encrypted and proxy-heavy environments. If users browse through remote proxies, security service edge platforms, or applications that hardcode IP addresses, DNS policy may not see the full picture. In those cases, DNS filtering should be paired with endpoint, web, and identity controls rather than expected to carry the entire burden. Where phishing resistance is a priority, the most effective programs align DNS controls with user awareness, access restrictions, and incident response so suspicious traffic can be contained quickly rather than debated after the fact.

Related resources from NHI Mgmt Group

• How do organisations reduce identity data exposure when using verifiable credentials?
• How should security teams reduce malware risk from phishing and malicious downloads?
• How can identity teams reduce exposure to redirect-based phishing without relying on blocklists?
• How should organisations reduce information exposure when using LLMs on internal data?