Email Verification well-known FAQ

Is this an email validation / deliverability API?

No. ZeroBounce-style tools check whether an address can receive mail. This site only helps issuers publish Chrome Email Verification discovery: a DNS TXT delegate and /.well-known/email-verification metadata. It never pings mailboxes, never scores risk, and never stores addresses you type into the form.

Can iss= include a scheme, port, or path?

No. The DNS TXT value must be a bare lowercase hostname — for example iss=accounts.example.com. Chrome rejects https://, ports, paths, uppercase letters, and trailing dots. Put paths only inside the JSON endpoint fields (issuance_endpoint, jwks_uri), which are full https URLs on that same host.

May the well-known URL redirect?

Prefer a direct HTTP 200. Discovery clients expect to fetch JSON from the canonical well-known path on the issuer origin. A redirect to another host, or a soft-404 HTML page with status 200, commonly breaks parsers even when your issuance API is healthy. Keep the file on the issuer origin and return Content-Type: application/json.

Why both Ed25519 and EdDSA?

Chrome 154–155 recognize EdDSA; Chrome 156+ also accepts fully-specified Ed25519. Listing both in signing_alg_values_supported reduces breakage while the fleet rolls forward. Drop an identifier only when you control the client set.

How is this different from BIMI / SPF / DKIM?

SPF, DKIM, and BIMI prove or brand mail in transit. Chrome Email Verification issuer discovery tells the browser which host issues verification credentials for a mailbox domain. You may run both stacks, but publishing SPF does not replace the _email-verification TXT or the well-known JSON document.

Do private keys go through this site?

No. The generator never asks for private keys. Domains and endpoint URLs stay in your browser; downloads are produced locally. Cloudflare may log ordinary page-view CDN data (IP, URL path) for this static site — not the contents of the form fields. Details: Privacy.

Where do Origin Trial tokens go?

On each relying party origin that consumes Email Verification — via meta tag or HTTP header from Chrome’s OT portal. They are not embedded in the discovery JSON. Renew tokens that may expire around 2026-11-17 independently of this pack.