Shopify Customer Accounts Default to a shopify.com Domain — Connecting Your Own Takes More Than a CNAME Record
Every Shopify store's new customer accounts open on a shared shopify.com URL until you connect a subdomain of your own, and the admin panel makes that look like a five-minute DNS change. It usually is — until the store runs its DNS through Cloudflare's proxy, or has already wired up a third-party identity provider whose settings point at the domain you're about to replace. Neither failure mode shows up until a customer can't sign in.
New Shopify customer accounts open on a shared shopify.com/<store-id>/account address by default, not your storefront's domain. You can point it at your own subdomain — something like account.yourstore.com — from Settings > Customer accounts in a few clicks, and Shopify's own instructions make it look like nothing more than one CNAME record. For most stores it is. It stops being that simple the moment your DNS runs through Cloudflare's proxy, or you've already connected a third-party identity provider whose configuration still points at the domain you're replacing.
What the default domain actually is, and why it isn't a Plus thing
Every store that has completed the move to the current customer accounts system — mandatory since Shopify deprecated legacy accounts on February 26, 2026 — gets a default account URL built from shopify.com and a numeric store ID, or in some configurations an account.myshopify.com-style address. It's functional, it's secure, and it says nothing about your brand to a customer who lands on it mid-checkout.
It's worth being precise about which parts of customer accounts are plan-gated, because the two get confused constantly. Connecting your own custom identity provider over OpenID Connect — replacing Shopify's sign-in screen entirely — is a Shopify Plus feature. Connecting a custom subdomain for the existing account pages is not. Shopify's documentation doesn't gate it by plan, and in practice it works the same way on Basic as it does on Plus. If you've been holding off because you assumed this needed an upgrade, it doesn't — check Settings > Customer accounts and you'll see the option regardless of plan.
Connecting your own subdomain, step by step
The path splits depending on whether the domain is already managed inside Shopify or sits with an outside registrar.
- If the domain is Shopify-managed: go to Settings > Customer accounts, select Change domain, type the subdomain string you want (most stores use
account), save, then confirm it as the primary customer accounts domain under Settings > Domains. - If the domain sits with a third-party registrar (Cloudflare, GoDaddy, Namecheap, your own DNS host): create the same subdomain string inside Shopify first, then add a CNAME record at the registrar with the host set to your chosen subdomain (e.g.
account) and the value pointed atshops.myshopify.com. Return to Shopify and trigger verification.
Shopify states verification can take up to 48 hours to propagate, and in most cases it's faster — but that window is exactly long enough that a merchant who checks back after 20 minutes, sees a red "Invalid DNS" warning, and assumes the record is wrong will go looking for a different fix instead of just waiting. Confirm the record actually exists before you touch anything else: dig CNAME account.yourstore.com +short from a terminal will show you whether the CNAME resolves to shops.myshopify.com, independent of whatever status Shopify's admin is currently displaying.
The failure nobody's setup guide mentions: Cloudflare's proxy
If your domain's DNS is hosted at Cloudflare and the record for your main site uses Cloudflare's proxy (the orange cloud icon, as opposed to grey "DNS only"), copying that same setting onto the new customer-accounts CNAME breaks it. Shopify's own domain troubleshooting documentation is explicit about why: issuing and renewing an SSL certificate requires a validation challenge to reach Shopify directly, and "a Cloudflare proxy can block or interfere with these challenges, which delays or prevents certificate issuance and renewal." The same page states plainly that "Cloudflare proxy setups...aren't supported by Shopify" — a proxied record can appear to work for a while and then fail with no change on your end, because the setup was never actually supported, just tolerated until something on either side shifted.
In practice this shows up as a permanent "Invalid DNS" or "Needs Attention" status on the customer accounts domain that looks identical to a genuinely wrong CNAME value. Merchants who hit this on Shopify's community forums frequently report the record being correct by every check they can run, because it is — the proxy toggle is the actual fault, not the record itself. Set that specific CNAME to DNS only and leave the rest of your zone's proxy settings untouched.
The failure that breaks sign-in, not just the domain
Shopify's own documentation for this feature includes one explicit warning, easy to skip past if you're focused on the DNS side of the change: if you've configured a third-party identity provider or social sign-in options for customer accounts, you have to update those provider settings to include the new subdomain before you change the domain in Shopify, not after. Miss that ordering and every affected sign-in method fails the moment the domain switches, because the provider keeps redirecting customers back to a callback URL Shopify no longer recognizes for the session.
That warning covers two setups that are easy to conflate. If your store is on Plus and has connected a full custom identity provider under the OIDC setup we've covered separately, the redirect URI lives in that provider's own dashboard — Okta, Auth0, Entra ID — and has to be updated there first. If your store is on any plan and has turned on native Google or Facebook sign-in instead, the same rule applies to the OAuth app you registered in Google Cloud Console or Meta for Developers: the authorized redirect URI field there needs the new subdomain added before you touch Settings > Customer accounts. Stores running only the default passwordless email flow, with no social sign-in and no OIDC provider connected, don't have this exposure at all — there's no external redirect URI to update, so the domain change is DNS-only for them.
A short checklist before you touch the DNS record
Most of the support threads about this feature trace back to skipping one of these, not to Shopify's setup actually being broken:
- Pick a subdomain string that isn't already claimed. If
account.yourstore.comis already pointed at something else — a help desk widget, a landing page builder, an old MX record fragment — adding a second CNAME for the same host will conflict, and the error you'll see is generic rather than "this subdomain is already in use." Check your existing DNS records for the host string before creating it in Shopify. - Check every sign-in method you've actually enabled, not just the one you remember setting up. A store that turned on Google sign-in eighteen months ago and forgot about it will still break on a domain change if nobody updates that redirect URI, even if nobody currently thinks of the store as having "identity provider stuff" configured.
- Confirm the CNAME with
digbefore opening a support ticket. A record that hasn't propagated yet and a record that's wrong produce the same "Invalid DNS" message in Shopify's admin. Ten minutes with a terminal tells you which one you're looking at before you spend longer troubleshooting the wrong side of it. - Do the identity provider update in a low-traffic window anyway. Even done correctly and in the right order, there's a propagation gap between the DNS record resolving and Shopify treating the new domain as fully live — test a sign-in yourself in an incognito window before announcing the change to customers.
What a custom domain does not fix
Connecting your own subdomain changes the URL a customer sees. It doesn't change what's rendered on the pages behind it. If what you actually want is a custom login popup instead of Shopify's redirect-based flow, custom registration fields, or account-page branding beyond a logo and color scheme, that's Customer Account UI extensions territory, and it's a materially bigger project — we've covered what that rebuild actually involves in our guide to rebuilding after the legacy accounts deprecation. And if customers are reporting they "can't log in" rather than complaining about the URL, a domain change won't touch that; the causes are almost always delivery or verification-code related, which we cover separately in full.
Who should skip this
If your store still shows classic customer accounts as active rather than the current system, fix that first — the custom-domain setting described here lives inside the new customer accounts admin and isn't available until you've migrated. If you're mid-migration with a launch date already on the calendar, bundle the domain change into that cutover rather than doing it twice; there's no benefit to pointing a subdomain at the interim state. And if your store gets negligible traffic to account pages specifically — no login-gated content, no order history checks, nobody bookmarking the account URL — this is genuinely cosmetic, and the 48-hour propagation window and Cloudflare troubleshooting above aren't worth spending against a problem nobody's actually hitting.
Most of the failures here aren't Shopify bugs — they're the two places DNS and identity configuration sit outside Shopify's own control, which is exactly where a setup guide written from the admin screen alone won't warn you. If your store runs through Cloudflare, has a custom identity provider connected, or you'd rather have someone check the DNS and redirect URIs before the switch than after, that's the kind of Shopify customer-accounts work we take on directly — get in touch and we'll tell you plainly what your specific setup needs before you touch a CNAME record.