Prerequisites
Before getting started with MCD, review the requirements below:- Your tenant is on an Enterprise plan (Public Cloud or Private Cloud deployments). For more information, see Manage Subscriptions.
- Your Enterprise plan provides a base entitlement of up to 20 custom domains per tenant.
- Additional custom domains beyond the base entitlement are available through an add-on SKU. Please reach out to Auth0 sales for details.
- You must be able to prove ownership of the configured custom domains.
Configure Multiple Custom Domains
You can add and manage multiple custom domains for your tenant using either the or the .- Auth0 Dashboard
- Management API
To create a custom domain in the Auth0 Dashboard:
- Navigate to Auth0 Dashboard > Branding > Custom Domains.
- Select +Add custom domain.
-
In the configuration form, provide the following information:
- Domain: A fully-qualified domain name that you own. For example:
my.custom-domain.com. - Certificate type: Choose Auth0-managed certificates or Self-managed certificates.
- Metadata (Key/Value): Add optional metadata like
region,client_name, orclient_id, to help organize and filter your domains.
- Domain: A fully-qualified domain name that you own. For example:
- Once you have configured the custom domain details, select Save.
pending until verification is complete.View and manage domains
The Custom Domains page displays all configured domains. You can:- Search: Find domains by name using the search box
- Filter: Filter domains by verification status, certificate type, or metadata values
- Sort: Sort domains by name, creation date, or verification status
- View details: Click on any domain to see detailed configuration, verification status, and certificate information
- Set default: Designate a domain as the default domain for your tenant
MCD features
MCD offers many key features and functionalities to more effectively manage your Auth0 implementation and improve user experience. You are responsible for owning and registering your desired custom domains with a domain name registrar. The Auth0 Management API provides comprehensive support for Create, Read, Update, Delete, and Verify operations for these custom domains, offering full programmatic control over their lifecycle. MCD is supported by the following Auth0 Management SDKs: Node.js, Go, Python, Java, and .NET. Authentication SDKs automatically work with custom domains when configured in your application.Default domain
When you have multiple custom domains configured, you can designate one as the default domain. The default domain is used when:- Sending email notifications (password resets, email verification, etc.) and the custom domain is not explicitly specified
- Making API calls to Auth0 endpoints without specifying a custom domain
- The
auth0-custom-domainheader is not provided in Management API requests
- Navigate to Auth0 Dashboard > Branding > Custom Domains
- Find the domain you want to set as default in the list
- Click the Set as Default button for that domain
The default domain makes the
auth0-custom-domain header optional in many scenarios. If you don’t specify a custom domain in your API calls or authentication flows, Auth0 will automatically use the default domain instead of the canonical tenant domain.Domain verification
The method for verifying domain name ownership depends on your chosen management type:| Domain Type | Verification Method | Details |
|---|---|---|
| Auth0-Managed | CNAME DNS record | Configure this record to confirm domain ownership and activate your domain. |
| Self-Managed | TXT DNS record | Specific TXT record details are provided in the Create API response. |
Metadata for enhanced management
You can provision up to 10 metadata fields per custom domain for easier organization and future customization. In upcoming releases, these metadata fields will enable advanced customization of email templates, , and authentication logic.Customize email templates
Leverage your custom domain information to personalize and brand your email templates, ensuring a consistent user experience. To facilitate this, MCD provides thecustom_domain.domain variable for use in Liquid Syntax.
For example, you could set the From Address of your email template to support@{{ custom_domain.domain }} , which would render as support@my.custom-domain.com. This variable is available through Liquid Syntax in the From Address, Subject, and Message fields. To learn more, read Customize Email Templates.
Customize email handling using the Management API
If you configured Multiple Custom Domains and enabled Use Custom Domains in Emails, theauth0-custom-domain HTTP header is available when using the Auth0 Management API. The header is passed as the value for the domain object in email templates.
The
auth0-custom-domain HTTP header is required if MCD is configured with at least 1 domain in ready state.
If you are moving from a single custom domain to MCD, you must update your existing Management API email requests to include the auth0-custom-domain HTTP header .auth0-custom-domain HTTP header:
- Send an email address verification email
- Create an email verification ticket
- Create invitations to an organization
- Create a user
- Create a multi-factor authentication enrollment ticket
- Create a password change ticket
- Update a user
Response messages
When you provide theauth0-custom-domain HTTP header, the following additional response types are possible:
| HTTP status code | Message |
|---|---|
409 | The tenant has multiple verified custom domains. |
400 | The custom domain does not exist for the tenant. |
400 | The auth0-custom-domain HTTP header has an invalid format. |
If you enable MCD and use the Auth0 Dashboard to configure Email templates, the Try feature will not allow you to test with a custom domain.
Multiple Custom Domains with Actions
Auth0 Actions allows you to create custom logic handling of your different transactions based on the custom domain. For example, you could create an Action that directs a user to an associated Organization, or enforce a specific access control policy. To facilitate this, post-login Actions features the objectevent.request.hostname, which provides the hostname being used for the authentication flow.
Use case: Restrict user access to an Organization based on custom domain
Store a domain allowlist and denylist (for example,allow_domains and deny_domains) in your Organization’s metadata.
Create an Action that:
- Gets the user’s domain through the
event.request.hostnameproperty - Compares that domain with both lists
- Allows or denies the user access accordingly
MCD provides access to custom domain metadata in Actions through the
event.request.hostname object. You can use this information along with the custom domain metadata configured in your tenant to implement domain-specific logic in your Actions.Custom domain attributes
MCD provides the following attributes related to custom domain verification and SSL/TLS certificate management. These attributes provide granular insights into the provisioning and operational status of custom domains.Updated attributes
| Attribute | Description |
|---|---|
status | A new enumeration value, failed, has been added to the status attribute. This value indicates that the custom domain verification process has encountered an error and was unsuccessful. This is in addition to the existing supported values pending and ready. |
New attributes
The following attributes are supported for Auth0-managed domains only:| Attribute | Description |
|---|---|
verification.status | Status of the DNS record verification process. Possible values are: verified, pending, and failed. |
verification.error_msg | In the event that verification.status indicates a failure, this string attribute will contain a human-readable error message providing context for the verification failure. |
verification.last_verified_at | This timestamp attribute records the date and time of the last successful verification of the custom domain. The format of this timestamp will adhere to ISO 8601. |
certificate | This object encapsulates information related to the SSL/TLS certificate associated with the custom domain. |
certificate.status | This attribute indicates the current provisioning status of the SSL/TLS certificate. Possible values will include states such as provisioning, provisioned, provisioning_failed, and renewing_failed. |
certificate.error_msg | If the certificate.status is provisioning_failed or renewing_failed, this string attribute will provide a user-friendly error message detailing the reason for the failure. |
certificate.certificate_authority | This string attribute specifies the Certificate Authority that issued the SSL/TLS certificate for the custom domain. |
certificate.renews_before | For Auth0-managed custom domains, this new timestamp attribute indicates the date and time before which the SSL/TLS certificate must be renewed. The format of this timestamp will adhere to ISO 8601. |
Limitations
The following limitations apply to Multiple Custom Domains:- WebAuthn/Passkeys: Each custom domain can have its own passkey enrollment. Users will need to enroll passkeys separately for each custom domain they authenticate through. Related origins support for shared passkey credentials across domains is planned for a future release.