DNS Filtering for Business: Block Malware, Phishing, and Distractions Without an Agent

Most small businesses do not have a security team. They have one person who is "good with computers," a stack of mismatched laptops and phones, and a to-do list that never gets shorter. When a phishing email slips through or a piece of malware tries to phone home, there is rarely time to roll out endpoint software on every machine, configure a management server, and keep it all patched. The advice to "just deploy an agent fleet-wide" assumes a maturity most small teams do not have and a budget they would rather spend elsewhere.

There is a quieter layer of protection that asks for far less and still covers a lot of ground: filtering at the DNS resolver. This post explains what it does, where it genuinely helps a small business, and, just as importantly, where it does not, so you can decide honestly whether it fits.

The small-business pain, named plainly

The threats that actually hit small teams are not exotic. They are the same handful, over and over:

• Phishing. Someone receives a convincing email, clicks a link, and lands on a page built to harvest a password or a payment detail. The page often lives on a domain registered hours ago for exactly this purpose.
• Malware callbacks. A machine gets infected, and the malware reaches out to a command-and-control domain to receive instructions or send stolen data. That outbound lookup is a chokepoint.
• Distraction. Employees lose hours to apps and sites that are designed to be hard to put down. This is not a moral failing; these products are engineered to hold attention. But on shared or work-issued devices, a team may simply prefer that certain categories not be reachable during the day.
• No time for heavy tooling. Device management, endpoint agents, and full web gateways are real solutions, and real projects. Many small businesses never start them because the setup cost feels larger than the problem.

DNS filtering does not solve all of this. But it addresses a meaningful slice of it with very little operational weight, which is why it is worth understanding before you reach for something heavier.

How resolver-level filtering works

Every connection your devices make starts with a question: "What is the IP address for this domain?" That question goes to a DNS resolver. Normally the resolver answers, and the connection proceeds.

A filtering resolver adds one step. Before answering, it checks the domain against your policy. If the domain is a known malware host, a freshly registered phishing page on a threat list, or a category you have chosen to block, the resolver declines to return an address. The browser or app gets nothing to connect to, so the connection never opens.

Two properties make this useful for a small business:

1. It is enforced before the connection exists. You are not cleaning up after a click; you are quietly preventing the lookup that the click depends on. A blocked phishing domain never loads.
2. It applies to whatever points at it. Because the filter lives at the resolver rather than on each device, a single policy can cover laptops, phones, and even the office network, without installing anything on the endpoints themselves.

With Guardino, this filtering happens at our resolver over encrypted DNS. The resolver sees the domain a device looks up, not the full URL and not the contents of any page. That distinction matters for both privacy and for setting honest expectations, which we will return to below.

Covering every device, without an agent

The part that saves small teams the most time is the absence of an endpoint agent. There is no software to install on each machine, no fleet to keep patched, and no native mobile app. You configure encrypted DNS once per profile, and every device pointed at that profile inherits the policy.

In practice, configuration looks like this:

• Laptops and desktops point their DNS at your Guardino profile.
• iPhones and iPads install a small configuration profile (a .mobileconfig file) that sets encrypted DNS system-wide.
• Android phones scan a QR code, or use the bare hostname dns1.guardino.ai in the Private DNS setting.
• The whole office network can use the resolver at the router level, so guests and shared devices are covered too.

The DoH endpoint carries a per-profile token in its URL, which is how the resolver knows which policy to apply. The setup flow generates the iOS profile and the Android QR code for you. See the setup guide for the exact steps per platform.

There is a real trade-off in this simplicity, and it is fair to say it out loud: an agent on the device can do things a resolver cannot, like scanning files or enforcing policy even when someone manually changes their DNS. Resolver filtering is broad and low-effort, not all-seeing. For many small businesses, broad and low-effort is exactly the right first move, but it is a first layer, not the whole stack.

Org-wide profiles and per-seat policies

A small business is rarely one undifferentiated group. The front desk, the developers, and the shared meeting-room tablet have different needs. Forcing one rigid policy on all of them tends to produce either too much friction or too little protection.

Guardino is organized around profiles, so you can match policy to context:

• A tighter profile for shared, kiosk, or front-of-house devices, heavier on category blocks, lighter on exceptions.
• A lighter profile for technical staff who legitimately need to reach a wider range of domains.
• A family or child profile if the business is a household operation, a small shop with younger helpers, or a setting where minors use the devices.

Each profile can apply:

• Curated blocklists for ads, trackers, malware, and phishing.
• Category policies such as the Mind Shield bundle (domains built around attention manipulation and compulsive engagement), Safe Search enforcement, a social-media bundle, gambling, and adult-content controls.
• Custom allow and deny rules, per tenant, so you can permit a specific tool your team depends on or block a domain you have decided is off-limits, without waiting for anyone else's list to update.

On the Team plan ($19.99 per seat), per-seat pricing maps onto this naturally: each seat can carry its own profile rather than everyone living under a single compromise policy. Smaller setups can start on the Pro plan ($4.99/mo), and the free tier covers 300,000 queries if you want to try the mechanics before committing.

Visibility: query stats and logs you control

You cannot manage what you cannot see, and a filter that gives no feedback is hard to trust. The Guardino dashboard shows real query statistics and logs: which domains were looked up, which were allowed, which were blocked, the category, and when. For a small business, this is enough to answer the everyday questions. Is the phishing list catching anything, what is generating the most blocked traffic, did a particular device behave strangely overnight.

Two honest notes on this visibility:

• It is domain-level, not content-level. The logs show that a device looked up a domain, not what was typed into a page or sent over it. DNS sees domains, not full URLs or page contents.
• Retention is yours to set. Query metadata is kept for 30 days by default, and you can shorten that window or delete records at any time. Device IP addresses are not held in long-term storage, and query data is never sold or shared. The specifics are written down in the privacy policy rather than implied.

For a business, that combination, useful operational visibility without building a permanent record of your staff's every move, tends to be the right balance. You get the audit trail you need to run the filter, kept only as long as you choose.

Where DNS filtering ends, and what to pair it with

Honesty is more useful than a sales pitch here, so this section is deliberate. DNS filtering is a strong, broad, low-effort layer. It is not a complete security program. It does not:

• Inspect file contents or email attachments. A malicious document that arrives over a domain you have not blocked will still arrive. DNS does not open the file.
• Stop attacks that skip the lookup. If something connects directly to a raw IP address with no DNS request, there is no domain to filter.
• Override a determined local change. Without a device agent, someone with admin rights can point their machine at a different resolver. Profiles and network-level enforcement reduce this, but resolver filtering alone cannot guarantee it on an unmanaged device.
• Replace the fundamentals. Endpoint antivirus, device management, off-site backups, multi-factor authentication, and a thirty-minute staff conversation about how phishing actually looks. Those still matter.

Think of DNS filtering as the layer that quietly removes a large class of bad connections before they start, so the heavier tools and the humans have less to catch. It pairs well with the platform controls a small team may already use. Apple and Google both ship device-management and screen-time features that work happily alongside a filtering resolver. Use them together; they solve different parts of the problem.

A realistic first step

If you run a small team and you have been meaning to "do something about security" but never had the runway for a full rollout, this is a low-commitment place to begin. Pick one tight profile for shared devices, point a few machines at it, and watch the dashboard for a week. You will see what your team's traffic actually looks like, the phishing and malware lists will be working in the background, and you will have spent an afternoon rather than a quarter.

It will not make you a hardened enterprise. It will close a common door that small businesses tend to leave open, with very little weight on the person who is "good with computers." That is a fair trade, and an honest one.

If you want to try it, you can create an account and start with the free tier, or read the setup guide first to see exactly what configuring a device involves.