The URL bar is the most-visible piece of branding subscribers see — more visible than the logo, the colors, or the typography. A subscriber who lands at portal.yourstore.com feels like they're on your store; the same subscriber landing at yourstore.recurring-vendor.com feels like they're on a vendor's product even if the portal interface itself is perfectly themed. Custom domain is also a deliverability feature: subscription emails sent from a domain that matches the portal URL are less likely to be flagged as phishing by mail providers. This guide is purely about the URL layer — the DNS records, the SSL, the verification. For brand removal in the portal UI itself see white-label subscription portal; for the broader portal customization workflow see customize your subscription portal.
Why a custom domain matters more than it looks
The trust argument is the most direct one. Subscribers who land at portal.yourstore.com see a URL bar that matches the store they bought from. Subscribers who land at yourstore.app.recurring-vendor.com see a URL bar with a vendor's name they may not recognize, and a non-trivial fraction of them check the URL twice, hesitate before signing in, or close the tab thinking it might be a phishing email. The conversion gap on the magic-link login flow alone is significant — measured in single-digit percentage points but stacked across every renewal cycle, it's real money.
The deliverability argument is more technical and more important. Email providers (Gmail, Outlook, Apple Mail) increasingly weight the alignment between the From domain and the URLs inside the email body. A magic-link email sent from [email protected] that contains a link to yourstore.app.recurring-vendor.com looks structurally suspicious — the email and the destination don't match. Aligned (yourstore.com email + portal.yourstore.com link) clears the suspicion entirely.
- Trust: URL bar matches the store; no 'who is this vendor?' moment
- Deliverability: mail providers favor emails whose URLs align with the sender domain
- Phishing resistance: subscribers can verify legitimacy by checking the URL against the store they know — a vendor URL provides no such anchor
- Bookmark and share-friendly: portal.yourstore.com is memorable; the vendor URL isn't
- SEO / brand consistency: all your customer-facing surfaces sit under one root domain
If you do one customization on your subscription portal, do this. The change in subscriber perception from a vendor URL to a custom domain is larger than every visual theming setting combined. The setup is under 10 minutes once DNS propagates. There's almost no reason not to do it.
Picking the subdomain: portal vs account vs subscriptions
The most common choice is portal.yourstore.com. It's descriptive, it's short, and it's what subscribers from other stores have probably seen before. The next most-common is account.yourstore.com, used when the subscription portal is part of a broader account-management experience.
- portal.yourstore.com — most common; explicitly subscription-focused
- account.yourstore.com — broader scope if you have other account features (loyalty, wishlist, etc.)
- subscriptions.yourstore.com — more verbose but explicit
- my.yourstore.com — shortest; consumer-friendly tone (Apple's pattern: my.account.apple.com)
- members.yourstore.com — works if you're framing subscriptions as a membership
Pick one and stick with it — changing the portal URL later means re-issuing magic-link emails for old subscribers, updating bookmarks, and breaking links in past confirmation emails. Choose the name that matches your brand voice and the broader account scope you might add later.
Some merchants try to put the portal at yourstore.com/subscription or yourstore.com directly. This doesn't work cleanly because the portal needs to run on its own origin (cookies, sessions, SSL boundary). The portal must live at a subdomain — portal.yourstore.com, account.yourstore.com, etc. If you want the portal to feel like part of the storefront, link to it from yourstore.com/account but host it at the subdomain.
The DNS records: CNAME plus optional TXT verification
Setup involves two DNS records: a CNAME that points your chosen subdomain at the subscription app's origin server, and (on some apps) a TXT record used for domain ownership verification before the app provisions SSL. Both records go in whichever DNS provider hosts your domain — Cloudflare, Route 53, GoDaddy, Namecheap, whoever.
# DNS records to add at your DNS provider
# 1. CNAME — points your subdomain at the subscription app's origin
Type: CNAME
Name: portal # produces portal.yourstore.com
Value: portal-origin.simplerecurring.app
TTL: 3600 # 1 hour; lower (300) during initial setup
# 2. TXT — domain ownership verification (some apps only)
Type: TXT
Name: _portal-verify
Value: portal-verify=abc123randomtoken
TTL: 3600After saving the records, DNS propagation typically takes 1–10 minutes. You can verify propagation with a tool like dnschecker.org or by running dig portal.yourstore.com from a terminal. Once the CNAME resolves and the TXT record is visible, return to your subscription app admin and click 'Verify domain'.
- In the subscription app admin, go to Portal settings → Custom domain and enter your chosen subdomain (e.g. portal.yourstore.com)
- The app shows the exact CNAME target and any TXT verification token you need to add
- Open your DNS provider and add the CNAME record pointing your subdomain to the app's origin
- If a TXT verification record is shown, add it too (some apps skip this step and verify via CNAME resolution alone)
- Save the records with a low-ish TTL (300–3600 seconds is fine)
- Wait 1–10 minutes for propagation; verify with dnschecker.org or dig
- Return to the app admin and click Verify domain. The app provisions a Let's Encrypt SSL certificate automatically
- Once verification succeeds, the portal is live at your custom domain. Update any hard-coded portal URLs in your email templates or storefront
SSL provisioning: how the certificate gets issued
Once your CNAME resolves and the verification step completes, the subscription app requests an SSL certificate from Let's Encrypt on your behalf. Let's Encrypt issues a free certificate after a brief automated challenge (typically HTTP-01 or DNS-01) that proves the app controls the domain. The certificate is installed on the app's edge servers, traffic to portal.yourstore.com is routed there with full HTTPS, and you don't need to do anything else.
Certificates auto-renew every 60–90 days. The app handles renewal in the background. If a renewal fails — usually because DNS has changed in the meantime — you'll get an email warning before the certificate expires. The failure case is rare; most stores never need to touch SSL again after the initial setup.
The admin will show 'SSL provisioned' as soon as the certificate is issued. The real test is opening portal.yourstore.com in an incognito window and confirming the padlock appears, the certificate is valid, and no mixed-content warnings appear. Run this check immediately after provisioning, then again after the first auto-renewal cycle (~60 days later) to confirm renewal works.
If you ever need a higher-trust certificate (Extended Validation or organization-validated), some apps support uploading your own cert instead of using Let's Encrypt. This is rare — Let's Encrypt is trusted by all major browsers and the EV badge has been deprecated from URL bars for years — but the option exists if you have a specific compliance requirement.
The Cloudflare proxy gotcha that trips up most setups
If your DNS provider is Cloudflare — and it is for a significant fraction of Shopify stores — there's one specific setting that breaks the custom domain setup, and it's the single most common cause of 'verify domain' failing repeatedly. Cloudflare offers two modes for each DNS record: DNS-only (grey cloud icon) and Proxied (orange cloud icon, the default for new records).
For subscription portals, the CNAME needs to be set to DNS-only (grey cloud). Proxied mode means Cloudflare intercepts traffic and terminates SSL at their edge, which conflicts with the subscription app's SSL provisioning — Let's Encrypt can't complete the challenge because Cloudflare answers first. The app then can't issue the certificate and verification fails.
If you're on Cloudflare and verify-domain keeps failing, the proxy status is almost always the cause. Toggle the cloud icon from orange (proxied) to grey (DNS-only) for the portal CNAME, wait a minute for the change to propagate, then re-try verification. This single change fixes maybe 80% of all 'verify domain failed' issues on Cloudflare-hosted DNS.
Once verification succeeds and SSL is provisioned, you can leave the record on DNS-only permanently — Cloudflare's other benefits (DDoS protection at the origin, caching) don't apply usefully to a subscription portal anyway. The portal is dynamic per-subscriber, so caching at the edge would mostly cause stale-data problems, and DDoS protection is handled at the subscription app's infrastructure level.
- Cloudflare: grey cloud (DNS-only) on the portal CNAME — orange cloud breaks SSL provisioning
- Route 53: standard CNAME works without special config
- GoDaddy / Namecheap: standard CNAME works; some have a 'forwarding' option you should avoid (use a real CNAME)
- Shopify-managed DNS (if you bought the domain through Shopify): standard CNAME works
Troubleshooting: when verification fails
Verification can fail for a handful of reasons. The error messages from subscription apps tend to be terse, so here's how to diagnose each common case yourself.
- 'CNAME not resolving' — DNS hasn't propagated yet. Wait 5–10 minutes and retry. Verify with
dig portal.yourstore.comor dnschecker.org. - 'CNAME resolves but points to the wrong target' — you typed the CNAME target slightly wrong. Double-check the exact hostname in the app admin (don't add http:// or trailing dots).
- 'SSL challenge failed' — usually Cloudflare proxy is on. Toggle to grey cloud (DNS-only). If not on Cloudflare, check that the CNAME isn't going through a URL-forwarding service.
- 'TXT record not found' — the verification TXT didn't propagate or you put it on the wrong record name. The record name is typically
_portal-verifyor similar — check the app admin for the exact format. - 'Domain already in use' — another subscription app or service is already using this subdomain. Pick a different one (e.g. account.yourstore.com instead of portal.yourstore.com).
- 'SSL provisioned but browser shows 'not secure'' — wait a few minutes for the certificate to fully propagate to all edge nodes. If it persists past 30 minutes, contact the app vendor.
- Run
dig portal.yourstore.com— does it resolve to the expected CNAME target? - Open dnschecker.org and check the subdomain across multiple regions — has propagation completed globally?
- If on Cloudflare, confirm the CNAME is grey cloud (DNS-only)
- Confirm there's no conflicting A record on the same subdomain — A and CNAME can't coexist on the same name
- Verify the CNAME target exactly matches what the app admin shows — no typos, no trailing dot, no extra subdomain
- If TXT verification is required, run
dig TXT _portal-verify.yourstore.com— does the token match? - Try the verification again in the app admin; some apps cache the failure for a few minutes
- If still failing, contact the app vendor with the exact error message and dig output
Aligning the portal domain with your email-sender domain
A custom domain on the portal is half the deliverability story. The other half is sending transactional emails from a matching domain. If your portal lives at portal.yourstore.com but the magic-link email comes from [email protected], the mismatch hurts deliverability and confuses subscribers.
Configure transactional email to send from your domain too — typically [email protected], [email protected], or a subdomain like notifications.yourstore.com. The setup is SPF, DKIM, and DMARC records in your DNS. The subscription app should provide the exact records to add. Don't skip DMARC — it's increasingly required by Gmail and Outlook for bulk transactional senders. The full email setup is covered in the subscription email and SMS providers guide.
Subscribers (and email providers) trust messages most when the portal URL and the sender email share the same root domain. portal.yourstore.com + [email protected] is ideal. portal.yourstore.com + [email protected] is a red flag for both subscribers and mail providers. Use one domain everywhere a subscriber sees your brand.
Migrating an existing portal to a custom domain
If you already have an existing portal running on a vendor URL and want to switch to a custom domain, the migration is straightforward but has a few subscriber-facing edges to manage.
- Set up the custom domain in admin without disconnecting the existing vendor URL — most apps support both running simultaneously during the switchover
- Once SSL is provisioned and the new URL works, send a one-time announcement email to active subscribers explaining the URL change
- Update any hard-coded portal URLs in your storefront, FAQ, support docs, and Klaviyo/email-marketing templates
- Re-send the magic-link to subscribers using the new URL — the old magic-link tokens may still work but the URL in them points to the old domain
- Monitor support tickets for the first week — some subscribers will have bookmarked the old URL; respond with the new URL
- After 30 days, you can deprecate the old URL if your app supports doing so (or leave both active permanently for safety)
The migration risk is low. Subscribers will typically use the new URL transparently because they navigate via magic-link emails (which are now generated with the new URL) rather than typed bookmarks. The bookmark/typed-URL fraction is small and handled by the announcement email.
Custom domain portal FAQ
How long does the custom domain setup take?
Under 10 minutes including DNS propagation: enter the subdomain in admin (1 min), add the CNAME record at your DNS provider (2 min), wait for propagation (1–5 min), click Verify in admin (instant), SSL provisions automatically (1–2 min). The longest variable is DNS propagation, which is usually fast but can occasionally take longer.
Do I need a developer to set up the custom domain?
No. The DNS provider's admin UI is a form with three fields (record type, name, value). If you've ever pointed a domain at Shopify, you've done a more complex version of this. If you're not comfortable with DNS at all, your domain registrar's support team can add the records for you in 5 minutes.
What if I'm on Cloudflare and verify keeps failing?
Toggle the portal CNAME from proxied (orange cloud) to DNS-only (grey cloud). This is the single most common cause of verify failures and the fix takes 30 seconds. Once SSL is provisioned, you can leave it on DNS-only permanently — Cloudflare's proxy benefits don't apply usefully to a dynamic subscription portal.
Is SSL automatic or do I need to upload a certificate?
Automatic via Let's Encrypt. Once your CNAME resolves and the domain is verified, the subscription app requests, installs, and auto-renews the SSL certificate for you. Renewals happen every 60–90 days in the background. You don't need to manage anything manually — but verify in browser after the first auto-renewal cycle just to confirm.
Can I use the apex domain (yourstore.com) instead of a subdomain?
No. The portal needs to run on its own origin (cookies, sessions, SSL boundary), which means it must live at a subdomain — portal.yourstore.com, account.yourstore.com, etc. You can link to it from yourstore.com/account but the portal itself lives at the subdomain.
Can I move the portal to a different subdomain later?
Yes, but it requires re-running the setup process for the new subdomain and migrating subscriber bookmarks via an announcement email. Most stores never move once they've picked a subdomain. Choose carefully on first setup.
What happens if my DNS provider changes (e.g. switching from GoDaddy to Cloudflare)?
Re-create the CNAME record at the new provider with the same target. The subscription app's SSL provisioning will continue working as long as the CNAME resolves correctly. Plan the switch during a low-traffic window — there's typically a few minutes of DNS propagation where the portal is unreachable.
Can I use a custom SSL certificate (e.g. an EV cert from a paid CA)?
Some apps support uploading your own certificate. Most don't — Let's Encrypt covers 99% of needs and is trusted by all browsers. The EV badge has been deprecated from browser URL bars since 2019, so there's no meaningful visual difference between Let's Encrypt and an EV certificate. Only consider a paid certificate if you have a specific compliance requirement that mandates one.
Does the custom domain affect SEO?
Not directly — subscription portals are gated behind magic-link login and aren't typically indexed. But hosting the portal on your root domain helps with brand cohesion and email deliverability, both of which indirectly benefit overall trust.
What if I have multiple stores — can I use one custom domain across all of them?
Each store needs its own subdomain (portal.store1.com, portal.store2.com). One subdomain can't serve multiple stores because the SSL certificate and routing are scoped to one subscription contract set. Some apps support market-aware configuration where one subdomain serves a single store across multiple Shopify markets.
Will subscribers get logged out when the URL changes?
If you migrate from a vendor URL to a custom domain, magic-link tokens issued against the old URL may not work on the new one — but new magic-link emails (sent automatically on the next login) will use the new URL transparently. Most subscribers won't notice. For the small fraction that had the old URL bookmarked, the announcement email gets them to the new one.
What if SSL fails to auto-renew?
You'll receive an email from the subscription app before the certificate expires. The fix is usually to re-verify the domain (CNAME may have changed, or DNS may have a temporary issue). If you ignore the email and the cert expires, the portal becomes unreachable until you fix it — so respond to the email when you get it.