Skip to main content

Verified Sign-in Domains

If your organization owns more than one email domain, for example acme.com and acme.io, you can use all of them with a single TridentStack Control workspace. Once a domain is verified, someone signing in with an email address on that domain is recognized as part of your organization instead of starting a separate one.

This is useful for organizations that grew through a rebrand, a regional TLD, an acquisition, or simply register mail on more than one domain.

What verifying a domain does​

Verifying a domain changes one thing: where sign-ins from that domain are routed. A verified domain is recognized as part of your organization, so someone signing in with an email on it joins your workspace instead of starting a new, separate one.

Verifying a domain does not open your workspace to everyone on that domain. Access is controlled exactly as it is for any other new person:

  • Anyone signing in from a verified domain lands in the pending-approval queue, and an admin approves them before they can use TridentStack Control.
  • You can invite people on any of your verified domains from your user management settings. You cannot invite someone on a domain you have not verified.

Automatic verification through Microsoft​

If your team signs in with Microsoft work accounts, adding another domain usually requires no action from you.

When someone signs in with a Microsoft work account whose sign-in name is on another domain your Microsoft organization owns, for example [email protected], TridentStack Control recognizes that the domain belongs to the same Microsoft organization as a domain you have already verified, and adds and verifies it automatically. There is no DNS record to add and no button to click. This works because your workspace is tied to your Microsoft organization the first time anyone from your primary domain signs in with a Microsoft work account.

As always, that sign-in verifies the domain, not the person: whoever signs in still waits for admin approval before they can use TridentStack Control.

Adding a domain manually​

If your team does not use Microsoft accounts to sign in, or you want to verify a domain before anyone signs in with it, you can add and verify it manually with a DNS record.

  1. Go to Settings -> Authentication -> Sign-in domains.
  2. Click Add domain and enter the domain, for example acme.io.
  3. TridentStack Control shows you a DNS TXT record to create:
    • Host: _tridentstack.acme.io
    • Value: a unique verification token, for example tridentstack-verify=abc123...
  4. Add that TXT record in your DNS provider's control panel.
  5. DNS changes can take up to an hour to propagate, depending on your provider and existing DNS settings.
  6. Back in TridentStack Control, click Verify. Once the TXT record is found, the domain is marked verified and ready to use.

If verification fails, double-check the host and value were entered exactly as shown, then wait a little longer for DNS to propagate before trying again.

Controlling sign-in methods per domain​

Every sign-in domain in your organization, including your primary domain, has its own card in Settings -> Authentication -> Sign-in domains with independent controls for which sign-in methods it allows. Each domain is configured the same way, in one place, so you can allow different domains to sign in different ways. For example, your primary domain might allow Microsoft, Google, and an email code, while a secondary domain is restricted to Microsoft only.

Open a domain's card and use the toggle next to each sign-in method to choose which ones are allowed for that domain. Only methods you have configured for your organization, such as specific OAuth providers, are available to turn on. At least one sign-in method must stay enabled for every domain, so the last remaining method cannot be turned off.

Single sign-on stays a separate, organization-wide setting under Settings -> Authentication -> SAML Single Sign-On and is not configured per domain.

Disabling a domain​

You can disable a verified domain at any time from the same Sign-in domains list.

Disabling a domain stops future sign-ins from that domain from resolving to your organization. Existing users who already have accounts keep them and are not affected, but new sign-in attempts from that domain are no longer recognized as belonging to your workspace.

You can re-enable a disabled domain later, which restores it to normal behavior.

Troubleshooting​

"This domain is already in use by another organization"

Each domain can be verified by only one TridentStack Control organization at a time. If you see this message while trying to add a domain, it means the domain is already claimed elsewhere, most commonly because it was verified by a different workspace.

If you believe this is an error, for example the domain should belong to your organization and you do not recognize the other workspace, contact TridentStack support.

A coworker on an added domain is asked to be invited

Automatic sign-in for a coworker works when the domain on their email address matches the domain on their Microsoft sign-in name. Some organizations set these to different domains: the email address is on one domain, for example a brand domain, while the Microsoft sign-in name is on the primary domain. When they differ, TridentStack Control asks that coworker to be invited before they can join, so that no one outside your organization can slip in. Invite them from your user management settings, and they can sign in normally.