Learn how authentication custom domains and multiple domains improve conversion, security, and branding; and how Logto helps you manage them without DNS headaches.
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.
There’s a reason nearly every large company uses some form of:
login.company.comauth.company.comaccounts.company.comThey’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:
Let’s keep it simple.
Every Logto tenant ships with a default domain: {{tenant-id}}.app.logto. So the moment that used to send users to: https://my-tenant-123.app.logto/sign-in.
An authentication custom domain swaps that visible URL for one you own—say auth.example.com. Now keeps users on-brand at: https://auth.example.com/sign-in.
Same authentication service under the hood. Very different first impression.
With Logto, custom domains are designed to work as subdomains, such as:
auth.example.comauth.us.example.comPractically, this is what you want for auth anyway:
example.com).domains.logto.app for traffic routing.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.
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.
Imagine a diagram where the user’s browser starts at:
Browser address bar
https://example.com.https://auth.example.com/sign-in.Authorization server & discovery document
https://auth.example.com/oidc/.well-known/openid-configurationRedirect URIs (OIDC/OAuth callbacks)
https://app.example.com/callbackSocial login / enterprise SSO hops
auth.example.com, the user might jump to Google, Microsoft Entra ID, Okta, etc.Emails and magic links / password reset links
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.
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.
Here’s how different teams typically map domains to their authentication experiences:
| Scenario | Example domains | Why it helps |
|---|---|---|
| One branded login | auth.example.com, account.example.com | Keeps the address bar on-brand while the default {{tenant-id}}.app.logto domain stays available for testing. |
| Regional experiences | auth.us.example.com, auth.eu.example.com, auth.apac.example.com | Localize content, consent flows, and compliance notices per geography inside a single tenant. |
| Environment guardrails | auth.staging.example.com, auth.example.com | Isolate QA and preview traffic without cloning every tenant or connector. |
| Per-organization branding | auth.customer-a.com, auth.customer-b.com | Offer white-labeled entry points for enterprise customers while managing users, orgs, and SSO centrally. |
| Brand or product lines | auth.shop.example.com, auth.app.example.com, auth.studio.example.com | Give each brand a cohesive login experience without fragmenting your identity stack. |
| Multiple TLDs | auth.foo.com, auth.foo.co.uk, auth.foo.dev | Support country sites or special-purpose domains without replicating configuration region by region. |
| Infrastructure-driven | auth.edge.example.com, auth.api.example.com | Align with CDN or edge routing rules while Logto stays the identity backend behind those hosts. |
Here’s what Logto gives you out of the box, without turning you into a DNS or PKI specialist.
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.endpoint, while social and enterprise SSO connectors list every valid redirect URI or ACS URL for each domain—no manual URL juggling.If you’ve read this far, you’re probably in one of two camps.
You can start experimenting with multiple custom domains right away:
endpoint where appropriate.It’s an easy way to clean up your login experience and test the impact on user trust and conversion.
If you’re just getting started:
auth.example.com as your public-facing login domain from day one.{{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.