Microsoft has pulled Domain Exclusion for Microsoft 365 Copilot shortly after its rollout began, removing a tenant-level control that allowed administrators to keep named websites out of Copilot’s web-grounded answers. For organizations that had started building exclusion lists, the immediate operational conclusion is simple: treat domain-level web-source filtering as unavailable and do not assume a previously configured blocklist is still protecting Copilot responses. WindowsReport first reported the reversal on August 5, saying Microsoft stopped the release, removed the capability from tenants that had already received it, and is reviewing what to do next. Microsoft has not published a public technical explanation for the withdrawal. The company’s earlier Message Center announcement, MC1411435, had described the feature as generally available worldwide beginning in mid-July 2026, with a PowerShell configuration script scheduled for July 16.
That is a sharp change from the rollout plan. Domain Exclusion was not a cosmetic setting: it was intended to let IT teams specify as many as 1,000 external domains that Microsoft 365 Copilot and Copilot Chat should not use when grounding answers with public web results. The feature was off by default and required an administrator to run Microsoft’s script, so it would not have changed any tenant’s behavior unless IT actively configured it.
The missing public explanation leaves administrators with an uncomfortable gap. Microsoft has withdrawn a control positioned as a compliance and content-governance safeguard, but has not said whether the issue involved enforcement, configuration, scope, auditing, rollout reliability, or something else entirely. Until that is clarified, a domain entered into an old exclusion file should be treated as documentation of intent, not evidence that Copilot is still avoiding it.

Analysts monitor global data dashboards and cybersecurity metrics in a high-tech operations center.MC1411435 promised a narrow but useful control​

The original announcement was specific about what Domain Exclusion was supposed to do. It applied to web grounding in Microsoft 365 Copilot and Copilot Chat, where Copilot uses Bing web search to bring current public information into a response. Administrators could name external domains to prevent those sites from being used as grounding sources.
This was distinct from blocking access to websites on the network. Microsoft’s existing Copilot management documentation expressly warns against trying to manage Copilot through selective domain, URL, IP-address, or protocol blocking at the network layer, saying those restrictions can cause unpredictable failures because Copilot is integrated across Microsoft 365 applications. Domain Exclusion was meant to be an in-service control: it governed sources after Copilot decided web search was appropriate, rather than trying to break the service’s connectivity.
Microsoft’s privacy documentation also explains why that distinction matters. In a web-grounded request, Microsoft 365 Copilot derives a search query from the user’s prompt and sends that query to Bing Search. The full prompt is not necessarily sent as the search query, but the answer can be grounded in external material returned from the web. The resulting Copilot interaction, including citations used to ground the answer, is stored under the organization’s Microsoft 365 commitments and can be subject to Purview, retention, and content-search controls.
Domain Exclusion therefore addressed a different problem from data-loss prevention, sensitivity labels, access permissions, or web filtering. It was a source-selection control. A tenant might allow web grounding broadly but exclude known misinformation sites, unapproved vendors, competitor domains, unofficial product-support sites, or publications that do not meet internal research standards.
That makes the withdrawal more consequential than the loss of a minor admin-center toggle. Organizations that adopted Copilot on the assumption that public-web grounding could be bounded at the source level have lost the one announced mechanism designed for that purpose.

A blocklist is not a trusted-source policy​

The feature also had an important limitation that Microsoft’s announcement did not solve: it was a blocklist, not an allowlist. Administrators would have had to predict and maintain the external domains they did not want Copilot to cite.
That works for obvious cases. A security team can identify known malicious, unreliable, impersonating, or policy-prohibited sites. A legal or regulated organization can list a defined set of sources whose use would be inappropriate. But the public web is much larger than any 1,000-entry list, and a list of excluded domains says little about the trustworthiness of everything left outside it.
For many enterprises, the more defensible policy is the reverse: permit a short, curated list of sources for a defined task, and reject the rest. A financial-services team may want research grounded in a regulator, a market operator, and selected filings. A pharmaceutical team may prefer specific health authorities and peer-reviewed publishers. An IT operations team may want vendor documentation, advisories, and a limited set of incident-status services.
Domain Exclusion could never provide that model. Blocking 1,000 domains is useful hygiene, but it does not turn web grounding into a controlled research environment. It only reduces known bad or unwanted inputs.
Microsoft has other controls that work closer to an allowlist concept, but they do not replace Domain Exclusion. The company has been adding ways to designate SharePoint Online sites as authoritative sources for Copilot Search, for example. Those settings can improve the visibility and ranking of internal content. They do not establish that Copilot web grounding will only use an approved set of public internet sources.
The consequence is that tenants which need a provable external-source policy should not rely on standard web-grounded Copilot responses for that workflow. They need either to disable web search for the relevant scope, use a controlled internal knowledge base, or build a governed agent or retrieval process that explicitly limits its external corpus.

The surviving control is much broader than the one Microsoft removed​

Microsoft’s current documented control for web grounding is the Allow web search in Copilot policy. That setting can be managed at the tenant level and, depending on configuration, for groups or users. It offers a binary governance choice: permit web search or turn it off.
If web search is disabled, Microsoft says Copilot Chat does not send web queries to Bing and instead responds using the underlying large language model. That prevents fresh external web retrieval, but it also removes the benefit administrators were trying to preserve: responses informed by current public information.
In other words, organizations have moved from a proposed middle position—web grounding with selected exclusions—to a far coarser choice:
  • Enable web search and accept that Copilot may draw from public sources without the withdrawn domain-specific guardrail.
  • Disable web search and lose current public-web grounding, while retaining Copilot’s internal and model-based capabilities where available.
For tenants in GCC and Department of Defense environments, Microsoft documents a different default: web search is off unless the administrator configures the policy. That offers a more conservative baseline, but it does not supply selective source control either.
This is the practical point many rollout documents miss. “Web search enabled” is not merely a user-experience setting. It is a governance decision about whether a work assistant can retrieve and synthesize internet material in answers that may later be reused in email, documents, presentations, customer communications, or internal decision-making.

Microsoft’s public record now obscures the status of Roadmap ID 503144​

The official record is unusually thin for a feature that Microsoft had announced as generally available. Roadmap ID 503144 was associated with Domain Exclusion, but the item is no longer visible on Microsoft’s public roadmap. Microsoft’s roadmap itself says entries are removed once a feature becomes generally available, is cancelled, or is postponed.
That policy makes a missing roadmap item evidence of very little on its own. It cannot distinguish a completed launch from a cancellation or a pause. In this case, however, the missing roadmap entry sits alongside WindowsReport’s account that Microsoft withdrew the feature and removed access from tenants that already had it.
The more useful evidence is what cannot now be found: a live Microsoft Learn page for the announced Domain Exclusion setup process, a public replacement configuration script, a revised launch date, or a public explanation of the rollback. Microsoft’s normal Copilot management documentation continues to describe tenant and group controls for allowing or disabling web search, but not an active domain-exclusion configuration.
Administrators should preserve any copies of the MC1411435 announcement, rollout notes, and proposed domain lists. Those records can be useful in internal risk reviews, especially if a Copilot deployment was approved on the premise that undesirable sources could be excluded. But they should not be treated as operating documentation while the feature remains withdrawn.

What IT teams should do while the feature is absent​

The immediate task is to verify present behavior rather than rely on what was announced in July. Review the Copilot Control System and Cloud Policy settings for web search, identify which users and groups can use web-grounded Copilot, and decide whether those scopes remain appropriate without source-specific exclusions.
Teams that had prepared a domain list should convert it into a risk register. Categorize entries by reason for exclusion: security, legal, compliance, misinformation, competitor intelligence, offensive content, or relevance. That work will still be valuable if Microsoft relaunches Domain Exclusion, and it will expose whether the business really needs an exclusion list or a smaller trusted-source design.
For sensitive workflows, document the temporary control decision clearly. If web grounding remains enabled, tell users that Copilot citations must be reviewed and that an answer’s citations are not an organizational endorsement of every source used. If web grounding is disabled, explain the trade-off: Copilot will no longer retrieve current public-web information for those users or workloads.
Microsoft has not said whether Domain Exclusion will return, whether the 1,000-domain limit will change, or whether an allowlist model is under consideration. Until it does, the safest assumption is that Microsoft 365 Copilot can either search the web under broad policy controls or not search it at all; the promised layer between those choices has been removed.

References​

  1. Primary source: Windows Report
    Published: 2026-08-05T11:26:41+00:00
  2. Related coverage: techcommunity.microsoft.com
  3. Related coverage: learn.microsoft.com
  4. Related coverage: support.microsoft.com
  5. Related coverage: learn.microsoft.com
  6. Related coverage: support.microsoft.com
  7. Related coverage: microsoft.com
  8. Related coverage: microsoftpartners.microsoft.com
  9. Related coverage: techcommunity.microsoft.com
  10. Related coverage: microsoft.com
  11. Related coverage: techriver.com
  12. Related coverage: windowscentral.com
  13. Related coverage: windowscentral.com
  14. Related coverage: tomshardware.com
  15. Related coverage: tomshardware.com
  16. Related coverage: m365admin.handsontek.net
  17. Related coverage: myabt.com
  18. Related coverage: linkedin.com
  19. Related coverage: windowsforum.com
  20. Related coverage: certcompanion.com
  21. Related coverage: microsoft.github.io
  22. Related coverage: assets.gname.com
  23. Related coverage: docs.oracle.com
  24. Related coverage: pieterkops.nl
  25. Related coverage: docs.oracle.com