How to Fix a False Positive Without Disabling the Whole Filter

Fix a false positive safely by reproducing the failed task, identifying the exact hostname and matched policy action, and changing only the smallest scope proven wrong. Prefer a resource-specific baseline override or precise domain correction over disabling a filter or allowing a broad category. Retest both the restored task and an expected block, then record an owner and review date.

A false positive is not simply “something is blocked.” It is a policy outcome that prevents a legitimate, expected task. Preserve that distinction. A login page may appear while its identity provider is blocked, or an app may open while a required API hostname fails. Define the task before touching the rule so the repair has a measurable finish line.

Freeze the failure before editing policy

Capture the smallest reproducible case while the failure still exists. Record the affected resource, browser or app, network, exact task, local time with timezone, and visible error. Write the expected result in plain language, such as “the employee can complete vendor sign-in,” rather than “the website works.” A five-minute window is easier to correlate than an entire day of activity.

1. Repeat the task once from the affected resource without changing its network or settings.
2. Confirm the intended resolver received a fresh query during the recorded window.
3. Note whether the observed action was allow, block, redirect, or log-only.
4. Run the same task from one known-good comparison only when that comparison is genuinely equivalent.
5. Preserve screenshots or event identifiers needed to explain the decision, not unrelated browsing detail.

Do not clear every cache, disable every list, or switch networks before capturing this evidence. Those moves can restore access while erasing the contrast that reveals the cause. If no fresh lookup reaches the expected resolver, investigate cache, an open connection, browser Secure DNS, VPN DNS, or another resolver path before blaming policy.

Find the domain that actually gates the task

Start with the hostname the user entered, then follow the required journey. Authentication, application APIs, file delivery, payments, and media often use different domains. Compare the failing attempt with a successful one and identify which blocked hostname appears at the moment the necessary function stops. Do not allow every hostname requested by the page merely because it is nearby.

DNS observations require restraint. RFC 9076 explains that lookups can arise from applications, advertisements, prefetching, and background activity as well as intentional visits.² A blocked row establishes that a device requested a domain and received an outcome; it does not establish why the request occurred or whether allowing it restores the task. Test that causal link directly.

Avoid broad shared infrastructure exceptions. Content delivery, identity, and cloud hosting domains may serve many unrelated products. Prefer a documented vendor hostname or the most specific verified domain supported by the policy model. If the legitimate and unwanted content share one domain, DNS cannot separate them by page, path, account, or content type.

Read the winning action, not the rule list

A configuration screen may show several plausible causes: a custom domain rule, a catalog or filter-list entry, baseline policy, enforced policy, or a redirect. The useful evidence is the action that actually won for this query and resource. Record its source, priority, scope, and answer. A newly created allow rule is irrelevant if a higher enforced rule correctly remains authoritative.

Check domain shape carefully. A rule for a parent name may or may not cover subdomains according to the product's documented matching semantics. A redirect target may be blocked even when the original name is allowed. A category entry can also change independently of a custom rule. Diagnose the resolver's effective result rather than assuming the most recently edited object must be responsible.

Choose the smallest unblocking lever

Match the correction to the cause. Correct a mistaken exact-domain rule; exclude one proven hostname from a filter match; attach the intended profile to the affected resource; or create a permitted resource override when baseline policy is too broad for that resource. If enforced policy is wrong, change it through its owner and review process. A lower scope cannot legitimately cancel it.

• Keep the exception to one verified domain rather than a category, wildcard, or shared service.
• Keep it on one resource or profile when the need is not shared by the whole Space or Tenant.
• Write the legitimate task, approver, evidence, and condition that ends the exception.
• Avoid copying the same workaround across scopes; promote a durable shared need only after review.

DNS filtering can allow, block, redirect, or otherwise act on domain lookups. It cannot inspect page contents, full URLs, search terms, in-app chats, voice audio, or full browser history. If the needed distinction is between two pages or accounts on the same hostname, use an application, browser, endpoint, or access-control layer that can observe that distinction.

Prove the fix on both sides

Retest the complete legitimate task from a clean session on the original resource and network. Confirm a fresh query reaches the intended resolver, the corrected action matches, and the user can finish the workflow. DNS answers can remain cached for their time to live, so account for normal cache reuse instead of repeatedly editing a correct rule.¹

Then test one representative domain that should remain blocked and one ordinary allowed workflow. This catches an exception that is technically narrow in configuration but broad in effect. Close the incident with the original symptom, winning rule, exact change, before-and-after evidence, protection check, owner, and review date. The record should let another helper understand the fix without reopening general activity.

False-positive decision questions

Is a broad allowlist a reasonable temporary fix?

Usually not. A broad allow can restore the visible task while quietly admitting unrelated domains and hiding the original match. If urgent access is necessary, use the narrowest verified hostname and resource scope available, name an owner, set a review condition, and retest the protection the exception might affect.

What if an enforced policy caused the false positive?

Do not try to defeat it with a local exception. Verify the hostname and business or household need, then ask the owner of the enforced Space or Tenant policy to correct that policy. Resource rules may override baseline policy when permitted, but they cannot weaken enforced policy.

Does one blocked DNS row prove which domain broke the page?

No. Pages and apps request many hostnames for content, identity, telemetry, and background work. Reproduce the exact task, compare a successful attempt, and change one candidate at a time. A DNS event proves a lookup and policy outcome, not the user's intent or the domain's functional role.

Make one scoped Veilty correction

In Veilty, keep household resources in a Space and team resources in a Tenant. Reusable baseline and enforced policies can be assigned to those boundaries; a resource may override baseline policy when permitted, but it cannot weaken enforced policy. Account invitations create membership only and grant no Space or Tenant access by themselves; after acceptance, an assigned scoped role governs controls and retained activity. Stored history belongs to its Space or Tenant, is end-to-end encrypted with user-held keys, and is visible only through permitted roles, while the resolver necessarily processes live DNS requests. Review one affected resource and short failure window, make the narrowest proven correction, and verify one restored task plus one expected block.