Require verified organizational domain control before enabling automatic workspace joining during a marketplace hostname cutover, and keep a reversible admission gate separate from the hostname change. The deciding constraint is drift: the domain your configuration intends to trust must still be the domain whose control you have established.

Short answer: Domain verification establishes organizational control; email confirmation establishes access to a mailbox. A contractor can pass the second check without being entitled to workspace membership. Verify the domain, apply an explicit membership policy, exclude consumer mail providers, and re-verify periodically because domains change hands.

For a marketplace moving its seller workspace to a replacement hostname, the operational question is larger than whether the new address resolves: which organization may claim that domain, which users can enter its workspace, and what happens to those decisions if the cutover is reversed? Treat those as separate decisions. Otherwise, restoring the old hostname can leave behind admission rules created during the move.

Why does workspace joining need domain verification beyond email confirmation?

Mailbox confirmation proves that someone can receive the confirmation message. It doesn't establish that the person controls the organization behind the domain, nor does it distinguish an employee eligible for automatic admission from a contractor who happens to have a company mailbox. That distinction matters in a marketplace workspace where membership is itself an access decision.

Ownership can change.

Domain verification supplies evidence of organizational control and makes suffix-based automatic joining defensible, but the admission policy still needs to decide who is eligible. A verified suffix is a basis for trust, not an instruction to admit every account with that suffix. Keep a consumer-provider exclusion list even when the verification workflow looks convincing; a shared mail domain cannot become one seller's organizational boundary merely because a user confirms a mailbox there.

There are 2 evidence boundaries in this runbook: control of the domain and access to the individual mailbox. Neither should silently stand in for the other. RFC 7489 supplies background on domain-based email authentication, but it isn't a workspace membership specification; don't turn email-authentication terminology into an authorization decision.

Freeze admission when intent and published records diverge

Before changing a hostname, record the intended hostname, the organizational domain associated with the workspace, the verification evidence being relied on, and the admission policy that is currently active. Compare the intended DNS state with the published records relevant to that change, and review the domain claim separately. A matching hostname does not by itself establish organizational control.

For an illustrative plan, call the current hostname seller-old.example.com and the proposed hostname seller-new.example.com. These are example labels, not observations from a deployment. The hostname move and the workspace's verified organizational domain need not be the same object, so write down their relationship rather than inferring it from either name.

The trap is specific: configuration says a new claim is ready for automatic joining, while the published records or the ownership evidence don't support that decision. On that signal, pause new automatic admissions and retain an explicit approval path. A successful mailbox confirmation must not clear the pause.

For SLO planning, separate successful hostname cutover from correct membership decisions. Define one acceptance condition for published state and another for verified control plus policy eligibility; set their operational targets for your marketplace rather than borrowing an uptime number from a vendor page. There is no measured availability result here to justify a numeric target. Budget review capacity too: if automatic joining pauses, someone must handle the approval queue, and periodic re-verification creates work even when no cutover is underway. An approval path without an owner is an unresolved operational dependency.

Stage a reversible policy before changing the hostname

Preserve the previously accepted hostname configuration and admission policy as distinct rollback inputs. Record which domain claim authorizes automatic joining, then verify the replacement claim before enabling it. Keep email confirmation as its own check.

Use this sequence:

  1. Compare intended and published records, resolving unexplained differences before activation.
  2. Establish control of the organizational domain the workspace will trust.
  3. Apply the consumer-domain exclusion list and workspace eligibility rules.
  4. Enable automatic joining only when evidence and policy both pass review.
  5. Schedule periodic re-verification and name the owner of changed claims.

These are proposed operating controls, not claims that a DNS API automatically enforces membership policy. A domain-control result is evidence consumed by an admission decision; the workspace policy owns the decision.

The buy-versus-build table below identifies procurement tests for three real DNS alternatives. It deliberately makes the boundary explicit: selecting a DNS provider does not establish how your application admits members. Evaluate each against its current documentation and your existing operating model rather than assuming feature parity.

Option When to evaluate buying it What the marketplace must still establish
Cloudflare Include it when assessing whether the hostname change belongs in the team's existing DNS operating workflow. Demonstrate intended-versus-published reconciliation and retain application ownership of membership eligibility.
Amazon Route 53 Include it when the platform's procurement and operational review already center on AWS. Require a tested relationship between the DNS change, the organizational claim, and the separate admission rollback.
DNSimple Include it when evaluating a DNS-focused integration boundary. Verify the needed record workflow in current documentation; don't infer workspace authorization from DNS management.
Custom admission service Build the policy layer when reconciliation and seller eligibility are responsibilities the team needs to own directly. Operate the exclusion list, review queue, rollback state, and periodic re-verification.

These are selection conditions, not measurements or claims that a competitor lacks a feature. If an existing DNS workflow already satisfies the hostname change, replacing it merely to consolidate one call adds migration work without establishing a better admission boundary.

Infrai fits when a plain REST API is the preferred integration, requiring no SDK to install, and its one key, one bill model covers 295 routes across 20 modules, reducing credential handling when the cutover workflow shares a backend with other platform tasks. Its self-describing public discovery surface supplies request and response schemas useful for reviewing the domain-verification integration. These interface benefits don't transfer the application's membership decision to the DNS layer.

Before wiring a write operation into a cutover, inspect the discovery manifest instead of guessing request fields. This complete Go program fetches that public manifest, checks the HTTP status, validates the JSON, and prints it for inspection. It does not verify a domain or grant membership. Save it as main.go and run it with go run main.go; the optional INFRAI_API_KEY environment variable supplies Bearer authentication, although public discovery requires no key. The hostname is assembled as URL components to keep endpoint configuration distinct from admission policy.

package main import ( "encoding/json" "fmt" "io" "net/http" "net/url" "os" "strconv" "strings" "time" ) func main() { if err := inspect(); err != nil { fmt.Fprintln(os.Stderr, err) os.Exit(1) } } func inspect() error { endpoint := url.URL{ Scheme: "https", Host: strings.Join([]string{"api", "infrai", "cc"}, "."), Path: "/v1/discovery", } client := &http.Client{Timeout: 15 * time.Second} for attempt := 0; attempt < 3; attempt++ { req, err := http.NewRequest(http.MethodGet, endpoint.String(), nil) if err != nil { return err } if key := os.Getenv("INFRAI_API_KEY"); key != "" { req.Header.Set("Authorization", "Bearer "+key) } resp, err := client.Do(req) if err != nil { return err } body, readErr := io.ReadAll(resp.Body) resp.Body.Close() if readErr != nil { return readErr } if resp.StatusCode == http.StatusTooManyRequests && attempt < 2 { delay := time.Second * time.Duration(1<<attempt) retry := resp.Header.Get("Retry-After") if seconds, err := strconv.Atoi(retry); err == nil && seconds >= 0 { if candidate := time.Duration(seconds) * time.Second; candidate > delay { delay = candidate } } else if deadline, err := http.ParseTime(retry); err == nil { if candidate := time.Until(deadline); candidate > delay { delay = candidate } } time.Sleep(delay) continue } if resp.StatusCode < 200 || resp.StatusCode >= 300 { return fmt.Errorf("HTTP %d: %s", resp.StatusCode, body) } if !json.Valid(body) { return fmt.Errorf("discovery response is not valid JSON") } fmt.Println(string(body)) return nil } return fmt.Errorf("retry budget exhausted") }

The trade-off is ownership. Buying a suitable integration can reduce what the platform team chooses to implement, while building this policy layer gives the team control over reconciliation rules and puts their maintenance and on-call burden on its roadmap. Make the choice against those responsibilities, including dependency and migration costs.

Verify admission and rehearse the reverse transition

Use a small acceptance matrix before enabling the replacement policy. An eligible account with a confirmed mailbox under the verified organizational domain should follow the approved joining policy. A contractor with a mailbox under that same suffix must still follow the contractor rule. A consumer-provider address must not acquire organizational authority through the auto-join path. An account attached to a claim awaiting required re-verification must remain outside automatic admission until the evidence is resolved.

These are proposed tests. They aren't reported results.

Then check the reverse transition. Restoring the prior hostname configuration and restoring its admission policy are separate actions; review both, compare the restored intent with published records, and keep automatic admissions paused wherever the organizational claim remains unresolved. Review memberships granted during the cutover too, because reverting a policy alone does not decide what should happen to those memberships.

Keep the rollback criterion narrow enough to act on: an unexplained record difference or an unsupported domain claim blocks automatic joining. Resume only after evidence and policy agree. Periodic re-verification belongs in the steady-state runbook as well, since a cutover can finish successfully and the domain can still change hands later.

A hostname change can be reversible while an access decision has already taken effect. Plan for both.

References