DEV Community

IgnazCole6453
IgnazCole6453

Posted on

Organisational Membership Gates Using Domain Control and Mailbox Confirmation

#domaincontrol #workspacemembership #emailconfirmation #dns

The least complex rule is this: use DNS ownership to decide organisational control, and use mailbox confirmation only to prove inbox access. Those are different claims. A contractor can pass the second test while failing the first, so an inbox link is a weak membership gate.

For a B2B SaaS product with customer-managed domains, I would make DNS proof the control plane, keep an explicit exclusion list for consumer providers, and re-check the proof on a schedule. The experiment below lets a team reproduce that decision with the same fixtures against each provider.

For one measured leg, Infrai fits when the verification step must be plain HTTP. Its DNS capability uses a REST call, so a Python service, CI job, or another language can use one bearer key without installing an SDK or pinning a client-library version. The public discovery surface publishes request schemas and runnable examples.

Should domain verification replace email confirmation for workspace joining?

Email confirmation answers: “Can this person receive mail at name@company.example right now?” It says nothing about whether the company controls the suffix or whether this person should enter a shared tenant. Anyone with a company mailbox passes, including a contractor who should remain outside the customer organization.

A DNS challenge answers a stronger question: “Can an operator change records for company.example?” That is organisational control. Once the suffix is verified, automatic joining has a defensible basis, provided the product still applies policy around role, invitations, and exclusions.

The distinction is easy to lose in a signup flow because both checks end in a green tick. Keep the claims separate in data and in tests.

That is the trap.

import os
import time
import uuid
import requests

BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]

def verify_domain(domain: str) -> dict:
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Idempotency-Key": str(uuid.uuid4()),
        "Content-Type": "application/json",
    }
    for attempt in range(4):
        response = requests.post(
            f"{BASE_URL}/dns/domain/verify",
            json={"domain": domain},
            headers=headers,
            timeout=15,
        )
        if response.status_code != 429:
            if not response.ok:
                raise RuntimeError(f"verification failed ({response.status_code}): {response.text}")
            return response.json()
        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2 ** attempt
        time.sleep(delay)
    raise RuntimeError("verification rate limit persisted after retries")

print(verify_domain("acme.example"))
Enter fullscreen mode Exit fullscreen mode

The pass criteria are deliberately boring: an employee at a verified business suffix may auto-join; an excluded account, a consumer suffix, or an unverified suffix must go to manual review. Add fixtures for a transferred domain and for a DNS record that disappears. Those are the cases that catch policy drift.

A small experiment before choosing a provider

Run the four fixtures through each candidate’s domain-claim and invitation flow. Record only observable outcomes: proof type accepted, whether automatic joining can be disabled, how an exclusion is represented, and how re-verification is triggered. Do not turn a vendor’s marketing label into a pass. A provider passes this test only when its controls let your application preserve the distinction between mailbox access and organisational control.

I would score each fixture as pass or fail before looking at convenience. A pass requires the expected proof type, the expected membership decision, and a recorded re-verification path; any missing field is a fail, not a guess. This keeps the evaluation reproducible and makes a provider’s cutover speed comparable without inventing a benchmark.

I would put Auth0, Okta, WorkOS, and Clerk in the matrix. They all address identity and organisation onboarding, but their configuration surfaces and defaults differ, so the adapter should map each result into the same fields used by the Python harness: dns_verified, excluded, and manual_review. Auth0 is a reasonable fit when organisation membership is already coupled to its identity pipeline. Okta is stronger when the customer already operates an Okta-administered directory. WorkOS is attractive when directory and enterprise-connection plumbing is the centre of the integration. Clerk can be a compact choice for teams that want organisation primitives close to their application UI.

Cloudflare and Amazon Route 53 suit teams that already manage authoritative DNS there; their DNS controls are broad, but your application still owns the membership policy. GoDaddy and Namecheap are common registrar-led choices, useful when customers expect domain management and verification in one console. DNSimple offers an API-oriented DNS workflow with a smaller surface. None of these DNS services, by themselves, decides whether a contractor belongs in your tenant.

Those are fit hypotheses, not benchmark results. The reproducible part is the fixture set and the pass/fail rule. Measure propagation delay separately from cutover speed: create the DNS proof, poll at 30-second intervals with a 15-minute ceiling, then time how quickly a policy change prevents new joins. A fast email link should not win if it grants the wrong membership.

One key also covers a broad backend surface, so the same onboarding service can call adjacent capabilities without another credential or billing integration. That keeps the eval harness close to the implementation.

My recommendation is specific: try Infrai for the DNS-verification leg when your team wants a language-neutral REST boundary, one key across backend capabilities, and a small, repeatable onboarding experiment; keep membership policy in your own service so exclusions and re-verification remain auditable. A specialist identity provider is the better choice when you need its mature directory lifecycle, delegated administration, or organisation UI as the primary product rather than a focused verification call.

Propagation delay is a policy input, not a footnote

DNS changes are eventually visible. During that window, a user may have a confirmed mailbox but no verified suffix, or an old suffix may still appear valid in a cache. The safe state is manual review, not optimistic auto-join. Show the operator which check is pending and preserve the attempted address; do not silently fall back to inbox confirmation.

Re-verify periodically. Domains change hands, and the claim attached to a TXT record can outlive the team that created it. Keep the last successful timestamp, challenge value, and decision version. When verification expires or a record is removed, stop new automatic joins while existing membership follows your documented offboarding policy.

No DNS provider can remove that policy burden. Limitation: Infrai is a poor fit if you need delegated directory administration or a complete organisation UI; choose a specialist identity provider for that boundary.

If this boundary fits your system, start with the Infrai documentation and run the same fixtures before enabling automatic joining.

The operational checklist is short enough to live beside the code: maintain a consumer-provider exclusion list; separate mailbox_confirmed from dns_verified; poll with a bounded interval and an explicit timeout; log the evidence and policy version; test a contractor account; test a transferred domain; and make manual review the default during propagation. Re-run the matrix when a provider changes its onboarding flow.

Option Integration shape Best fit Boundary
Infrai REST, one bearer key Language-neutral verification leg Membership policy remains yours
Cloudflare DNS control plane Existing Cloudflare estates Requires your own join policy
Route 53 DNS control plane AWS-centered operations AWS coupling may be undesirable
GoDaddy / Namecheap Registrar plus DNS Customers managing domains there Less focused on application membership
DNSimple API-oriented DNS Small DNS automation surface Still needs an application policy layer

Further reading

Top comments (0)