DomainsCopy Anchor Link

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 AchieveCopy Anchor Link

From Domain Strings to Known OrganizationsCopy Anchor Link

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 organization's domains, kept out of the default view. On a multi-tenant dashboard this covers every connected tenant, so a sibling tenant never shows up as an external counterparty.

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 ControlsCopy Anchor Link

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 FiltersCopy Anchor Link

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. Registry chips sit alongside: Re-registered after first contact, Ownership changed (90 days), Registered under 30 days and Age unknown.

The Domain ListCopy Anchor Link

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.

Known since is the earliest dated evidence of the counterparty we hold - the first email, guest account or shared file - and reads as "known since at least": it cannot be older than the data we scanned. It is different from Discovered, which is only when 1Security first saw the domain. The New in last 30 days chip and the New relationship policy field use Known since.

Click any domain to open the full picture.

The DrawerCopy Anchor Link

• Insights - the organization's Entra identity, the relationship rollups, and the timeline.
• Registry - what the public domain registry says about the name: when it was registered, who holds it, who runs its DNS, when it expires, and a timeline of registry events and the ownership changes 1Security has observed, next to your own milestones (first contact, verdict changes). A Refresh now button queues a re-check.
• 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.

Registry: Age, Ownership and ExpiryCopy Anchor Link

Three clocks sit on every external domain, each from a different source:

• Registered - the start of the current registration, read from the public registry (RDAP, with WHOIS as the fallback for registries that have no RDAP service). A re-registration resets this clock; the earlier date is kept in the timeline.
• Owned since - the latest of the registration, a registry-published transfer, and an ownership change 1Security observed between two of its own snapshots (registrar, registrant organization or nameserver operator changed).
• Known since - the earliest dated evidence you hold (see the Domain List above).

The flags derived from them follow Cloudflare's own domain-age labelling, so you can cross-reference them with your mail filter: Registered under 30 days, Re-registered after first contact (the registration is younger than your relationship - the name was dropped and taken by someone else while you were still dealing with it), Ownership changed (90 days), Expires within 30 days, Lapsed (expiry passed or the registry shows a redemption or pending-delete status) and Age unknown.

Age unknown is an honest state, not an absence of a problem: some registries never publish registration dates (DENIC for .de and SWITCH for .ch among them, and several registries without RDAP hide them in WHOIS too). Those domains appear with the flag and their own quick filter so they can be reviewed by hand.

The dangerous combinations open incidents on the Anomalies screen under Domain registry risk: a re-registered domain that still has guests, files or recent mail; an ownership change on a domain you trust; a domain under 30 days old that already holds guests, files or sensitive mail; and a trusted domain whose registration lapsed. Setting the verdict to Blocked resolves the incident; so does the condition going away.

Registry data is public and identical for every tenant, so 1Security keeps one shared record per domain name and refreshes it on a schedule (weekly for young or soon-expiring names, monthly or quarterly otherwise). Person names and contact details are never stored - only the organization, country, registrar, nameservers, dates and status codes. Self-hosted deployments need outbound HTTPS to the registries' RDAP hosts and TCP port 43 for WHOIS; without port 43 the affected TLDs simply show as not supported.

When the server cannot reach the registries at all, nothing breaks: the fetcher checks its own egress before every run and pauses instead of recording failures, and the Domains screen shows an onboarding step that lists the exact hosts and ports to allow, with a Test again button that re-runs the check on demand. Once the path is open the waiting names are looked up on the next run. Self-hosted installs find the same table in the deployment guide (section 5.5a, outbound network access for domain registry lookups).

Blocking a DomainCopy Anchor Link

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.

PermissionsCopy Anchor Link

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.