Short answer: a customer can point www.example.com at your SaaS with a normal CNAME, but the root example.com needs another path. Offer an A record to an address your proxy controls, a DNS provider's ALIAS or CNAME-flattening feature, or a redirect from the root to www. The right instruction depends on the customer's DNS provider and on how your edge provisions HTTPS.
Why an ordinary apex CNAME fails
The DNS zone apex already has SOA and NS records. The DNS standard says a CNAME can't coexist with other data at the same name. Some DNS control panels accept an apex “CNAME” anyway because their authoritative service flattens it into address answers. That's a provider feature, not an ordinary CNAME response. Check the provider's documentation and the actual DNS answer.
Three customer-facing choices
| Choice | What the customer enters | Operational trade-off |
|---|---|---|
| A record | The root name and your proxy's IPv4 address. | Works at conventional DNS providers, but changing the address later requires customer DNS updates. |
| ALIAS or flattening | The root name and a hostname you control, using their provider's supported record type. | Allows indirection; availability and UI wording vary by provider. |
Redirect to www | A root-domain forwarding setup plus a CNAME for www. | Simple app hostname, but the root still needs an HTTPS-capable redirect service and a certificate. |
Cloudflare documents apex CNAME flattening; Route 53 documents alias records and their target restrictions. Don't assume a customer using one DNS provider can follow another provider's “@” instructions verbatim.
When an A record is the clearer product experience
An A record is often the least surprising instruction for customers whose provider has no apex alias feature. The cost is address coupling. Inventory every domain using that address before moving or retiring it, and rehearse how you would ask customers to change records.
We give your Approximated cluster a dedicated IPv4 address that serves its configured virtual hosts. Your customers can use an apex A record at their existing DNS provider, with the same edge handling their certificates and traffic. The address is per cluster, not a separate IP for every hostname. Our cluster documentation and Cloudflare comparison explain the available routes.
DNS can be correct while HTTPS is still pending
After the record changes, verify both the DNS answer and a certificate for the exact apex hostname. A redirect from https://example.com still needs a valid certificate at example.com before the browser will follow it. If the customer uses a CDN or proxy in front of your edge, test the real path because it can change how certificate validation reaches you. ACME challenge types explain why the validation route matters.
Don't collapse these observations into one “DNS verified” flag. Our virtual-host monitoring distinguishes DNS, SSL, and proxy-hit status. Our webhooks can carry those changes to your onboarding UI and support tools. Complete the check with an actual HTTPS request to confirm the origin and tenant.
Write instructions around the customer's hostname
- Ask whether they want the root, a subdomain, or both.
- Identify the DNS host that controls the zone; it may differ from the registrar.
- Show the record type, name, and value for that host, with a warning about conflicting old records.
- Check authoritative and public DNS answers, then test HTTPS and the application response separately.
- Keep the previous record values for a deliberate rollback during migration.
Our optional DNS widget presents provider-specific instructions and verifies the requested records inside your product. Pair it with your application's ownership checks and final request test. The onboarding checklist covers that sequence.
Apex support should keep working after setup
We build the apex path into the same dedicated cluster as your other customer domains. Our WAF and DDoS protection helps handle attacks and abusive traffic across the SaaS domains you serve, while Edge Verify can protect forms on those domains. Domain monitoring keeps DNS and certificate changes visible after launch.
If a customer's DNS setup gets complicated, our real engineering support can help you work through it. Our cloud pricing makes domain and bandwidth costs explicit. If you later need traffic and certificates on your own infrastructure, we offer a path to self-hosting; plan any address change and customer DNS migration with that deployment.
Frequently asked questions
Why can't a standard CNAME record be used at the domain apex?
A standard CNAME can't coexist with other records at the same DNS name. A zone apex already needs records such as SOA and NS, so a plain apex CNAME conflicts with the DNS model. Provider features called ALIAS, ANAME, or CNAME flattening work around that constraint through provider-specific behavior. Their availability and target restrictions vary.
Which DNS record should a SaaS customer use for a root domain?
Use an A record when your edge provides a stable IPv4 address, or a DNS-provider alias or flattening feature when that provider supports your target. We give each proxy cluster a dedicated IPv4 address that serves its configured customer domains, making an apex A record a straightforward option without requiring customers to change DNS providers.
Does redirecting an apex domain to www require an SSL certificate?
Yes, for an HTTPS redirect. A browser establishes TLS with the apex hostname before it can read the HTTP redirect to www or another hostname. The apex therefore needs a valid certificate even if it only redirects. Verify the certificate and the redirect separately, using the exact public hostname the customer will visit.
Does every customer apex domain need its own IP address?
What should I monitor after a customer apex domain connects?
Monitor DNS answers, certificate validity, and the real HTTPS response for the intended tenant. A customer can later change DNS or place another proxy in front of the route, so setup success isn't permanent proof. Our DNS, SSL, and proxy-hit monitoring and webhooks keep edge changes visible; application request checks confirm that the origin still serves the right content.