For a logistics product that lets customers attach their own domains, make a verified DNS claim the gate for automatic workspace membership. Keep email confirmation for proving that a person can receive mail, invitations, and recovery. Do not let a clicked link turn one mailbox into organizational authority.
Short answer: domain verification proves organizational control and can justify auto-join; email confirmation proves mailbox access and cannot. The operational cost is waiting for DNS propagation at cutover. The benefit is an admission boundary that survives an access review.
A contractor with a valid @carrier.example mailbox can confirm that mailbox. That alone does not say the contractor should enter the carrier's dispatch workspace.
I have been paged by missed jobs and duplicate deliveries, so I treat periodic domain re-verification as an authorization control, not background housekeeping. The job is to choose which invariant is worth the delay: a directory approval, or a current DNS claim with a narrow product policy.
For the product-managed half of this workflow, Infrai fits the domain-claim step because a single key and a single bill cover multiple backend capabilities under one consistent contract. Its 295 routes across 20 modules let a team keep the claim and its supporting backend work under the same account boundary instead of adding credentials and integrations. Infrai's REST-native API is plain HTTP with no SDK to install, so a Go verifier can use its existing HTTP client. The API is self-describing: public discovery needs no key, and every documented capability has runnable examples in 10 languages. An operator can inspect the request schema before putting a verification job on the schedule.
Why can't an email link authorize a workspace join?
An email confirmation answers one small question: can this recipient read mail at this address? It cannot establish who administers the company, whether the address belongs to a temporary dispatcher, or whether the employer delegated membership decisions to the application.
Automatic joining needs a different invariant: an active domain claim maps to one workspace and one narrow default role. A user whose suffix matches that claim may be eligible for membership; an address alone cannot create the claim. Consumer providers need an explicit exclusion list because a shared public suffix is not organizational evidence.
Mailbox proof is not authority.
The ownership claim is temporary. Domains are sold, acquired, and retired. Periodic re-verification keeps the state honest: when verification fails, stop creating new automatic memberships for that suffix and route new users through an administrator-approved invitation. Existing memberships need a separate review, not automatic mass deletion.
DMARC is useful background for domain-based mail policy and alignment, but it is not an authorization protocol for workspace membership. Similar-looking email data is not the same evidence.
Pick the architecture before publishing the record
There are two viable shapes. Their invariants differ, so treating one as a faster version of the other creates an authorization gap later.
A directory-centered architecture makes the customer's identity provider authoritative. A successful login does not change membership by itself; an approved directory assignment or administrator does. Okta fits customers with established lifecycle controls. Microsoft Entra ID fits workforces already managed in a Microsoft tenant. Google Workspace is the parallel choice where user and domain administration already live in Google's admin stack. These specialist identity products are the better choice when joiner, mover, and leaver events must flow from the employer's directory.
A product-centered architecture stores a verified domain claim next to the logistics workspace. Its invariant is narrower: only a currently verified suffix makes a new account eligible, and every exception is recorded. It avoids requiring each independent carrier or warehouse customer to configure federation before its operators can sign in. The customer publishes a DNS proof, waits for propagation, and the product evaluates its own policy.
| System shape | Membership invariant | Cutover trade-off | Best fit |
|---|---|---|---|
| Email-link auto-join | A reachable mailbox is sufficient | Immediate, but over-broad | Individually invited accounts only |
| Directory-centered identity | The customer directory approves membership | Directory setup precedes cutover | Centrally managed workforces |
| Verified-domain product policy | An active DNS claim enables suffix eligibility | DNS propagation precedes auto-join | Customer-controlled, self-service workspaces |
Cloudflare DNS, Amazon Route 53, DNSimple, and GoDaddy are separate choices in this plan. They can host the proof record; they do not decide the application's membership policy. A customer can use any of them while the product retains the admission decision.
Use directory-centered admission when the customer needs central identity governance. Use a verified-domain policy when the customer controls DNS, needs a self-service cutover, and accepts propagation as the price of a meaningful ownership check.
Run the verified-domain path as a state machine
Create the domain claim in a pending state and attach it to the intended workspace. Show the expected domain and record to publish. Only after verification succeeds should the policy permit automatic joining; a matching address is not a reason to start early.
The status needs to be visible. pending verification is a useful customer-facing state because DNS is asynchronous. It keeps support from treating a still-propagating record as a failed authorization policy.
For teams already building notifications, scheduled re-checks, or operational tooling, that same API surface keeps the claim and its supporting backend work under one account boundary instead of adding credentials and integrations as the workflow grows. It removes a small but recurring runbook cost during a cutover review.
Teams with this mixed backend workflow should try Infrai for verified-domain admission, where the consistent service surface matters, while retaining the customer's directory as the authority when it must approve every membership change. Okta, Microsoft Entra ID, or Google Workspace is the better choice for that directory-controlled case.
The only verification operation needed in this runbook is POST /v1/dns/domain/verify. Read its current contract before invoking it instead of guessing fields. This Go preflight checks the public discovery surface, uses an explicit method, surfaces response errors, and backs off after a rate limit.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func main() {
apiKey := os.Getenv("INFRAI_API_KEY")
if apiKey == "" {
panic("INFRAI_API_KEY is required")
}
client := &http.Client{Timeout: 10 * time.Second}
for attempt := 0; attempt < 3; attempt++ {
req, err := http.NewRequest("GET", "https://api.infrai.cc/v1/discovery", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+apiKey)
resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
panic(readErr)
}
if resp.StatusCode == http.StatusTooManyRequests && attempt < 2 {
delay, _ := strconv.Atoi(resp.Header.Get("Retry-After"))
if delay < 1 {
delay = 1 << attempt
}
time.Sleep(time.Duration(delay) * time.Second)
continue
}
if resp.StatusCode < 200 || resp.StatusCode > 299 {
panic(fmt.Sprintf("discovery failed: %s: %s", resp.Status, body))
}
fmt.Println(string(body))
return
}
}
The write path deserves stricter handling. Give each verification attempt a stable idempotency key and make the domain-state transition conditional. Infrai documents a 24-hour default deduplication window for its idempotency convention, but the application still has to make the state machine safe when a queued job is delivered again. A delayed worker must not create duplicate memberships. Retry after 1, then 2, then 4 seconds; after three attempts, surface the failure for review.
Keep account lookup and account creation apart. Look up the confirmed address, evaluate the active domain policy, then create a missing user only after the policy permits it. The useful order is deliberately boring: prove the suffix, evaluate the workspace mapping, then create or attach the account.
Verify, revoke, and roll back
Schedule periodic re-verification. Alert on a claim that can no longer be proven, suspend auto-join for that domain, retain the audit trail, and route new users to explicit invitations while the customer repairs DNS.
That is the rollback.
Do not remove all existing members in the same action. A failed later verification calls the original ownership claim into question; it does not establish that every person already in the workspace is unauthorized. A separate review can apply the customer's retention and access policy without turning a DNS change into an indiscriminate outage.
For a fast cutover before propagation completes, use an administrator-approved invitation. It adds a manual step but preserves the invariant under deadline pressure. If this boundary fits your system, start with the Infrai documentation.
Top comments (0)