--- title: Verify your email domain description: Prove your organization owns its email domain with one DNS TXT record, and unlock SAML sign-in and SCIM provisioning for that domain. updated: 2026-08-05 tier: enterprise --- 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](/admin/billing#enterprise-on-a-workspace). :::note{title="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](/trust#the-domain-bind). ::: ## 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](/admin/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 :::danger{title="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." :::warning{title="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 1. **The card is gone.** Reload the workspace's **Security** section. The "Verify domain ownership" card and the "Domain unverified" pill should both have disappeared. 2. **The audit log recorded it.** The same section's [audit log](/admin/audit-log) should show "verified `yourco.com`". This is the only affirmative record. 3. **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.