Email Verification issuer use cases

Three real jobs where the discovery pack matters. Each scenario names who owns DNS, who hosts the well-known JSON, what “done” looks like, and how it fails when Chrome cannot find iss.

1. Mailbox provider standing up EVP issuance

Who: A consumer mailbox product that wants Chrome to discover its Email Verification issuer for addresses on mail.example (or the apex domain users type in the address bar).

Task: Publish DNS on the email domain and host issuer metadata on the issuer host that actually signs verification tokens. Those hosts are often different.

  1. Decide the email domain users receive mail on (e.g. example.com) and the issuer host that will serve tokens (e.g. accounts.example.com).
  2. Open the generator. Enter both hosts, plus https issuance_endpoint and jwks_uri on the issuer origin.
  3. Keep both Ed25519 and EdDSA in signing_alg_values_supported through the Chrome 154–156 cutover unless you control every client version.
  4. Publish the TXT on the email zone: _email-verification.example.com TXT "iss=accounts.example.com" — bare lowercase hostname only.
  5. Deploy the downloaded JSON at https://accounts.example.com/.well-known/email-verification with Content-Type: application/json (Pages recipe from the tool).
  6. Confirm with curl (see how-to) that the JSON issuer matches the HTTPS origin byte-for-byte (no trailing slash).

Result when correct: Chrome can resolve iss from DNS and fetch metadata from the issuer origin.

Failure symptoms: TXT missing or carrying https:// / a path / uppercase; well-known returns HTML or wrong Content-Type; issuer string mismatches the origin. In those cases discovery never completes — users never reach a valid issuance flow even if your signing service is healthy.

2. Enterprise IdP: corp mail delegated to accounts.example

Who: Identity / platform engineers whose employees use @corp.example mailboxes but verification tokens are issued by accounts.example (or a dedicated IdP hostname).

Task: Delegate discovery from the mailbox DNS zone to the IdP origin without inventing a second RP-like identity. Hostname in iss= must equal the HTTPS origin that serves the well-known document — character for character.

  1. Inventory who can edit DNS for corp.example vs who deploys on accounts.example. Both teams need a shared pack (generate once, paste into each ticket).
  2. Generate the pack with email domain corp.example and issuer host accounts.example.
  3. DNS owners publish the TXT on corp.example. IdP owners host JSON + JWKS + issuance on https://accounts.example.
  4. Refuse trailing slashes in the JSON issuer field. Refuse ports and paths in the TXT iss= value.
  5. Clarify who holds the Origin Trial token on each relying party origin that consumes verification — that token is not inside this discovery pack. Renew OT meta/header separately before the 2026-11-17 window if your tokens predate the extension.

Result: Mail on corp.example discovers accounts.example; issuance and JWKS stay on the IdP. Security review can see that private signing keys never touched this static generator.

3. SDK / docs site: reference discovery pack for integrators

Who: SDK vendors documenting how customers become issuers, or internal platform docs that ship a “golden” example pack.

Task: Give integrators a copy-paste discovery example without implying this site validates email addresses like ZeroBounce / NeverBounce.

  1. Generate a fictional but schema-valid pack (e.g. docs-example.test / issuer.docs-example.test) with the tool — still fully local.
  2. In your docs, label it clearly as issuer discovery, not deliverability checking. Link the FAQ boundary.
  3. Tell customers they must replace hosts, publish real DNS, and obtain their own OT tokens for relying-party origins.
  4. Never paste customer private keys into demos; this tool never asks for keys.
Boundary: If someone arrives looking for “is this email real?”, send them away. This matrix only helps issuers publish discovery metadata Chrome can fetch.