Domains

The Domains screen answers the question every other screen raises: "Do we actually know this organization?" A guest appears in a group, a file goes to an outside address, a vendor app shows up - each of those is a relationship with an external organization, and this screen is where those relationships become visible, get a name, and get a decision.

What You Can Achieve

From Domain Strings to Known Organizations

Every signal source in Microsoft 365 speaks the same key - the email domain - so that is the unit of the screen. But a string answers nothing on its own. 1Security resolves each observed domain against Microsoft Entra's tenant directory and classifies it:

• Known organization - the domain belongs to a real Entra tenant; you see its display name, its tenant identity, and its sibling domains.
• Freemail - gmail.com and its relatives. That access belongs to a person, not an organization - a different risk conversation entirely.
• Unrecognized - no Microsoft organization stands behind it: self-hosted mail, other clouds, or something worth a closer look.
• Internal - your own verified domains, kept out of the default view.

On top of that classification sits your verdict: unreviewed, trusted, watched, or blocked. The classification is what can be proven; the verdict is what your organization decides. Every verdict change is recorded - who, when, and why - so the trust ledger holds up in an audit.

Reconciling Microsoft's Trusted-Domain Controls

Microsoft ships several trusted-domain mechanisms - SharePoint and OneDrive sharing domain lists, guest-invitation restrictions, cross-tenant access partner settings. They live in different admin centers, use different keys, and never check each other. A domain "blocked" in one control can hold live guests, valid sharing links, and daily email flow through the others - and there is no Microsoft screen where that contradiction would ever appear.

1Security reads the controls it can reach - the tenant-wide SharePoint sharing lists, the cross-tenant access partner configuration, and (for tenants with the audit connection) the Defender Tenant Allow/Block List, the mail channel's own allow/block surface - and puts each domain's standing next to its observed reality. The contradictions become drift flags:

• Blocked but active - on a sharing or mail block list, yet guests or recent activity persist. Blocking never evicts access that already exists; this flag is where that surprise shows up.
• Trusted but unused - configured as trusted (verdict, allow list, or cross-tenant partner) with no activity for 90 days. Stale trust is attack surface nobody is using.
• Active but ungoverned - sensitive data flows to this domain and no control or verdict covers it. This is the review queue, ranked by what is actually leaving.
• Conflicting lists - tenant-level and site-level lists disagree about the same domain.

Each drift class ships as a ready-made detection template, so "blocked but active" raises an alert instead of waiting for someone to browse the list.

Quick Filters

The chip row above the list is the review workflow in miniature, each chip with a live count: Blocked but active and Active but ungoverned (the two drift classes worth immediate attention), Unreviewed (the verdict backlog), Sensitive data exposure, Unrecognized, Freemail, Has guests, Files shared, New in last 30 days, Blocked, and No activity in the last year.

The Domain List

Each row is one external organization: the domain with its resolved Entra name beneath it, its classification and verdict pills, a drift indicator, and the relationship in numbers - guest accounts, email correspondents, emails exchanged, files its people can reach, sensitivity exposure, and when the relationship began and was last active.

Click any domain to open the full picture.

The Drawer

• Insights - the organization's Entra identity, the relationship rollups, and the timeline.
• Posture - where this domain stands in every Microsoft control 1Security reads, the drift explained in plain words, your verdict with its note and history, and the block/unblock control.
• People - the guest accounts from this domain (both Entra B2B and SharePoint-only guests) and the email-only correspondents who exist in no directory at all.
• Files - everything this domain's guests can reach, ranked by sensitivity.
• Emails - the message flow with this domain, both directions.
• Activity - audit-log events performed by this domain's people.

Blocking a Domain

From the Posture tab you can block (or unblock) SharePoint and OneDrive sharing to a domain tenant-wide. 1Security edits your tenant's own sharing domain lists through Microsoft's API, working within whatever restriction mode you already run - it appends to your block list, or removes from your allow list, and never flips the mode itself behind your back.

Permissions

Discovery, rollups, and verdicts work from data 1Security already collects - no extra permissions. Three optional read permissions light up the rest: CrossTenantInformation.ReadBasic.All (resolving domains to Entra organizations), SharePointTenantSettings.Read.All (the tenant-wide sharing lists), and Policy.Read.All (cross-tenant access partners). Blocking a domain additionally needs the SharePointTenantSettings write permission. The Defender Tenant Allow/Block List rides the audit app's Exchange Online connection - if audit logs are connected, the mail lists come along with no extra permission. Everything degrades gracefully: a missing permission is shown as exactly that, never as an empty screen.