What is authentication custom domain and why multiple domains matter

If you’ve ever shipped a product a bit too quickly, this story will feel familiar.

Your app lives happily at example.com. Marketing is running campaigns, users are signing up, everything looks polished. Then a new user clicks Sign in.

Instead of a familiar URL like auth.example.com, the browser jumps to something that looks like a test environment: my-tenant-123.app.logto

Technically, nothing is wrong. The page is secure. The login still works.
But the user’s first reaction is:

“Wait, where did I just go?”

That one second of doubt is where drop‑offs happen.

• From a conversion point of view, sign-in and sign-up are the narrowest part of your funnel. Any extra “What is this domain?” moment creates friction.
• From a security point of view, users have been told “check the URL” for years. If the login domain doesn’t match your brand, it looks more like phishing than production.

There’s a reason nearly every large company uses some form of:

• login.company.com
• auth.company.com
• accounts.company.com

They’re not doing it for fun. They’re doing it because the login domain is part of the product experience.

In this post, we’ll look at:

• What an authentication custom domain actually is
• When one login domain is enough — and when you should plan for multiple
• The most common mistakes with login domains (and how to avoid “redirect URI does not match” hell)
• How Logto’s custom domain support helps you do all this without becoming a full-time DNS engineer

What is an authentication custom domain?#

Let’s keep it simple.

Every Logto tenant ships with a default domain:

An authentication custom domain swaps that visible URL for one you own—say auth.example.com—while the identity service underneath stays exactly the same.

So the moment that used to send users to: https://my-tenant-123.app.logto/sign-in

now keeps them on-brand at: https://auth.example.com/sign-in

Same authentication service under the hood. Very different first impression.

Why subdomains, not root domains?#

With Logto, custom domains are designed to work as subdomains, such as:

• auth.example.com
• auth.us.example.com

Practically, this is what you want for auth anyway:

• Root domains are usually reserved for your main site (example.com).
• The DNS “zone apex” can’t use a CNAME, and Logto’s hosted sign-in requires a CNAME to domains.logto.app for traffic routing.
• Logto manages certificates through Cloudflare. To terminate TLS on a root domain we would need to control that entire zone (including your existing A, MX, TXT, etc.), which isn’t viable for a multi-tenant SaaS.

Apex-flattening records (ALIAS/ANAME) still resolve to IPs we don’t own, so they can’t back our managed certificates. In short, the hosted sign-in has to live on a subdomain. Point that subdomain to Logto with a CNAME and we’ll handle verification, SSL, and uptime—your apex domain stays free to serve the rest of your site.

Why it’s not “just add a CNAME and done”#

A very common misconception:

“I’ll just add a CNAME to my DNS and I’m finished, right?”

Unfortunately, no.

Changing the visible login domain is only one part of the story. The moment you introduce a custom auth domain, you’re touching:

• The sign-in and registration page URL
  Users are now visiting https://auth.example.com/... for the hosted pages.

• OIDC / OAuth redirect URIs
  Your apps and connectors must use the same domain in their redirect/callback URLs, or you’ll get redirect_uri_mismatch type errors.

• Social logins & enterprise SSO (IdPs)
  Google, GitHub, Azure AD, Okta, etc., all validate redirect URIs or ACS URLs including the domain.

• Passkeys (WebAuthn)
  Passkeys are tied to the exact domain where they were registered. Change the domain, and those passkeys won’t work anymore.

• SDK configuration
  Your Logto SDKs use an endpoint that points to your tenant’s domain. If the endpoint uses the wrong domain, your app and the identity layer drift out of sync.

So, is there DNS involved? Absolutely.
But if you only think in terms of “I added a CNAME so I’m done”, you’ll almost certainly break something else.

A quick mental model: how the login domain flows through the stack#

Imagine a diagram (you don’t need to draw it, just picture it) where the user’s browser starts at:

1. Browser address bar

   • User clicks Log in on https://example.com.
   • They’re redirected to https://auth.example.com/sign-in.

2. Authorization server & discovery document

   • Your app uses the OpenID configuration endpoint at:
     https://auth.example.com/oidc/.well-known/openid-configuration
   • This tells your app where to send authentication requests and where to expect tokens.

3. Redirect URIs (OIDC/OAuth callbacks)

   • After the user signs in, Logto redirects back to your app at something like:
     https://app.example.com/callback
   • The IdP and your application both need to agree on those URLs.

4. Social login / enterprise SSO hops

   • From auth.example.com, the user might jump to Google, Microsoft Entra ID, Okta, etc.
   • Those providers also see and validate redirect URIs that include your custom auth domain.

5. Emails and magic links / password reset links

   • Links in emails should point consistently to your custom domain to avoid confusing users.

At each of these steps, the domain matters. When you introduce a custom login domain, you want that domain to flow through the whole chain in a consistent way.

That’s why a well-thought-out custom domain strategy is less about DNS tricks and more about coherent identity design.

Single vs multiple custom domains: not a trick question#

For many teams, a single custom domain like auth.example.com is perfectly fine. But as your product, geography, and customer base evolve, you’ll quickly hit limitations if you don’t plan ahead.

Let’s look at the main patterns we see in the wild.

Here’s how different teams typically map domains to their sign-in experiences:

How Logto makes custom domains easy#

Here’s what Logto gives you out of the box, without turning you into a DNS or PKI specialist.

• One tenant, many domains. Map regions, environments, customers, or brands to their own login hosts without cloning tenants. Plan limits apply, but the core promise stays: one identity backbone, many entry points.
• Default stays live. Adding auth.example.com doesn’t kill {{tenant-id}}.app.logto. Use the default for internal tools or gradual rollouts while production users hit the branded domain.
• Connectors auto-adjust. SDKs point to the right endpoint, while social and enterprise SSO connectors list every valid redirect URI or ACS URL for each domain—no manual URL juggling.
• SSL on autopilot. After you add the CNAME, Logto verifies DNS, provisions certificates, and keeps them renewed. No key management, no surprise expirations.

Where to go from here#

If you’ve read this far, you’re probably in one of two camps.

Already using Logto?#

You can start experimenting with multiple custom domains right away:

• Go to Console → Settings → Domains.
• Add a second custom domain for:
  • A new region you’re about to launch, or
  • A key enterprise customer that wants their own branded login, or
  • A dedicated staging or beta environment.

Then:

• Update the SDK endpoint where appropriate.
• Use the domain-aware redirect URIs and ACS URLs Logto provides for your connectors.

It’s an easy way to clean up your login experience and test the impact on user trust and conversion.

New to Logto?#

If you’re just getting started:

• Sign up for Logto and create a tenant.
• Use the free allocation of custom domains to set up auth.example.com as your public-facing login domain from day one.
• Keep the default {{tenant-id}}.app.logto domain handy for internal use or testing.

You’ll avoid the “this looks like staging” login URL problem entirely — and future you won’t have to unwind a messy domain migration when you’re already in growth mode.

Want the step-by-step setup details, including DNS records and troubleshooting?
Check out the full guide in our docs: Custom domains for Logto Cloud.