Verify your email domain

Prove your organization owns its email domain with one DNS TXT record, and unlock SAML sign-in and SCIM provisioning for that domain.

Verifying a domain proves your organization controls it. Until you do, single sign-on and SCIM will not work for anybody on that domain, no matter how correctly they are configured.

Prerequisites: you are an admin of the workspace, the workspace is on Enterprise, and the workspace has an email domain set. The email domain is set when you activate Enterprise.

Why a DNS record rather than a checkbox

The domain is what binds an identity provider's assertions to your workspace: a verified domain is what lets Dashies accept "this person is someone@yourco.com" from your IdP and turn it into a Dashies session.

An unverified claim would therefore be an account-takeover primitive. Any workspace admin could type in another company's domain and start minting sessions for its employees. Proving control of the DNS is what makes that impossible. The full model is in How Dashies protects your account.

Add the record

Open Settings, switch into the workspace, and open its Security section. The Verify domain ownership card shows the exact token with a Copy button. Add it to your DNS as a TXT record:

Field	Value
Type	`TXT`
Name / host	the email domain itself, with no prefix. Most DNS panels write this as `@`.
Value	`dashies-domain-verification=` followed by the workspace id, exactly as the card shows it

Two things people get wrong here:

There is no _dashies subdomain. The record goes on the apex of the email domain, so for acme.com the record is on acme.com, not on _dashies.acme.com.
The domain is your email domain, not your dashboard subdomain. If your people sign in as name@acme.com, the record belongs on acme.com, whatever your workspace slug is.

The token is matched case-insensitively and only has to be contained in the record, so a DNS panel that upper-cases the value, or a provider that appends its own text, still verifies.

Check it

Click Check now on the same card.

Dashies resolves the record over public DNS rather than asking your authoritative nameserver directly, so a record you just saved may not be visible yet. If the check fails immediately after you add the record, wait and retry rather than editing it.

Failures come back as short codes:

Code	What it means	What to do
`txt_record_not_found`	DNS answered, but nothing matched. The card lists the records it did see, up to five.	Compare the listed records against the token. If yours is not listed at all, it has not propagated yet.
`dns_lookup_failed`	The DNS lookup itself did not complete.	Retry. If it persists, check the domain resolves at all.
`domain_already_verified_by_another_workspace`	Another workspace has already verified this domain.	A domain can be verified by exactly one workspace. Find the other workspace and release the domain there first.
`db_update_failed`	The record matched but the result could not be saved.	Retry. The check is safe to repeat.

There is no "verified" badge

This surprises people. When verification succeeds, the Verify domain ownership card and the Domain unverified warning both disappear, and that absence is the whole confirmation. The one positive record is a line in the audit log reading "verified yourco.com".

What a verified domain does

Exactly four things, all of them about identity:

SAML sign-in started from Dashies works for that domain. Without verification, users get "No SSO is configured for that domain".
SAML sign-in started from your IdP works. Without verification, it fails silently and drops the user on the sign-in page.
SCIM events are processed. Without verification, they are rejected and your IdP stops retrying, so joiners and leavers silently stop syncing.
SCIM credentials can be generated at all. The button refuses with "verify your domain before configuring SCIM".

And what it deliberately does not do, because people assume otherwise:

It does not auto-join anyone. Someone signing up with a matching email address does not land in your workspace. They join by invitation, by SCIM, or by signing in through your IdP.
It does not restrict who you can invite. You can still invite people on any domain.
It does not affect dashboard visibility, URLs, or your workspace subdomain.

Changing or releasing the domain

Changing the email domain silently un-verifies it

Editing a workspace's email domain resets its verification, automatically and without a warning. SSO sign-in and SCIM stop working for everyone at that moment, and stay broken until you verify the new domain.

If you are migrating to a new domain, plan for a gap and verify the new one promptly.

Releasing a domain frees it for another workspace to claim and verify. The button lives in the workspace's Security section and is disabled while SSO is connected, with the note "Connected to single sign-on. Disconnect SSO to release this domain."

Disconnecting SSO is not self-serve today

There is no button in the app that disconnects SSO once it is connected. That means releasing the domain and deleting the workspace are both blocked from the moment you connect SAML, and you will need support to undo either.

If you are experimenting with SSO, do it on a workspace you are willing to keep.

Check it worked

The card is gone. Reload the workspace's Security section. The "Verify domain ownership" card and the "Domain unverified" pill should both have disappeared.
The audit log recorded it. The same section's audit log should show "verified yourco.com". This is the only affirmative record.
Sign-in actually resolves the domain. Sign out, open the sign-in page, enter an address on the verified domain and click Sign in with SSO. If SSO is already connected you get redirected to your IdP. If you have not connected SAML yet, "No SSO is configured for that domain" is the expected answer at this stage and means verification is not what is missing.