On July 28, Microsoft announced Domain Exclusion for Microsoft 365 Copilot, a new control that lets administrators prevent specific public websites from being used to ground answers in Microsoft 365 Copilot and Copilot Chat.
The feature fills a real governance gap. Until now, many organizations treated web grounding as a broad on-or-off decision. Domain Exclusion adds a middle path: keep current public-web context where it helps, while removing sources that conflict with company policy, compliance obligations, regional rules, or trusted-source standards.
It is useful—but narrower than its name can sound. A good rollout starts with a precise understanding of what the control does and does not do.
What Microsoft announced
When Copilot uses web grounding, it can draw on current public information to make a response more timely. Domain Exclusion lets an administrator define domains that Copilot should not use in those web-grounded responses.
- The control applies to Microsoft 365 Copilot and Copilot Chat web grounding
- Organizations can exclude up to 1,000 domains
- It is not enabled by default
- Microsoft currently provides a PowerShell script for configuration
- A Search Administrator or Global Administrator runs the configuration
- The script can create, update, export, delete, and template an exclusion list using CSV data
This is an exclusion list, not an allowlist. Domains not on the list remain eligible for web grounding if web search is otherwise available.
What Domain Exclusion does not control
Do not treat the feature as a complete web or AI security boundary. It does not:
- Block a user from visiting a website in Edge, Chrome, or another browser
- Replace DNS filtering, secure web gateways, endpoint controls, or firewall policy
- Remove information already stored in SharePoint, OneDrive, Teams, email, or other connected business data
- Correct weak Microsoft 365 permissions or prevent overshared internal content from grounding a response
- Guarantee that every Copilot answer is accurate, complete, or appropriate for a business decision
- Create an approved-source-only model; it removes named domains rather than limiting Copilot to a closed list
Think of Domain Exclusion as one policy layer in a broader Copilot governance design. It shapes public-web influence. Identity, permissions, data protection, user training, and human review still carry most of the risk.
When excluding a domain makes sense
A useful exclusion should have a defensible reason. Common categories include:
- Compliance conflicts: sources the organization is prohibited from using in regulated research or client work
- Known low-quality content: domains with persistent misinformation, scraped material, or unreliable attribution
- Brand safety: sites whose content or ownership creates a documented reputational concern
- Regional restrictions: sources that do not align with geographic or contractual data-use requirements
- Conflict-of-interest policy: sources barred from a specific professional workflow
“We do not like this publisher” is not a sustainable governance rule. Every exclusion should have an owner, rationale, approval date, and review date.
Do not overbuild the list
A 1,000-domain capacity is not a target. Large lists create maintenance work and unintended blind spots. They also encourage teams to mistake source removal for factual validation.
Start with a short, high-confidence list tied to written policy. Before adding a domain, ask:
- What specific risk are we reducing?
- Does another control already address it better?
- Could excluding this domain remove legitimate primary-source material?
- Who will reassess the decision when ownership or content changes?
- How will users know a policy may be narrowing their web-grounded result?
A practical deployment plan
1. Confirm the business objective
Decide whether the organization needs targeted exclusions, a broader web-search restriction, or no change. Domain Exclusion is strongest when a small number of known domains cause a documented issue.
2. Establish ownership
AI governance, compliance, legal, information security, and the Microsoft 365 service owner should agree on who can request and approve changes. Do not leave the list to one administrator without policy oversight.
3. Build a controlled CSV
Use Microsoft’s template and keep a working record with:
- Domain
- Reason for exclusion
- Policy or risk reference
- Approver and implementation date
- Review or expiration date
4. Configure with least privilege
Microsoft’s script requires a Search Administrator or Global Administrator. Prefer the narrower role where it supports the task, use a controlled admin workstation, and retain the exported configuration as evidence of what changed.
5. Test realistic prompts
Test before and after behavior using prompts that previously drew from the domain. Check citations, answer quality, alternative sources, and whether users receive a clear indication that administrator policy may restrict sources.
6. Communicate the limitation
Tell users that exclusions may shape web-grounded answers. They still need to review citations and use approved primary sources for consequential work. A hidden policy with no user context can look like an incomplete or inexplicably biased result.
7. Review quarterly
Domains change ownership, quality, and purpose. Revalidate the list at least quarterly and remove exclusions that no longer serve a documented objective.
How this fits with other Copilot controls
A mature Microsoft 365 Copilot program uses several complementary layers:
- Web search policy: determine whether web grounding is available at all
- Domain Exclusion: remove specific external domains from web grounding
- SharePoint and Teams governance: reduce oversharing and stale internal content
- Purview controls: apply sensitivity labels, retention, and data loss prevention where licensed and appropriate
- Identity and device controls: ensure the person asking Copilot is properly authenticated and authorized
- Human-review rules: define which outputs require verification before external use or business action
The quality of Copilot governance depends more on how these layers work together than on any single switch.
Recommended policy language
A concise internal standard can read:
Copilot may use public web sources when enabled. IT may exclude domains that conflict with documented legal, compliance, security, or quality requirements. Domain exclusions do not validate remaining sources. Users must review citations and verify consequential outputs against approved primary sources.
Frequently Asked Questions
Does Domain Exclusion turn off web search? No. It is a targeted control. Microsoft provides a separate policy for managing public web access more broadly.
How many domains can we exclude? Microsoft says up to 1,000.
Is it automatic? No. An administrator must configure it using Microsoft’s PowerShell script.
Does it block employees from visiting those sites? No. It is not a browser or network filtering tool.
Should we exclude every questionable site we find? Usually not. Start with a small, policy-backed list and review it regularly.
Need a practical Copilot governance baseline?
We can map web grounding, permissions, Purview controls, model access, and human-review rules into one Microsoft 365 Copilot policy your admins can operate.
Book a Free Consultation