Every vertical SaaS platform ends up building the same four things for its customers: a customer portal, an invoice and payment page, a quote or booking link, and transactional email. A pool service company sends clients a portal link. A plumber texts a quote. A salon emails a receipt.
All those surfaces are front facing for your customers' customers — people who didn't buy your software and have never heard of you. When those links point to pay.yourplatform.com/acme-4471, or the email comes from noreply@yourplatform.io, your customer pays a tax on every one of them in trust and in conversion. Your platform collects nothing from it.
This post covers what that tax costs, why most platforms still haven't removed it, and how to remove it without signing your team up for a permanent DNS support desk.
Payment pages on an unknown domain look like fraud
Start with the surface that matters most. Invoice and payment pages show up in nearly every vertical SaaS product, and they're where an unfamiliar domain does the most damage.
A homeowner gets a text saying their invoice from Sparkling Pools is ready, followed by a link to a domain they've never seen. After years of fake delivery notices and toll-payment scams, their first thought is that it's a phishing attempt. Some ignore it. Some call the business to ask whether it's real. Some pay, then dispute the charge when they don't recognize the name on their statement.
All of that lands on your customer: invoices paid late or not at all, phone calls they have to answer, and disputes they have to fight. The same link on pay.sparklingpools.com looks like it came from the business the homeowner hired, because it did.
A shared sending domain means shared reputation
Transactional email is the one surface every platform has, and it's the one where the platform's setup can hurt its customers directly.
When every customer's invoices and reminders go out from noreply@yourplatform.io, they all share one sender reputation. If one customer sends spammy messages or emails a bad list, inbox providers lower their trust in the whole domain, and everyone else's mail suffers. Your merchant's unpaid-invoice reminder lands in the promotions tab or in spam, and they never find out why.
The sender requirements Gmail and Yahoo introduced in 2024 raised the stakes. Senders now need SPF and DKIM authentication, and bulk senders also need a DMARC policy aligned with the domain in the From address. Sending from each customer's own authenticated domain keeps their reputation separate from everyone else's.
Your customers lose the search value they're paying for
For booking sites and other public pages, every merchant page that lives at yourplatform.com/john-cuts or john.yourplatform.com builds nothing the merchant owns, so they struggle to show up when local clients search for them. The reviews, service descriptions and local backlinks a small business earns never build up on a domain they own.
The workarounds some platforms offer don't fix this. With domain forwarding, the merchant buys a domain, points it at you, and visitors get redirected to your URL anyway. With masked forwarding, your page loads inside a frame, so the address bar shows the merchant's domain while search engines still credit your page. Either way, the merchant paid for a domain that does very little for them.
A custom domain is a switching cost that works in your favor
This is the argument that tends to move product roadmaps.
A customer on a vendor subdomain has nothing tying their business to your platform except the product itself. Once portal.sparklingpools.com is printed on invoices, saved in clients' bookmarks, added to email signatures and painted on the truck, your platform is part of how the business presents itself. The portal links, payment links and email authentication records are all set up around you. Moving to another platform means redoing that setup and breaking every link clients have saved.
Custom domains look like a branding feature. In practice, they're retention infrastructure.
It's a feature your customers already value
Customers already expect to pay for a custom domain. Webflow requires a paid site plan to connect one, and ClickFunnels lets users buy a domain without leaving its product, which earns ClickFunnels six-figure annual revenue. The value is easy to see: their name instead of yours.
A platform that gives every customer a free domain provides more value to their users and makes it harder to leave.
Why platforms haven't fixed this yet
Platforms don't skip custom domains because they don't see the value. They skip them because DNS is some of the worst user experience in software, and supporting it never ends.
The problems are specific:
Apex domains can't take a CNAME record. Serving sparklingpools.com itself, rather than a subdomain, means relying on ALIAS or ANAME records, CNAME flattening or a fixed IP address, and support for those varies by DNS provider.
SSL certificates have to be issued and renewed for every customer domain, automatically, with no gaps.
Existing records conflict with new ones. An old A record or a parked-domain setting can break the setup without an obvious error.
SPF allows only one record per domain and a maximum of 10 DNS lookups. Add your platform's include to a customer who already sends through Google Workspace, a marketing tool and a CRM, and you can push them over the limit and break authentication for all of their email.
Many small business owners don't know which registrar holds their domain, or where the login is.
Writing the help article for custom domains takes about a week. Supporting it never stops. That trade-off is why so many platforms stop at a vendor subdomain.
How to build custom domains well
If you decide to offer custom domains, these are the decisions that matter most.
Default to a subdomain. Ask customers to connect pay.sparklingpools.com or book.sparklingpools.com, not the bare sparklingpools.com. A subdomain needs one CNAME record, leaves the customer's existing website alone and avoids the apex-domain problem entirely. Add apex support later, if at all.
Verify before you provision. Have the customer add a TXT record that proves they control the domain before you issue a certificate or route any traffic. Otherwise you'll be issuing certificates for domains nobody has finished setting up, or that someone else owns.
Route by Host header. Point every customer domain at the same infrastructure and let your app decide which customer to serve from the Host header on each request. Keep a lookup table of verified domains, and serve nothing for hosts that aren't in it.
Automate certificates with ACME. Use an ACME certificate authority such as Let's Encrypt to issue a certificate as soon as a domain is verified, and renew it automatically before it expires. Alert on renewal failures. An expired certificate on a payment page does more damage than no custom domain at all.
Handle email separately. Sending from the customer's domain means adding DKIM records and merging your SPF include into their existing SPF record, never adding a second one.
Plan the fallback. Automation will fail for some customers: a provider with no API, a conflicting record, a domain still locked by a previous provider. Decide ahead of time what happens next, with manual instructions for that provider, a status screen that shows exactly which record is missing, and a support path that doesn't start from zero.
Where guided DNS setup fits
Most of the cost above comes from one step: showing customers a table of records and asking them to go find their registrar. Guided DNS onboarding replaces that step. It detects where the customer's domain is managed, has them sign in to that provider and writes the records for them, then checks that everything resolves.
This is what Entri does. Entri Connect handles the DNS step inside your onboarding flow, including the records for email authentication, across the providers your customers use. Entri Power and Entri Secure cover the infrastructure side, serving customer domains and provisioning SSL certificates for them. Entri Monitor alerts you when a customer's records change, so a broken portal or payment page doesn't go unnoticed. And Entri Sell lets customers who don't have a domain yet buy one inside your app, which adds revenue.
Your customers pay the subdomain tax on every invoice, email and booking link they send. Removing it helps them get paid and trusted, and it gives your platform a product that's harder to leave and more valuable to every customer who uses it.
Book a demo to see how Entri fits into your onboarding.