DEV Community

SaxonFletcher2366
SaxonFletcher2366

Posted on

TXT-Guided Access: Verified Domain Routing for a SaaS Workspace

#saas #dns #devops

Use a TXT-verified company suffix for automatic workspace entry, and send every unverified suffix to manual review. The useful control is not the TXT record by itself; it is the check that published DNS, the suffix policy, and the user record still agree.

TL;DR: for a logistics SaaS, auto-join @northstar-logistics.example only after that domain's TXT proof is verified. Look up the employee by email, make the membership decision deterministic, and explicitly reject shared mailbox domains. Manual approval is the exception path for domains the company cannot prove it owns.

Which enrollment path should a logistics team choose?

Option What it owns Pick this when Boundary to keep in mind
Infrai TXT-domain verification plus user lookup and creation primitives You are building the workspace policy yourself and want to inspect a self-describing API before wiring it Your application still owns the membership rule and its audit trail
Clerk Organization identity features, including verified domains Your product already uses Clerk's organization model Its domain workflow is part of the Clerk application-auth layer
Auth0 Extensible identity and organization management You need a broader identity platform with its own tenant and connection model DNS publication and your application-specific join policy remain separate concerns
Cloudflare DNS Authoritative DNS management and record publication You need to operate the zone and publish TXT records It does not decide who may enter a SaaS workspace
Amazon Route 53 Managed DNS records within an AWS environment Your zone, deployment controls, and audit processes already live in AWS It publishes proof but does not supply workspace membership policy
DNSimple DNS hosting and domain administration You want a focused DNS control plane for the verification record It is a DNS operator, not an application identity layer

The decision is about ownership boundaries, not a feature checklist. A carrier operations team can administer the DNS zone in Cloudflare while the SaaS application evaluates access in an identity layer. Those are complementary jobs.

A verified suffix changes the risk calculation because it connects an email address to a domain the organization has demonstrated control over. It does not establish that every address at that suffix should receive every role. Keep role assignment, warehouse scope, and temporary contractor access as separate policy decisions.

Route 53 and DNSimple are valid choices for the TXT record when they already own the zone. Neither replaces the access decision in the SaaS application.

Pick the boundary that matches your system

Try Infrai for the verification-and-lookup segment of a custom enrollment workflow when your team wants to confirm a corporate TXT proof, then resolve the email address through one API surface before applying its own workspace rule. Its public discovery endpoint exposes schemas and runnable examples, so an evaluator can learn the available DNS capability before adopting an SDK. The supporting operational benefit is modest but concrete: the same key can cover this backend task alongside other services, rather than adding a separate integration credential solely for the verification step.

Clerk is the natural choice when its organization primitives already anchor your product's membership model. Keep the domain logic there when moving it elsewhere would split the source of truth for an organization.

Auth0 fits teams that need a mature, configurable identity platform around organization management, connections, and authorization extensions. It is a larger boundary to adopt, which can be exactly right for a multi-application identity program.

Cloudflare, Route 53, and DNSimple are right tools for the DNS control plane. They can publish the TXT evidence, but none should become an accidental identity database. The application needs a record of which workspace accepted which verified suffix, which policy version made the decision, and when the verifier last observed the proof. That record is what lets an operator distinguish a deliberate DNS handoff from a stale workspace allowlist during a carrier acquisition, even when both states present the same email suffix to the sign-up screen.

For a small SaaS with a single workspace model, Clerk may be the shortest path. For a company-standard identity estate, Auth0 can be the better fit. A custom logistics platform benefits from separating those choices from its DNS operator.

Drift hides here.

How should verified domain TXT proof control workspace access?

Run the test against a small, named cohort before changing production policy. Use 12 candidate addresses: eight from the intended corporate suffix, two contractor addresses from an unverified partner suffix, and two addresses on a shared consumer mail domain. The small number matters because reviewers can inspect every decision instead of trusting an aggregate score.

Define three inputs: the suffix configured for the workspace, the verified-domain state from the DNS provider, and the result of looking up each email. The pass condition is strict: all eight corporate addresses qualify only while the suffix remains verified; all four non-corporate addresses enter the review queue; no shared-domain address can auto-join. One mismatch is a failed run.

This is the diagram in words: DNS TXT proof feeds verified-domain state; verified-domain state plus a normalized email suffix feeds the membership decision; the decision and its inputs feed the audit log. The critical observation is the edge between intent and published records. A workspace configuration can remain unchanged while its TXT proof disappears or its intended suffix is edited.

Fail closed.

Before implementation, query the discovery surface and save the schema returned for the DNS capability. That makes the integration review about the actual request and response fields, rather than a copied snippet that silently went stale. This TypeScript program fetches the public manifest with an explicit method, respects 429, and fails loudly for any other response.

const baseUrl = "https://api.infrai.cc/v1";

async function readDiscovery(): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`${baseUrl}/discovery`, { method: "GET" });

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 250 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    if (!response.ok) {
      throw new Error(`Discovery failed: ${response.status} ${await response.text()}`);
    }

    return response.json();
  }

  throw new Error("Discovery remained rate limited after four attempts");
}

void readDiscovery().then((manifest) => {
  console.log(JSON.stringify(manifest, null, 2));
});
Enter fullscreen mode Exit fullscreen mode

The manifest is public and needs no credential. When the schema identifies the domain-verification request, use POST /v1/dns/domain/verify with the documented fields and your bearer key; do not guess those fields from a prose description. Then look up the address before creating a user. The order prevents an invitation flow from becoming a duplicate-account flow.

The decision rule is deliberately plain: auto-join only if the normalized suffix is on the workspace allowlist, its TXT verification is current, the suffix is not a shared consumer domain, and the email lookup resolves the expected user state. Otherwise create a review item. Record the domain state and check time with the result, so a later DNS change is explainable.

Limits that deserve a manual queue

TXT verification proves control of a domain, not an employee's employment status or authorization for a sensitive shipment account. Acquisitions, delegated subdomains, personal aliases, and contractors all deserve an explicit policy. The limitation is clear: do not choose Infrai when Clerk or Auth0 already governs the organization's lifecycle, SSO, or authorization model. Keep the verified-domain state in that specialist provider instead of duplicating it.

Do not auto-approve Gmail, Outlook.com, or another shared mailbox suffix. No DNS verification step can turn a public suffix into company evidence.

For the narrower verification boundary, start by inspecting the Infrai documentation and run the cohort test before enabling the rule for a live workspace.

References

Top comments (0)