A small agency policy should do four jobs reliably: refuse known malicious destinations, follow work devices beyond office Wi-Fi, preserve essential client services, and explain a block well enough to resolve mistakes. Start with a shared security floor, not a long catalogue of productivity preferences. A short policy that survives real deadlines is stronger than an ambitious one people learn to bypass.
Define the agency’s non-negotiable floor
Treat the baseline as the default protection applied across the agency’s Tenants, not every preference the founder has about internet use. Reserve enforced Tenant policy for protections that a local resource must never weaken. A useful policy is short enough for a contractor to understand and precise enough to test: threats, scope, response, reporting route, exception owner, and review date.
Inventory the work before choosing categories. Include design and development laptops, finance devices, shared meeting-room hardware, test phones, remote contractors, and endpoints that reach client systems. Note which Tenant owns each device, the networks it uses, and the services that cannot fail during delivery: identity, source control, cloud consoles, file transfer, fonts, analytics, advertising, payment, support, and client staging domains.
| Decision | Starting position | Reason |
|---|---|---|
| Known malware, phishing, botnet, and command-and-control | Block | Reduces contact with known threat infrastructure |
| Uncategorized or newly observed domains | Observe or pilot narrowly | Agency work frequently touches new client properties |
| Client and production services | Allow only verified required domains | Keeps exceptions narrow and attributable |
| Roaming DNS path | Require and test | Home, coworking, and travel are normal work locations |
| Detailed activity | Off or purpose-limited | Security evidence should not become routine surveillance |
NCSC describes deny lists as a core protective DNS capability and says organizations should also be able to curate allow lists so critical services remain available.2 Cloudflare’s common-policy examples similarly separate trusted corporate domains from security-category blocking and make rule precedence explicit.3 DNSFilter’s setup material groups category, threat, app, and custom-list controls rather than presenting one universal strict preset.4 In practice, threat protection and business-specific choices should remain separate decisions.
Separate enforced protection from flexible work
- Define baseline scope. Name the Tenants, endpoints, networks, and roaming conditions that receive the reusable starting policy.
- Define enforced scope. Reserve it for agreed protections, such as high-confidence malicious destinations, that Tenant resources cannot weaken.
- Define response. Choose block, refuse, or redirect behavior and make the support route understandable to the affected person.
- Define exceptions. Require a verified domain, business reason, owner, affected scope, and review date.
- Define evidence. Keep routine review aggregate-first and allow retained detail only to Tenant roles answering a named incident or compatibility question.
Keep content preferences outside enforced security unless the agency has a documented business, legal, or client requirement. Blocking social networks, generative tools, advertising, streaming, or file sharing can break research and delivery. Those decisions need their own Tenant scope and owner. Do not hide them beneath a malware label because one DNS service can express both.
Write what DNS cannot promise. It acts on domain lookups and policy outcomes. It cannot read page contents, typed search terms, in-app chats, voice audio, full browser history, or the contents of an attachment. Direct IP connections, allowed platforms, fresh malicious domains, and traffic sent to another resolver can evade the intended decision. Endpoint security, patching, identity controls, email protection, backups, and staff verification remain necessary.
Pilot through a normal client day
Choose an ordinary endpoint with a cooperative owner and representative client work. Avoid the finance laptop, launch day, and the founder’s unusually permissive machine. Confirm the endpoint’s resolver path and use a documented safe test domain. Then complete a real workflow: sign in, join a meeting, open source control, retrieve client assets, publish to staging, and submit time or expenses.
- Test on office Wi-Fi, home Wi-Fi, a mobile hotspot, and any corporate VPN used by the pilot.
- Confirm both the expected block and ordinary allowed work; a green block page alone is not a complete test.
- Check browser Secure DNS, private relay, VPN, and manual resolver settings when requests do not appear.
- Run the pilot for several representative workdays before expanding to contractors and client-specific devices.
- Publish one support route so people report a failure instead of silently changing DNS.
For a block, establish which rule acted before changing policy. A certificate error may be a side effect of redirection rather than a broken site. A domain can also support multiple products or load dependencies from other hostnames. Reproduce the exact work path, verify domain ownership, and allow the smallest necessary hostname at the narrowest applicable scope.
Expire exceptions before clients do
Agency work changes quickly. A client staging domain may exist for a week; an old file-transfer service may disappear after a migration. Every exception should contain an owner, reason, scope, creation date, and review date. During the review, prove the dependency still exists. Remove the exception when the project ends rather than carrying client risk into unrelated work.
Review the baseline monthly and after a meaningful incident, provider category change, merger, new office, or major client requirement. A weekly operational glance can be smaller: endpoint coverage, aggregate security blocks, unresolved false positives, and exceptions approaching review. Avoid ranking people by request counts. Background software and different roles make those comparisons misleading.
- Blocking broad unknown categories before observing agency dependencies.
- Testing only on office Wi-Fi while most people work elsewhere.
- Using a public secondary resolver that silently bypasses protective policy.
- Granting every invited account member access to every Tenant’s retained history.
- Allowing an entire category to repair one client hostname.
- Assuming a DNS block replaces incident reporting or endpoint investigation.
Agency baseline questions
Should an agency block every newly registered domain?
Not by default. That may reduce exposure to some campaigns but can disrupt new client sites and legitimate services. Test the category, measure impact, and use it only where the risk and work pattern justify it.
Should contractors receive the same DNS policy as employees?
They should receive the enforced protections required for the Tenant work they perform. Separate endpoint or role-based resources can reflect different client tools, device ownership, and exception needs without weakening enforced policy.
What belongs in the first weekly DNS review?
Confirm endpoint coverage, examine blocked security categories and unresolved support reports, close obsolete exceptions, and test one safe known outcome. Aggregate counts should lead; detailed requests need a named reason.
Represent the baseline in Veilty
Apply reusable baseline and enforced policies to the Veilty Tenants that represent the agency’s teams, clients, or labs. A resource inside a Tenant may override baseline policy for a narrow work need, but it cannot override enforced policy. Invite collaborators to the account first; after acceptance, assign only the Tenant roles their work requires. Test one endpoint before expanding coverage.1
After the pilot, review aggregate outcomes and one documented support case. Keep retained Tenant activity available only to roles that need it and only for a useful period. Saved details are end-to-end encrypted with user-held keys, while the resolver still processes each live hostname to make the policy decision.