Secure DNS vs. Phishing: How to Block Threats Before a Site Even Loads

A phishing attack often starts with a simple action: the user clicks a link. Before the page loads, the device queries DNS to resolve the domain's IP address. Secure DNS uses this early stage to block access to a malicious or suspicious domain before the site even opens.

This doesn't replace user awareness training, email security, or EDR, but it adds an important layer of early-stage control.

Why DNS Matters for Defense

Almost every connection to a website, API, or command-and-control server starts with a DNS query. If, at this stage, a domain is identified as linked to phishing, malicious infrastructure, or an unwanted category, the connection can be stopped before the user ever sees the page or malicious code gets a response.

That's why DNS protection is useful not only against phishing, but also against communication between infected hosts and C2 servers.

Why DNS Sees Phishing Earlier Than Email and the Browser

The DNS resolver receives the request to resolve a domain earlier than the email gateway manages to bring the message to content analysis, and earlier than the browser starts loading the page — because both of these layers come into play later in the chain.

The difference lies in the moment of the check itself. An email gateway analyzes a message at the moment of delivery: the subject, the attachments, the sender reputation, the links inside the text. But time can pass between the delivery of the message and the click on the link — minutes, hours, sometimes days — and during that time a domain that looked neutral when the message was sent can turn into a phishing resource. Some email security architectures can re-check a link at the moment of the click, but that check also comes down to DNS resolution of the same domain.

Browser protection is one more step further along the chain: it comes into play once a network connection has been established and the page content starts loading. Between sending the DNS query and receiving the first bytes of the page, the TCP connection is established — if the domain is already blocked at the name resolution stage, things simply never get that far.

DNS is therefore the earliest shared control point, no matter where the link came from: an email, a messenger, an ad banner, or a compromised legitimate website. This doesn't make DNS filtering more important than email security or EDR — it makes it the earliest link in a single chain that has to work as a whole.

Which Domain Indicators Justify Blocking

Secure DNS doesn't block domains arbitrarily: the decision relies on specific verifiable indicators — how long ago the domain was registered, how closely its spelling resembles a legitimate resource, which reputation category it belongs to, and what the profile of requests to it from the organization's network looks like.

No single indicator on its own proves that a domain is malicious — a newly registered domain may belong to a legitimate startup, and an atypical zone may belong to a new partner. That is why Secure DNS correlates several indicators at once and relies on reputation databases and categories rather than on one isolated signal.

How Secure DNS Blocks Phishing

Secure DNS checks domains against reputation databases, categories, and organizational policies. If a domain is considered dangerous, the request is blocked or redirected to a warning page.

Typical signals include:

• the domain is a known phishing domain;
• the domain was recently registered and mimics a brand;
• the domain belongs to a blocked category;
• the domain is used in a malicious campaign;
• the query behavior looks anomalous.

Why Email Security Alone Isn't Enough

An email gateway can block a message containing a link, but users receive links through more than just email: messengers, documents, personal email, ads, and compromised websites. Secure DNS closes off some of these bypass routes because it checks the domain request itself.

Where DNS Filtering Doesn't Close the Threat

Secure DNS sees only the fact of a request to a domain: where a connection does without a DNS query altogether or uses an already trusted domain, the DNS filter will not see that threat, and the gap has to be closed by the next layer of protection.

Three typical scenarios in which the DNS layer alone will not work:

• Direct access by IP address. If malicious code contacts its command server directly by IP, bypassing name resolution, the DNS resolver will not see that request at all. This scenario is covered by EDR, which observes the network activity of a process directly on the endpoint rather than DNS queries alone.
• Encrypted DNS that bypasses the corporate resolver. If a device queries a public DoH or DoT resolver directly, bypassing corporate settings, Secure DNS policies are not applied to that request. This is closed at the network level — with rules that redirect or block requests to public encrypted resolvers that bypass the organization's protected DNS service.
• A link on legitimate hosting. If a phishing page is hosted on a trusted cloud service or in a legitimate SaaS product, the domain itself has a good reputation and the DNS filter will not block it. Here the gap is closed by tools that analyze the content and the context of the page or the message itself rather than the domain reputation alone — email security, and this scenario is covered in more detail in How Email Security Works and in Protection Against Phishing and BEC.

What You Can See in the Logs

The DNS query log helps with incident investigation. It can show:

• who accessed the suspicious domain;
• when the requests started;
• whether requests repeat from the same host;
• whether similar requests appear from other users;
• which policies were triggered.

This data is valuable for the SOC and helps correlate DNS events with EDR telemetry, email security, and SIEM.

How to Tie a DNS Signal to Email and the Endpoint in a Single Investigation

A DNS log taken on its own shows only that a particular host accessed a suspicious domain. The full picture of an incident comes from correlating that event with the email log — who received the message with the link — and with EDR telemetry — what happened on the host after the request.

A typical incident investigation chain looks like this: a message with a link passes through the email gateway, the user clicks the link, the host sends a DNS query for the domain, and Secure DNS makes a decision — block the request or let it through. If the request is allowed and the domain later turns out to be malicious, it is EDR telemetry that shows which process initiated the connection and what happened on the host next. Correlating all three sources by host, user, and timestamp in the SIEM turns scattered events into a coherent investigation of a single incident rather than three independent records in different systems. How DNS events are exported for such correlation is described in more detail in How Secure DNS Protects Your Network from DNS Attacks.

Remote Employees

DNS protection is especially important for remote employees. If a device outside the office uses a protected DNS service and the organization's policies, phishing domains can be blocked regardless of whether the user is on the corporate network. The specific setup depends on the architecture of the organization and the supported modes — before deploying protection for remote hosts, it is worth checking the product documentation.

How to Roll Out Secure DNS in Stages

Deploying DNS filtering without preparation almost always leads to a burst of false blocks and a flood of support tickets. The right order reduces that risk and provides visibility before blocking is turned on.

1. Resolver inventory. First you need to find every DNS resolver actually in use across the organization: corporate ones, branch ones, and the default resolvers on the devices of remote employees. You can't protect what isn't accounted for.
2. Moving clients to Secure DNS. Devices are switched to the protected resolver via DHCP, local forwarding, or an agent — in stages, by user group, rather than across the whole organization at once.
3. Category configuration. The administrator chooses which categories are blocked right away — known malicious and phishing ones — and which require agreement with the business, content restrictions, for example.
4. Monitoring mode before blocking. Before blocking is enabled, Secure DNS runs in logging mode: it records which domains users access but does not block them. This shows which legitimate services might accidentally fall under future policies.
5. Gradual transition to blocking. Blocking mode is enabled by category and by user group, starting with the most unambiguous cases — known malicious and phishing domains.
6. Handling false positives. A clear process is needed: the user reports a blocked legitimate domain, the administrator quickly verifies it and adds an exception, and policies are reviewed regularly based on such reports.

Common Deployment Mistakes

• Turning on blocking right away, with no monitoring period. This blocks legitimate services unexpectedly for users, triggers a wave of support tickets, and undermines the trust of the business in the tool.
• Migrating only part of the devices. If the laptops of employees outside the office keep using the default resolver, protection does not work exactly where the risk of following a phishing link is higher.
• DNS logs are collected but not analyzed. Logs without regular review and without a link to other telemetry sources lose their main value — the ability to quickly reconstruct the timeline of an incident.
• Secure DNS is treated as exhaustive protection. Direct access by IP, a phishing page on legitimate hosting, and resolver bypass through public encrypted DNS are three specific gaps that the DNS layer alone does not close (see the section above).
• No fast process for the white list. If unblocking a legitimate domain takes days, some employees start bypassing the corporate resolver on their own — and that opens a worse gap than having no DNS filtering at all.

Checklist Before Turning On Blocking

• Every resolver in the organization is accounted for, including the devices of remote employees and branches.
• A monitoring period long enough to reveal rare and seasonal requests has been completed.
• Someone is assigned to handle reports of false positives.
• Export of DNS logs to the SIEM is configured, and correlation with email and EDR events by host and time has been verified.
• There is a plan for blocking or redirecting public encrypted DNS resolvers that bypass the corporate one.
• Blocking categories have been agreed with business units rather than chosen by the security team alone.

Hands-On Practice

In the Deploying and Administering BI.ZONE Secure DNS course, you can practice policy configuration and DNS event analysis on lab environments: see how domains get blocked, what a query log looks like, and how DNS protection complements other security tools. If you need to start with the basics, read What Secure DNS Is, and the technical side of protection against DNS attacks is covered in How Secure DNS Protects Your Network from DNS Attacks.