What the page checks
POST /api/verify-dns performs a real _agenid.<domain> TXT lookup against a per-domain token, joining chunked TXT records, and on a match reports proves: "domain_control". /verify/domain polls POST /api/domain/status, which returns provider detection, one-click availability, TXT record state and the state of the operator's .well-known key document from a single read, so the page cannot display a combination of states that never coexisted.
The token is per domain. That is worth saying because an earlier generated route used one hard-coded token for every user and every domain; it was removed as a fabricated-verification stub on 2026-09-14.
Why AgenID holds no DNS write credentials
A service that proves identity should not hold standing write access to its users' DNS zones. That credential can redirect mail, obtain certificates for the domain and publish a different key document, which is the very evidence a verifier relies on. Holding it would make AgenID a single point from which operator identities could be rewritten.
With Domain Connect the operator signs in to its own provider and approves one specific record. AgenID never sees a provider credential. A route that did hold a Cloudflare or GoDaddy credential existed in the tree, unconfigured. It was later deleted rather than left idle, and a test now forbids any web source file from reading a DNS provider credential or calling a provider write API.
Where one-click stands today
One-click Domain Connect is pending registration of AgenID's service template with DNS providers. Until then the one-click URL is null, and the interface renders no button rather than a link that would 404 on someone else's dashboard. Operators add the TXT record by hand, which the page walks through with the exact name and value.
Provider detection uses spec-literal Domain Connect discovery with a GoDaddy fallback, and a resolver failure on the polling endpoint reports pending and retries rather than failing the flow.
Evidence is not a level
Confirming domain control records evidence. It raises nothing. The reference deployment at agenid.com issues nothing above L1_REGISTERED today: L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved and is not issuable at all.
When L2 does ship, it is planned as the first level above L1 precisely because its evidence is a DNS record any third party can re-derive, so a wrongly issued L2 would be externally detectable.
What it does not do, and how to try it
Which agent is acting is not the same question as what it is allowed to do. AgenID answers the first. Protocol v1.1.1 defines no signed authorization object, so permission stays with the operator and with the party on the other side. Domain control says an operator controls a name. It says nothing about what the operator's agent may do on anyone's behalf.
Open /verify/domain, enter a domain you control, publish the record it shows and wait for the check to complete. The domain control verification and Domain Connect entries cover the background.