Tenant domains and regions: canonical domain vs custom domain

TL;DR: Your tenant domain includes the region (tenant.us.auth0.com), and hardcoding the wrong one breaks issuer validation. Custom domains mask it but the canonical domain stays the issuer unless configured otherwise. Rules - Use the full canonical domain everywhere: issuerBaseURL, JWKS URL, Management API base. - Never guess the region. Copy it from Dashboard > Settings, or from Tenant Settings in the Management API. - The tenant name alone (YOUR-TENANT) is not a domain; requests to it fail DNS or route to the wrong region.

Tenant domains

Canonical domain

New tenants get https://YOUR-TENANT.YOUR-REGION.auth0.com, e.g. YOUR-TENANT.us.auth0.com. The region is part of the domain. The OIDC issuer is this URL with a trailing slash: https://YOUR-TENANT.YOUR-REGION.auth0.com/. Token iss claims and the /.well-known/openid-configuration discovery document use it.

Rules

• Use the full canonical domain everywhere: issuerBaseURL, JWKS URL, Management API base.
• Never guess the region. Copy it from Dashboard > Settings, or from Tenant Settings in the Management API.
• The tenant name alone (YOUR-TENANT) is not a domain; requests to it fail DNS or route to the wrong region.

Custom domains

A custom domain (login.YOUR-DOMAIN) is a mask over the canonical domain: users see your brand in the URL bar, and cookies become first-party (fixes Safari ITP silent-auth issues). Setup: add the domain in Dashboard > Branding > Custom Domains, choose Auth0-managed certificates (they handle issuance and renewal) or self-managed, add the CNAME record at your DNS, complete verification.

Caveats agents hit:

• Feature table: not every Auth0 feature works through the custom domain; check the docs table for your feature (notably some Management API and edge behaviors still use the canonical domain).
• Token iss: by default the issuer stays the canonical domain even when authenticating through the custom domain. API validators must accept the canonical issuer, or configure the issuer accordingly.
• After verifying, update the SDK domain values and the callback/logout URL registrations to the custom domain; mixed domains cause cookie and issuer mismatches.

Checklist

• Canonical domain copied from the dashboard, not guessed.
• If using a custom domain, SDKs and URL allowlists point at it consistently.

When to use this

• This covers exactly what the title says: Tenant domains and regions.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Tenant; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Tenant behavior.

Auth0's custom domains doc describes the custom domain as a mask for the tenant domain URL, Auth0-managed vs self-managed certificates, CNAME verification, and the feature-compatibility table. The tenant domain format with region is documented in the Auth0 overview docs. Verified against live docs 2026-09-26.