Malware and phishing defense
Start with maintained malware, phishing, scam, and other high-risk lists; discuss broader browsing categories before enabling them.
DNS filtering for teams, contractors, and labs
Protect work devices with clear DNS rules, then assign different filter or rule sets only where the job requires them. Veilty combines baseline and enforced Tenant policies, clear management roles, narrow exceptions, and private activity history for focused troubleshooting.
Metrics
Example DNS activity summary for a protected family or team network.
Team DNS controls for devices and Tenants
Reuse baseline and enforced policies across Tenants, assign filters or rules only where needs differ, and keep work devices on the team DNS setup away from the office.
Rules by device purpose
Separate finance, contractor, shared, guest, and lab devices only when their risks or required tools differ.
Tenants with clear roles
Create a separate Tenant for a department, client, or lab, then give account members access by assigning the roles they need.
Private support history
User-held keys protect retained DNS details and summaries, preserving useful support context without creating logs Veilty can read.
Hide a device’s IP from chosen sites
Use transparent proxying when a chosen site should see a Veilty exit address instead of the team device’s real IP.
Documented exception workflow
Tie each allowed site, blocked site, or location change to an owner, reason, and review date.
The first rollout should protect work, not interrupt it
A team DNS setup should make the workday safer without surprising people. Start with security categories and add broader categories only after explicit agreement.
When team DNS filtering is the right layer
DNS fits decisions about site access, baseline and enforced Tenant policies, assigned filters and rules, and narrow exceptions. It does not replace identity or device security.
Good DNS-fit problems
Choose Veilty for baseline and enforced Tenant policies, assigned filters and rules, transparent proxying, and recent activity details.
DNS is a good fit when a team wants a clear first layer for malware, phishing, scams, and known high-risk domains before deciding whether broader categories are appropriate.
Assign separate filter or rule sets when finance, contractor, guest, shared, and lab devices need different settings because their risk or workflow differs.
Recent site, device, action, and rule details can help support approve a narrow exception. Saved details and summaries stay encrypted until a member with access to that Tenant opens them.
Get early access for team DNS filtering
Join the wait list for team DNS filtering with baseline and enforced Tenant policies, assigned rules, narrow exceptions, transparent proxying, and private activity history.
100 Founders
The first 100 verified early access requests qualify for Founder access.
1,000 Families
The next 1,000 verified early access requests qualify for Family plan launch priority.
Wait list
Loading wait list details.
Top referrals
Loading referral ranking.
Email-only wait-list signups. Duplicate, self-referral, temporary, or spam entries may be removed from the wait list. Wait-list signups and account invitations are covered by the Wait List Terms and Privacy Policy.
DNS filtering for teams FAQ
Practical answers for teams that want useful DNS protection, support paths, and privacy-aware visibility.
Yes. DNS filtering can reduce risky domains and give a team a consistent device setup, but it should be treated as one security layer rather than a full security stack.
Usually no. A shared kiosk, founder laptop, finance device, developer workstation, guest device, and test device may need different filter or rule sets.
A Tenant keeps one team, client, or lab separate. It has its own members, roles, devices, and rules, and it does not sit inside another Tenant.
Invitations add people to the Veilty account. After they accept, assign one or more roles to give them access to a Tenant. An invitation does not grant Tenant access by itself.
The owner controls ownership and who can become an admin. Admins manage people, devices, and shared protection choices. Members can manage devices and see the shared setup. Viewers can read without changing it. These roles govern access to the Tenant and its retained activity.
Baseline and enforced policies are reusable across Tenants. Within a Tenant, resources added there may override its baseline policy. An enforced policy takes precedence and cannot be weakened by those resources.
DNS filtering blocks some risky sites, while updates, account protection, backups, device security, and user training cover other threats.
Retained history belongs to a Tenant. A member can review saved activity only for Tenants their assigned roles let them access; account membership alone does not expose every Tenant.
Veilty end-to-end encrypts saved activity details and summaries before storing them. Members open that history only for Tenants their assigned roles let them access.
Use recent activity to find the device, site, rule, and reason. Allow only the required site, record who approved the change, and review it later.
No. DNS filtering allows or blocks sites. Use a VPN or company access tool when people need a private connection to work systems or broader protection for device traffic.
Related team guides
Start with device policy, then compare VPN coverage and the risks of overly broad blocklists.