Your product lets an organisation claim a domain. Once claimed, anyone signing up with an address at that domain joins their workspace, single sign-on can be enforced, and the administrator can manage those accounts.
That is a powerful grant, and the security of the whole tenancy model rests on how you verified the claim and on whether you ever check it again.
This post is what domain verification has to get right. For whoever is building the enterprise tier.
Verification has to prove control, not receipt
The weak version sends a confirmation to an address at the domain. That proves someone reads mail there, which is not the same as controlling the domain, and it is satisfiable by anyone with a mailbox including a former employee or a contractor.
The strong version requires a change only someone with DNS control can make: a TXT record containing a value you generated, or a file served at a well-known path on the domain's website.
Between them sits a middle version that is widely used and worth being clear about: verification via a privileged mailbox such as admin@ or postmaster@. Better than an arbitrary address, still weaker than DNS, and worth accepting only for low-consequence claims.
The consequence scales with what the claim unlocks. If claiming a domain lets you take over existing accounts, require DNS.
Re-verify, because domains change hands
A one-time check binds a claim to a moment. Domains lapse, get sold, and move between companies, and a claim made in 2021 by a company that no longer owns the domain is a live grant over anyone using it today.
Re-verify periodically. If the record is gone, do not revoke silently: notify, allow a grace period, then suspend the domain-based privileges rather than deleting anything. A customer whose DNS team removed an unexplained TXT record should get a warning, not an outage.
Decide what a claim actually grants
Three levels, and products frequently conflate them:
Auto-join. New signups at the domain land in the workspace. Convenient, and it means whoever controls the domain gets new users routed to them.
Enforcement. Existing and future users at the domain must authenticate through the organisation's identity provider. This is what enterprises want and it is a real constraint on those users.
Capture. Existing accounts at the domain, created before the claim, are absorbed into the workspace, with the administrator gaining control over them.
That third one is where the sharp edges are. A user who signed up with a work address for personal use, or an account created by a contractor, gets handed to an administrator who can read what is in it. That may be entirely correct, since it is a work address and the company's data. It is also a surprise, and it deserves notification to the affected user and a clear statement in your documentation rather than being discovered.
Handle the shared-domain problem
Not every domain belongs to one organisation. Free mailbox providers are the obvious case and easy to block. The harder ones are shared hosting domains, university domains where departments are effectively separate, and country-level domains with unusual registration rules.
Maintain a list of domains that cannot be claimed, seed it from the well-known public suffix data rather than writing your own, and have a path for a customer to dispute a claim. Someone will eventually claim a domain they share with others, and if there is no process, your support team will improvise one.
Subdomains need a decision
Does claiming example.com grant eng.example.com? Both answers are defensible and the failure is not choosing.
If claims cascade, a claim on a parent captures every subdomain including ones belonging to different parts of a large organisation. If they do not, an enterprise must claim each one, which is tedious and which they will discover only when a user lands in the wrong place.
Pick one, say so in the interface at the moment of claiming, and make the behaviour visible.
Log it like the privileged action it is
Every claim, verification, re-verification, failure and revocation, with who initiated it and what method was used. When a dispute arrives, and one will, the record of how the claim was verified is what resolves it.
The same applies to capture events: which accounts moved into a workspace, when, and on whose claim. That is an access change affecting users who did not request it, and it belongs in the audit trail on both sides.
The concession
DNS verification is genuinely harder for customers. Many people who administer a workspace do not administer DNS, and requiring a TXT record introduces a delay and a second team into what was a self-service flow. Products that require it see fewer domains claimed, and some of those are customers who gave up.
The workable split is by consequence. Auto-join for new signups: a privileged mailbox is proportionate. Enforcement or capture of existing accounts: DNS, because the grant reaches people who did not consent to it. Applying the strongest check to the lowest-consequence action is how a verification flow becomes something customers route around by asking support to do it manually, which is verification by email with extra steps.
The implication
Domain verification is the root of trust for everything your enterprise tier does. Every subsequent control, enforced sign-on, administrative visibility, tenant isolation, inherits whatever confidence that check produced.
If the answer to "how do we know this organisation owns this domain" is that somebody clicked a link in an email, that is the strength of the whole model.
