Microsoft cloud
M365 tenant
Microsoft 365 tenant
A Microsoft 365 tenant is the dedicated, logically isolated instance of Microsoft's cloud services that an organisation is provisioned when it signs up for Microsoft 365, identified by a unique tenant ID and one or more verified domain names.
Why M365 tenant matters in a Microsoft estate
M365 tenant matters because Microsoft 365, Azure, Windows 365, Teams, and related services are usually managed as one estate. The term connects to planning, cost, configuration, security, and day-two operational decisions across that estate.
How M365 tenant shows up in practice
It is the container inside which every user account, licence assignment, Microsoft Entra ID directory object, SharePoint site, Exchange Online mailbox, and Teams instance for that organisation lives, completely separated at the infrastructure level from every other customer's tenant, even though all tenants run on the same shared underlying Microsoft datacentre infrastructure. Every organisation using Microsoft 365, regardless of size, has exactly one primary tenant by default. Larger organisations, particularly those that have grown through acquisition, not infrequently end up managing multiple tenants, either deliberately for regulatory, data-residency, or organisational separation reasons, or simply as an unmanaged byproduct of an acquired company's existing tenant never being consolidated into the parent's.
Multi-tenant sprawl of the unmanaged kind is a genuine governance and cost problem, since licensing, security policy, and Conditional Access all have to be independently configured and audited per tenant rather than once centrally. The tenant is also the unit at which nearly all administrative and security configuration is scoped: Conditional Access policies, Data Loss Prevention rules, retention policies, and the vast majority of settings configured in the Microsoft 365 admin centre, Entra admin center, and Purview compliance portal apply tenant-wide by default unless deliberately scoped down to specific groups. That is why a single misconfigured tenant-wide policy can have an outsized organisation-wide impact compared to a per-user or per-group mistake.
Cross-tenant collaboration, where users from one organisation's tenant need controlled access into another's, whether through Teams guest access, B2B collaboration invitations, or B2B direct connect, is governed by cross-tenant access settings that let an administrator define, tenant by tenant, exactly what inbound and outbound trust and access is permitted. Getting these settings wrong is a recurring source of either unwanted external exposure or blocked legitimate collaboration between partner organisations. For licence and cost governance specifically, the tenant is the natural unit of audit: because every licence purchase, every user assignment, and every service configuration is scoped to a specific tenant, any serious Microsoft 365 licence reclaim or cost optimisation exercise starts by establishing a complete and accurate inventory at the tenant level, including confirming how many tenants an organisation actually operates, before any per-user or per-licence analysis can be considered reliable.