Skip to main content

Domain Scopes

Domain scopes tell Surface Security which domains matter to your organization. They are the starting point for attack surface discovery: every domain you add here defines where Surface focuses its monitoring, which domains it treats as company-owned, and which external domains it tracks on your behalf.

A domain scope does not allow or block anything by itself. Think of it as a declaration of territory — "these domains are ours" and "these domains we care about" — that other parts of the platform build on. Enforcement decisions (allow, warn, block) are always made by security policies.

Screenshot

[SCREENSHOT PLACEHOLDER: The Domain Scopes page (Attack Surface > Domain Scopes) showing the four summary cards (Total Domains, Owned Domains, Tracked (External), Attack Surface Enabled) and a table with several owned and tracked domains]

How it works

Each domain scope is a single domain (for example example.com) with three switches that control how Surface treats it:

SettingEffect
Include subdomainsThe scope covers the domain and everything beneath it (shown as *.example.com with a +Subdomains badge). Without it, only the exact domain is covered.
OwnershipOwned marks the domain as company-owned or internal. Tracked (the default) marks it as an external domain you want visibility into, such as a partner portal or a vendor login page.
Attack SurfaceWhen Enabled, Surface aggregates every subdomain, endpoint, and authentication service it discovers under this domain into the Attack Surface view.

The ownership flag matters for detection quality:

  • Owned domains are treated as yours. Surface skips third-party reputation scanning for company-owned domains, so your internal sites are never submitted to external reputation services and never generate reputation-based noise. When Include subdomains is set, this applies to every subdomain as well.
  • Tracked (External) domains are monitored normally. They appear in your telemetry and attack surface data, but Surface does not treat them as company property.

Attack surface tracking is what feeds the Attack Surface page. If no domain scope has it enabled, the Attack Surface page stays empty and shows a prompt directing you back here. Once enabled, Surface builds a live map of subdomains, endpoints, and authentication services observed under that domain — a practical way to find shadow IT and forgotten login pages.

Using the page

Navigate to Attack Surface > Domain Scopes in the dashboard sidebar.

The page shows four summary cards — Total Domains, Owned Domains, Tracked (External), and Attack Surface Enabled — followed by the domain scopes table with the columns Domain, Ownership, Attack Surface, Notes, and Added.

Use the filter dropdown above the table to switch between All Domains, Owned, and Tracked (External).

Adding a domain

  1. Click Add Domain.
  2. Enter the domain name (for example example.com). If you type a leading wildcard such as *.example.com, Surface strips it automatically and uses the Include subdomains checkbox instead.
  3. Choose the options that apply:
    • Include subdomains (*.example.com) — checked by default.
    • This is an owned/internal domain — check for domains your organization controls.
    • Enable attack surface tracking — check to monitor and discover all subdomains, endpoints, and authentication services under this domain.
  4. Optionally add Notes (for example "Main corporate domain" or "Partner portal").
  5. Click Add Domain.
Screenshot

[SCREENSHOT PLACEHOLDER: The Add Domain dialog with a domain entered, "Include subdomains" and "This is an owned/internal domain" checked, and the "Enable attack surface tracking" option with its helper text visible]

Removing a domain

Click Remove on a table row and confirm. Removing a domain scope stops future discovery and monitoring focus for that domain, but historical data already collected is preserved.

Patterns and matching

Domain scopes deliberately keep matching simple:

  • A scope is one registered domain, entered without a scheme or path — example.com, not https://example.com/login.
  • Subdomain coverage is a checkbox, not a pattern language. With Include subdomains checked, example.com covers login.example.com, mail.corp.example.com, and so on.
  • There is no arbitrary wildcard or regular-expression support on this page. If you need pattern-based matching for enforcement (exact, wildcard, or regex domain rules), that lives in security policies, not in domain scopes.

Interaction with policies

Domain scopes and policies answer different questions:

  • Domain scopes answer "which domains does Surface pay attention to?" — discovery, attack surface mapping, and owned-versus-external classification.
  • Policies answer "what happens when a user interacts with a domain?" — allow, warn, or block actions on credential events, with their own domain matching rules.

A typical setup uses both: declare example.com as an owned scope so discovery and telemetry are anchored to it, then write policies that warn or block risky credential behavior on everything outside your owned domains. Policies are configured under Policy in the sidebar; see the Security Policies guide for rule structure and the "most restrictive wins" resolution logic.

If you also want Surface to actively defend a specific login page against cloning and lookalike domains, add it as a protected domain — that is a separate, stronger declaration than a domain scope.

Worked example

Suppose your organization is Acme Corp:

  1. Add acmecorp.com with Include subdomains, This is an owned/internal domain, and Enable attack surface tracking all checked. Notes: "Main corporate domain".
    • The Attack Surface page begins mapping every subdomain and authentication endpoint seen under acmecorp.com.
    • Reputation scanners skip acmecorp.com and its subdomains, since they are yours.
  2. Add acme-benefits-portal.com (your third-party benefits provider) with Include subdomains checked but ownership left as Tracked. Notes: "External HR/benefits vendor".
    • Surface keeps visibility into employee authentication against this vendor without treating it as company property.
  3. On the page, the summary cards now show 2 total domains, 1 owned, 1 tracked, and 1 with attack surface tracking enabled.

A month later, the Attack Surface view surfaces old-vpn.acmecorp.com — a forgotten VPN portal still accepting logins. That discovery started with the single domain scope you added in step 1.

Screenshot

[SCREENSHOT PLACEHOLDER: The Attack Surface page populated with discovered subdomains under an owned domain, illustrating what attack surface tracking produces]

Troubleshooting

The Attack Surface page says no domains are being tracked. At least one domain scope must have Enable attack surface tracking turned on. Edit or re-add the domain with that option checked.

I typed *.example.com and it saved as example.com. That is expected. Leading wildcards are stripped automatically; subdomain coverage is controlled by the Include subdomains checkbox, which was preserved.

I get "Please enter a valid domain name". Enter a bare domain such as example.com — no https://, no path, no port. Internationalized or single-label names that do not resolve to a valid domain format are rejected.

Does removing a scope delete my data? No. The confirmation dialog notes that historical data is preserved. Removing a scope only stops it from focusing future discovery and monitoring.

Should login pages I want to defend against phishing go here? Add them here for discovery, and also add them on the Protected Domains page. Protected domains get baseline fingerprinting and lookalike-domain alerting that domain scopes alone do not provide.