A shared alias that outlived an offboarding passes the mailbox check onboarding treats as ownership

The token in the sample code needs no database. `expected_token()` HMACs the account id and the lowercased domain with a secret read from `DOMAIN_PROOF_SECRET`, then truncates the SHA-256 hexdigest to 32 characters ^[18][17]. Those 32 hex characters are 128 bits, half the digest ^[20]. Determinism per account and domain is what removes the token table ^[18]. It also means the secret cannot be rotated quietly: change `DOMAIN_PROOF_SECRET` and every record a customer already published stops matching ^[22].

`authoritative_resolver()` is where the cache gets bypassed. It calls `zone_for_name` on the domain, resolves the zone's NS set, resolves an A record for each nameserver, and returns a resolver built with `configure=False`, that nameserver list, and `lifetime = 5.0` ^[19]. For a zone listing two nameservers, that is four resolutions before anything asks for the TXT record ^[21]. The list is rebuilt inside the function, so every attempt pays those lookups again ^[26].

Take a zone publishing a one-hour negative TTL, inside the range the RFC recommends. A job polling every 30 seconds reads the same cached NXDOMAIN 120 times before the entry expires ^[23]. The customer, meanwhile, pasted the record into a dashboard forty seconds ago ^[27].

The post calls the platform-owned subdomain case "the one that passes code review and still fails in production" ^[9]. The lookup succeeds every time. That is why the branch has to happen before the query, at the registrable domain. For names inside a zone the platform is authoritative for, the remaining signals are a registrar contact, an out-of-band contract, or human review ^[12]. Where the name lives in the customer's zone, the post treats the TXT check as the strongest cheap evidence available ^[13].

The split between the two proofs has precedent in the standards. Neither standard mails anybody: DMARC publishes policy in a TXT record at `_dmarc` because writing there requires zone authority, and ACME's dns-01 challenge does the same at `_acme-challenge` ^[5]. Mailbox checks, in the post's framing, belong to inviting a teammate, confirming a billing contact, and recovering a locked account ^[6].

Re-verification is the piece the post opens on and then drops. Its first paragraph lists "what you do when the proof quietly disappears six months later" among the things the zone boundary decides ^[1]. The published text then works through the mailbox conflation, the self-signed subdomain and the negative cache before the code listing breaks off mid function ^[25]. The design does make a later check cheap, because the expected token is recomputed from the account id and the domain and nothing has to be stored ^[24]. In my view the Public Suffix List branch is the easy half of this; the re-check interval is the half that never gets a ticket. The label to look for is `_saas-verify` ^[17].