Branded Email Style Resolution

A branded email template built in the Email Templates section renders with dynamic branding placeholders that adapt to your Auth Studio branding. When LoginRadius sends the email, it hydrates those placeholders from a specific Auth Studio Style, so the message matches the login page the user just came from.

This page explains which Style is applied when the email is sent, starting from the simplest deployment and building to a full multiple-custom-domain setup. If you run a single template on one domain, the first two sections are all you need.

How Style Resolution Works

Branding placeholders in a branded (V3) template are hydrated from the CSS variables of one Auth Studio Style at send time. The Style chosen is the one that renders on the Auth Studio page the email was triggered from, so the email stays consistent with what the user sees on screen. For the placeholder-to-variable mapping, see Branding placeholders.

When more than one Style could apply, LoginRadius resolves them in this order, from highest priority to lowest.

The s= query parameter on the request URL, if present.
The default Style mapped to the custom domain, if one is configured.
The template's default Style set in Auth Studio.

Placeholder hydration runs only for V3 template deployments. A legacy V2 template renders branding placeholders as literal text, so use static branding values in a V2 template.

Single V3 Template

A single V3 template deployed on the LoginRadius Hosted Domain or one custom domain resolves to the Style rendered on the page that triggered the email.

When the user lands on the hosted or custom domain and triggers an email from an action on the Auth page, the email uses the template's default Style, matching the page the user sees.
When the login page is opened with a specific Style through the s= parameter, for example ?s=dark, the email uses that Style instead, keeping the message consistent with the variant on screen.

The value of s= is the name of a Style set in the template. For how Styles and the s= parameter work, see Styles.

Single V2 Template (legacy)

A single legacy V2 template does not participate in dynamic style resolution. V2 is a static deployment, so branding placeholders are not hydrated and no Auth Studio Style is applied to the email.

Set the branding directly in the template with fixed values (colors, fonts, and layout), and manage each variant as its own template. To migrate to dynamic branding, move the domain to a V3 Auth Studio template.

Multiple Custom Domains

When different Auth Studio pages are deployed on different custom domains, including the hub domain, each domain resolves the Style independently. An email triggered from a domain uses that domain's applied Style, so the message matches the brand the end user sees on that domain's login page.

Consider two custom domains, acme.com and acme.in, plus the hub domain acme.hub.loginradius.com, with three pages that each hold Styles a, b, and c.

Page A is deployed on acme.com, with the custom domain's default Style set to a.
Page B is deployed on acme.in, with no default Style set on the domain, so the page's Auth Studio default c applies.
Page C is deployed on the hub domain, with the page's Auth Studio default set to b.

Emails triggered from each request resolve as follows.

Request	Applied Style	Why
`acme.com`	Style `a` of page A	The default Style mapped to the custom domain.
`acme.com?s=b`	Style `b` of page A	The `s=` parameter overrides the domain's default Style.
`acme.in`	Style `c` of page B	No domain default is set, so the page's Auth Studio default applies.
`acme.in?s=a`	Style `a` of page B	The `s=` parameter overrides the page default.
`acme.hub.loginradius.com`	Style `b` of page C	The page's Auth Studio default on the hub domain.
`acme.hub.loginradius.com?s=c`	Style `c` of page C	The login page renders Style `c`, so the email matches it.

For how to map domains to templates and set a per-domain default Style, see Multiple Custom Domains.

Mixed V2 and V3 Domains

Domains can run different template versions at the same time, and each domain resolves independently. Style hydration continues to work on every domain that serves a V3 template, following the resolution order above. Domains that serve a legacy V2 template do not hydrate placeholders.

For a domain on a V2 template, create a separate email template with static branding and pass its name through the SDK common options, so that domain sends a correctly branded static email. The Options reference lists the per-action template options, such as verificationEmailTemplate, resetPasswordEmailTemplate, and passwordlessLoginEmailTemplate.

// Point a V2 (legacy) domain at statically branded email templates
const options = {
  apiKey: process.env.LR_API_KEY,
  verificationEmailTemplate: "verification-static-acme",
  resetPasswordEmailTemplate: "reset-password-static-acme",
};

Best Practices

Prefer V3 templates for dynamic branding: Only V3 deployments hydrate branding placeholders from the applied Style, so migrate legacy domains for consistent styling.
Set a default Style per domain: Map a default Style on each custom domain so emails resolve predictably even without an s= parameter.
Match the s= parameter across the journey: Carry the same s= value users open the login page with, so the email Style matches the on-screen variant.
Keep static fallbacks for V2 domains: Maintain statically branded templates and reference them through the SDK common options for any domain still on V2.
Verify on each domain: Trigger a test email from every mapped domain to confirm the resolved Style is the one you expect.