--- title: Adopt a domain description: Claim a domain for your organization on Sudomimus by proving DNS control, binding it exclusively to the organization as the basis for login policy and federation. editUrl: true head: [] template: doc sidebar: order: 2 hidden: false attrs: {} pagefind: true draft: false --- import { CardGrid, LinkCard } from "@astrojs/starlight/components"; If your organization owns a domain (`example.com`, your company's domain, a personal domain you control), an **owner** of that organization can **adopt** it on Sudomimus. Once adopted, the domain belongs to your organization on the platform: it is bound exclusively to the organization that proved control of it. Adoption is the **foundation** the rest of this section builds on — it is the ownership primitive that a [login policy](/en-us/domains-federation/domain-login-policy/) and [enterprise federation](/en-us/domains-federation/sign-in-with-your-idp/) attach to. On its own, an adopted domain has no effect on any sign-in flow; it becomes load-bearing the moment you give it a policy. ## What an adopted domain gives you - **Exclusive ownership.** A verified domain is bound to a single organization. No other organization can hold a verified claim on the same domain while you hold it. - **A mount point for policy.** Once verified, the domain can carry a [login policy](/en-us/domains-federation/domain-login-policy/) (allow / block / force SSO) and can be bound to one of your [federation connectors](/en-us/domains-federation/federation-connectors/). ## Why this exists Most authentication products treat domain ownership as a paid enterprise feature. In Sudomimus it is a first-class primitive — the platform already needs to verify which email addresses belong to whom in order to support email OTP, and domain adoption is a natural extension of that model. It is particularly useful when: - You run a company whose employees share a domain. - You operate a community or organization whose members share a domain. - You want a verified, organization-owned claim on your domain as the basis for policy and federation. ## The adoption flow 1. **Initiate adoption** from the With portal at [`with.sudomimus.com`](https://with.sudomimus.com): pick one of your organizations and claim the domain you want against it. Only an organization owner can start an adoption. 2. **Publish the DNS record.** Sudomimus gives you a one-line `TXT` record to add to the domain: | Field | Value | |---|---| | Host / name | `_sudomimus-challenge.example.com` | | Type | `TXT` | | Value | `sudomimus-domain-verification=` | The dedicated `_sudomimus-challenge` subhost keeps the record clear of any apex SPF / DKIM / other `TXT` records you already publish. The token is fixed for the life of the claim. 3. **Verify.** Back in the portal, click **Verify**. Sudomimus performs one live DNS lookup, compares the record, and on success binds the domain exclusively to your organization. The claim moves from `PENDING` to `VERIFIED`. :::note[DNS takes a moment to propagate] Verification is on-demand and synchronous — there is no background polling. If you click **Verify** before the record has propagated (or while a stale "no such record" answer is still cached by the resolver), it can fail for a short while. Wait a minute and retry. ::: ## Contested domains and exclusivity - **Pending claims may coexist.** Two organizations can each have a `PENDING` claim on the same domain — initiation is not exclusive. - **Verification is the exclusive gate.** Only one organization can hold a `VERIFIED` claim at a time: whoever proves DNS control first wins the single verified slot. (This is deliberate — it stops anyone from "squatting" a competitor's domain in pending state.) - **Verifying a domain another organization already holds** fails with `DomainAlreadyAdopted`. ## Releasing a domain Releasing is reversible. An organization owner can hand a domain back to the platform at any time, after which it is free for another organization to adopt. Releasing a verified domain tears down its ownership lock and frees the quota slot. :::caution Releasing a domain also tears down any [login policy](/en-us/domains-federation/domain-login-policy/) attached to it. If the domain is forcing SSO, release it only when you intend to stop governing how that domain's users sign in. ::: ## Quota Each organization can hold a limited number of adopted domains (default **3**, counting pending and verified together; releasing any claim frees a slot). Sudomimus staff can raise the limit for your organization on request. The quota is enforced on the self-service surface only. ## Domain format Sudomimus accepts standard ASCII domains with at least two labels (`example.com`, `mail.example.co.uk`). Internationalized (punycode / `xn--`) domains are not accepted yet. Apex and subdomains are independent claims — adopting `example.com` does **not** adopt `mail.example.com`. ## Related