Skip to main content

​
Claiming an email domain

Verified domains define who your identity provider may sign in, create or reactivate: SSO sign-in, just-in-time provisioning and SCIM creation/reactivation require an email on one of these domains. SCIM can still update or deactivate existing invited guests outside these domains; deactivation can archive their assets. Verified domains also power the Continue with SSO button: a member enters their email on the login page, Empiric Intelligence matches the domain to your workspace, and redirects to your IdP.
1

Claim

In the workspace console open Workspace, then Security, and add your domain (for example acme.com). Public email domains (gmail.com, outlook.com, and similar) cannot be claimed.
2

Add the DNS TXT record

The page shows a record host and record value for a DNS TXT challenge. Create that record at your DNS provider.
3

Verify

Click Verify. Distinct failure states (record not found, value mismatch, lookup failed) are reported so you can tell propagation delay from a typo. Once verified, the domain routes sign-ins to your connection.
A domain can be verified by one workspace globally. If verification reports the domain as already owned by another organization and you believe it is yours, contact Empiric Intelligence support. Some domains are reserved and cannot be claimed or verified by a customer workspace; if one of yours is refused this way, contact support too.

​
Enforcing SSO

Enforcement refuses password sign-in for every member whose email is on one of your verified domains; they must come through your IdP. Members whose email is outside those domains (invited guests, such as contractors or your Empiric Intelligence contact) keep password sign-in. Before you can turn it on:
  • At least one domain is verified (the connection cannot be enabled without one).
  • The connection must be enabled.
  • You must have signed in through this SSO connection at least once, so your own email must be on one of your verified domains. This proves the connection works before it becomes the only door.
When you turn it on:
  • Every session of a member on your verified domains is revoked immediately; they sign in again through the IdP. Your own session survives, and guests outside those domains are unaffected.
  • Any later change to an IdP field (issuer, client ID or secret, SAML entity ID, sign-on URL, certificate, protocol) automatically drops enforcement in the same save, so a broken IdP config cannot lock the workspace out.
There is no self-service break-glass for members on your verified domains. If your IdP is misconfigured or unreachable and they cannot sign in, recovery is performed by Empiric Intelligence support. An owner or member whose email is outside your verified domains keeps password sign-in. Test the connection thoroughly before enforcing, and re-verify after every IdP-side change.
Changing your domains changes who enforcement covers, at once. Removing a verified domain turns its members into guests: single sign-on stops for them and they can use password reset again. Verifying a new domain on an enforced workspace signs out that domain’s members (your own session survives); they sign in again through your IdP.

​
Provisioning interplay

  • JIT only: a first SSO sign-in creates the member with the connection’s default role, only when their email is on one of your verified domains. Anyone else is invited.
  • With SCIM: your directory creates, updates, and deactivates members ahead of sign-in, for emails on your verified domains; JIT still fills any gap. See Directory sync.