An Employee Clicks a Phishing Link: How DNS Protection Can Still Make a Difference
Even well-trained employees can click a malicious link. Protective DNS adds another layer of security by blocking certain dangerous destinations before a connection is established. Here's how it works and where its limitations lie.
It's 9:12 on a Tuesday morning.
An employee receives what appears to be an ordinary email from a supplier.
The message is well written. The logo looks familiar. The request makes sense: a revised invoice is available and needs to be reviewed.
They click the link.
Nothing particularly unusual has happened. Employees open links all day, from suppliers, customers, colleagues and business applications.
And that's exactly the problem.
A company's cybersecurity strategy cannot depend entirely on every employee recognizing every malicious message.
It also needs to consider what happens after someone clicks.
Before a website opens, something usually happens in the background
When you enter a website address or click a link, your device generally needs to find the IP address associated with the domain name.
That's one of the jobs performed by the Domain Name System, or DNS.
Most people never notice this process.
They click a link and the website appears.
But this otherwise invisible step can provide an additional security control.
If a domain is known to be malicious, a protective DNS service can apply a policy that prevents its normal resolution.
In practice, this may stop the browser from connecting to that destination through the expected DNS lookup.
The user might see a warning or simply find that the website cannot be reached.
The idea is straightforward: block certain dangerous connections before the user reaches the destination.
The US National Institute of Standards and Technology discusses protective DNS as part of a broader defense-in-depth approach in its Secure Domain Name System (DNS) Deployment Guide, published in March 2026.
Source: NIST SP 800-81 Rev. 3
What this changes in a real phishing scenario
Let's return to our employee.
The link in the supplier email leads to a fake login page.
Without an effective blocking mechanism, the browser might open the site and display a convincing imitation of a legitimate business service.
The employee is then invited to enter their username and password.
If the destination is already recognized as malicious, a correctly configured protective DNS service may stop the connection before the fake page is displayed.
The employee doesn't need to understand DNS records or identify every suspicious character in the domain name.
A technical control has provided another opportunity to prevent the attack.
This doesn't make security awareness unnecessary.
It means awareness is no longer the only barrier.
Why this matters for small businesses
Business activity increasingly depends on online services.
Accounting platforms, CRM systems, electronic signatures, cloud storage, HR software, customer portals and supplier platforms are all part of normal working life.
Each service generates emails, notifications and links.
Some legitimate messages even create a sense of urgency.
Invoices need approval. Contracts are waiting for signatures. Passwords expire. Customers request documents.
Attackers take advantage of these familiar workflows.
For a small business with limited security resources, DNS filtering can provide an additional layer of control without requiring every employee to become a phishing expert.
Instead of relying entirely on individual judgment, the organization can apply centrally managed policies to certain DNS requests.
That can be useful for office networks and, with an appropriate deployment model, devices working remotely.
But protective DNS is not a magic security solution
This is where marketing claims can become misleading.
Protective DNS does not block every phishing campaign, malware infection or cyberattack.
A newly registered malicious domain may not yet be recognized.
An attacker might use a legitimate cloud service or a compromised website.
DNS filtering generally operates at domain-resolution level. It cannot reliably distinguish one specific malicious HTTPS page from another harmless page hosted under the same domain.
And if devices are allowed to use alternative DNS resolvers, unmanaged DNS-over-HTTPS or direct IP connections, some protective controls may be bypassed.
There are also false positives.
A legitimate business service might occasionally be classified incorrectly, interrupting normal work.
That is why protective DNS needs an appropriate exception process, monitoring and technical ownership.
It is an additional security layer, not a substitute for endpoint protection, MFA, patch management or incident monitoring.
NIST explicitly places DNS security within a broader risk management and defense-in-depth strategy.
Source: NIST — Secure DNS Deployment Guide
DNS events can also help an investigation
There's another benefit that is easy to overlook.
DNS logs can sometimes reveal unusual patterns of activity.
For example, a workstation repeatedly attempts to resolve domains associated with known malicious infrastructure.
A server suddenly starts requesting unfamiliar destinations.
A device produces a noticeable increase in failed DNS lookups.
Or suspicious requests appear shortly after an employee opens an unexpected attachment.
None of these observations proves an intrusion on its own.
An unfamiliar domain might belong to a legitimate business tool. An increased number of DNS requests might result from a software update.
The important part is context.
Which device made the request?
When did it happen?
Was the domain blocked?
Was there a successful connection through another route?
Did endpoint or network monitoring show anything else?
This is where DNS information can become useful for a security operations team.
It provides another piece of evidence that can be correlated with other events.
Five things to check before deploying DNS protection
A company considering protective DNS should start with its existing environment.
First, identify which DNS resolvers its devices actually use. A security policy applied to the office DNS server is of limited value if half the laptops bypass it.
Second, think about remote work. Devices used from home, hotels and customer locations may require a different deployment approach.
Third, define a realistic blocking policy. Security controls should protect business activity, not unnecessarily interrupt it.
Fourth, establish a process for investigating blocks and handling exceptions. Someone must be able to determine whether a blocked domain is actually dangerous.
Finally, consider privacy and log retention. DNS records can reveal information about users and their activity, so the organization needs appropriate access controls and retention practices.
France's ANSSI also provides technical guidance on DNS service architectures, covering considerations for securing these essential infrastructure components.
Source: ANSSI — Recommendations for DNS Service Architectures
The difference between enabling a filter and managing it
Activating a DNS filter is relatively straightforward in many environments.
Keeping it useful over time is another matter.
Someone needs to review policies, handle false positives, investigate meaningful events and understand how DNS protection fits with the company's other security controls.
This is where managed services can help.
Cyberhack includes managed DNS protection among the services presented through Cyberhack Platform.
Organizations receiving these services can review information Cyberhack has published for their environment within a dedicated customer workspace.
The point is not to replace the company's network architecture or promise that every malicious connection will be detected.
It is to make DNS protection part of a more structured security approach, supported by operational follow-up and clear reporting.
Conclusion
No company can reasonably expect its employees to identify every malicious email.
Even experienced IT professionals sometimes encounter phishing messages that look convincing.
The answer is not to abandon awareness training.
It's to combine human awareness with technical controls.
Security awareness helps people recognize suspicious situations.
Protective DNS can block certain dangerous destinations.
MFA can reduce the impact of some credential-theft attempts.
Endpoint and network monitoring can help investigate suspicious behavior.
None of these measures is perfect on its own.
Together, they create multiple opportunities to prevent an ordinary click from becoming a serious security incident.
And sometimes, stopping one connection at the right moment makes all the difference.
