# Verify a domain

> Source: https://elaichi.ai/docs/guides/settings/verify-a-domain/

Prove you own an email domain with a DNS TXT record. Once verified, people who sign in with an address at that domain can join this organization automatically — without a one-off invite. Verified domains are also how SSO routes email addresses to the right identity provider.

**Where to find it:** **Settings → Domains**

You need **Manage organization** (`org:manage`) to add, verify, configure, or remove domains.

## What a verified domain enables

| Capability | Where you configure it |
| --- | --- |
| **Auto-join** | Domains tab — anyone signing in with `@your-domain` can join this org |
| **Default role on join** | Domains tab — role assigned when they join (defaults to **Member**) |
| **SSO routing** | **Settings → SSO → Domain routing** — bind the domain to an SSO connection |
| **Enforce SSO** | SSO connection settings — social login and magic links are refused for that domain |

Removing a domain stops new automatic joins. Existing members keep their access.

## Add and verify a domain

1. Open **Settings → Domains**.
2. Choose **Add domain** and enter the domain (for example `acme.com`).
3. Elaichi shows a **TXT value** to publish. Copy it.
4. In your DNS provider, create a **TXT** record for that domain and paste the value.
5. Back in Elaichi, choose **Check now**, or wait — the add dialog polls automatically while DNS propagates. On the Domains list you can also choose **Verify**.

Status shows **pending** until DNS matches, then **verified**.

**You'll know it worked when:** The domain row shows verified, and you can set a default role.

:::callout{type="info"}
DNS changes can take minutes to hours. If verification fails, wait and try again — the TXT value itself does not change until you remove and re-add the domain.
:::

## Default role for auto-join

After a domain is verified, pick which role new joiners receive:

1. In the Domains table, open the **Default role** control for that domain.
2. Choose **Member (default)** or any custom / built-in role **except Org Owner**.
3. The change saves immediately.

People who join only because of this domain get that role. Invites and SCIM can still assign different roles through their own flows.

## Bind the domain to SSO

Domain → IdP routing lives under **Settings → SSO**, not on the Domains tab:

1. Verify the domain first.
2. Open **Settings → SSO → Domain routing**.
3. For each verified domain, choose an SSO connection, or leave **Org default** to use the connection marked as default.

Without a verified domain, the login screen cannot resolve “which IdP should handle this email?” for enterprise SSO.

## Enforce SSO (implications)

Enforcement is a switch on the **SSO connection** (and only while the connection is active):

- Members whose email matches a **linked verified domain** must sign in through that IdP.
- **Social login** (Google, GitHub, Microsoft) and **magic links** are refused for those addresses.
- Just-in-time provisioning can still create membership on first successful SSO login.

Turn enforcement on only after the connection is active, domains are linked, and you have tested sign-in with a real account.

## Remove a domain

Use the delete control on the Domains row and confirm. Confirm copy explains that new automatic joins stop; existing members are unchanged. If the domain was linked for SSO, update **Domain routing** before or after removal so login resolution stays correct.

## Good to know

- Domains are stored lowercase.
- Only verified domains appear in SSO domain routing.
- Auto-join and invites both create membership; SCIM is a third path when you use provisioning.
- SSO, SCIM, and group mappings require the Black plan (see [Billing](/guides/settings/billing)).

## Related

- [Set up single sign-on](/guides/settings/single-sign-on)
- [Provisioning members with SCIM](/guides/sso/scim-provisioning)
- [Invite and manage people](/guides/members/invite-and-manage-people)
- [Roles and permissions](/guides/members/roles)