Hello @VitaliiS.52030 (Customer)​ Thank you for posting on our Community page!

The behavior you are experiencing is actually expected and stems from how Okta maps domain contexts to brands.

When you trigger an action like "Reset Password by Admin" directly from the Okta Admin Console, that action is executed under your default Okta administrative domain (e.g., okta-org-admin.pixtulate.com). Because Okta delivers email templates based on the domain used during the action, any emails triggered from the Admin Console UI will always pull the email template configured under your Default Brand.

While the documentation notes that an org with a single custom brand might try to carry over global theming (like basic colors or logos), any specific HTML or content customizations you made to the email template inside the Custom Brand tab are strictly bound to actions originating from your custom domain (custom.example.com).

To get your "Reset Password by Admin" emails to use your custom branding, you have two options depending on your operational needs:

Option 1: Copy the template to the Default Brand (Recommended)

If you only care about the visual branding (logo, colors, HTML content) and aren't concerned with the sender email address used for admin-triggered resets, the easiest fix is to duplicate the template.

1. In the Admin Console, go to Customizations > Brands.
2. Select your Default Brand (not the custom brand).
3. Navigate to Emails > Reset Password by Admin.
4. Paste the exact same custom HTML/branding that you configured in your custom brand.

Because the Admin Console operates in the Default Brand context, it will now use your customized template whenever an admin clicks the reset button.

Option 2: Trigger the reset via API using the custom domain

If you want the email to be fully processed by the Custom Brand (which is also required if you want the email to come from your custom sender email address rather than noreply@okta.com), you cannot trigger it via the Admin Console UI.

Instead, you must trigger the password reset programmatically using an API call that routes through your custom domain.

• API Call:POST [https://custom.example.com/api/v1/users/](https://custom.example.com/api/v1/users/){userId}/lifecycle/reset_password

Because the API request host (custom.example.com) matches your Custom Brand's domain, Okta will successfully map the request to the Custom Brand and use its specific email templates and sender settings.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.

Securing AI agents across your org? Join our upcoming Ask Me Anything on 8/5 about Okta for AI Agents. Ask our expert questions.

Hi @Paul S. (Okta, Inc.)​,

Thank you for the clarification. This makes sense for the case with one custom brand.

I have one additional question regarding a multi-brand setup.

Assume we have:

• One Default Brand
• Multiple Custom Brands
• Each Custom Brand has its own custom domain

For example:

• Custom Brand A → custom-domain-a.com
• Custom Brand B → custom-domain-b.com

If an admin triggers "Reset Password by Admin" from the Admin Console, the action is executed from the default Okta administrative domain.

In this scenario, how does Okta determine which brand/template should be used?

• Does it always use the Default Brand?
• Is there any priority or fallback logic when multiple brands exist?
• What is the recommended approach for organizations with multiple brands that need admins to trigger password reset emails with the correct branding?

Would the recommended approach be to use API-based password reset flows where the request can be sent through the required custom domain?

Thanks!