What must a brand's email domain prove before it may route sign-ins to that brand's identity provider?

## Why a domain claim is a privileged operation Once a domain routes to a tenant's identity provider, that provider decides who may sign in as any address under it. A domain claim is therefore not a profile field - it is a grant of authority over a namespace. Treat adding one the way you would treat granting an administrator role: it is a privileged write, it is audited, and it needs proof. The attack is direct. A brand onboards, types a domain it does not own into its connection settings, and the next sign-in from that domain is routed to a provider that brand controls. That provider asserts whatever subject and address it likes, first-login creation mints an account, and the claiming brand now reads a namespace it has no relationship with. Nothing in the sign-in path is broken - every signature verifies - because the defect is upstream, in the claim you accepted. ## What the proof looks like - **Issue a nonce**, bound to the tenant and the domain, with an expiry. It is single-use for that claim. - **The domain's operator publishes it** where only someone with authority over the domain can put it: a DNS TXT record on the domain, or a file served under a well-known path on a host in that domain. Both demonstrate operational control; a confirmation mail to an address *in* the domain is weaker, because the person claiming may simply be an employee rather than an authority. - **You check it server-side**, from your own infrastructure, and record the outcome: who requested it, the nonce, when it first verified, and when it was last re-checked. - **You re-check on a schedule.** Domains lapse, get sold, and get reassigned inside a group of brands. A claim verified once and never revisited is an assertion about the past. ## The cases that make this hard | Case | Why it bites | What to do | |---|---|---| | Shared consumer mail domains | One tenant claiming one would capture everyone with a personal address | A denylist checked before a claim is even offered, maintained as data | | Subdomains | A brand controls a subdomain but not the parent, or vice versa | Verify the exact label routed; do not let a parent claim imply its children unless the parent proved it | | Existing accounts under a newly claimed domain | They already exist locally with their own credentials | Do not silently re-home them; decide explicitly, notify, and treat the transition as a migration | | A domain moving between brands in one group | The old tenant's routing keeps working | Re-verification catches it; unique-domain enforcement makes the handover an explicit operation | | A brand that cannot publish DNS records quickly | Central IT owns the zone and moves slowly | The claim stays pending and routing stays local - a pending claim must never route | ## The part people get wrong The dangerous state is not "unverified", it is **"unverified but already routing"**. It appears when verification is modelled as a flag on the same row that routing reads, and some code path sets the row before the check returns. Two habits prevent it: 1. **Routing reads a separate verified-domains table**, written only by the verification job. A claim in progress lives elsewhere and cannot be routed to by construction. 2. **The claim has states** - pending, verified, failed, revoked - and routing matches on `verified` explicitly rather than on "not failed". ## What verification does not prove It proves control of the domain today. It does not prove that everyone with an address under it works for that brand, that the brand's provider authenticates them well, or that the addresses the provider asserts actually exist. Those are separate decisions: the admission policy decides who gets an account, and the assertion itself decides who arrived. What verification buys is narrower and essential - the tenant asking to receive this namespace's sign-ins is the party that operates it. ## Operating it - Keep verification status visible to the customer, with the exact record still to publish and the last check time, so support conversations are self-service. - Alert your own staff when a previously verified domain stops verifying, and keep routing on for a grace period rather than cutting a brand off on a transient lookup failure - then stop. - Record every claim, verification and revocation in the audit trail with the acting administrator; this is the row you will read after an incident.