Cloudflare for SaaS custom hostnames: setup, step by step
Short answer: you set up two things once, a proxied fallback origin and (optionally) a CNAME target, then for each customer you add a custom hostname and have them point a CNAME at your target. A hostname is live when Cloudflare reports both the hostname and its certificate as active. The parts that trip people up are the order of the DNS change and the certificate validation, and the bare-domain case, which a CNAME cannot cover.
Published · Cloudflare documentation retrieved
Before you start
Cloudflare for SaaS runs on a zone you own. Per Cloudflare's getting-started page, add that zone to Cloudflare (a Free plan is enough to begin), enable Cloudflare for SaaS on it, and read the hostname prioritization guidance, because wildcards behave differently from exact matches. The first 100 custom hostnames are included and each one after that is $0.10; the Cloudflare for SaaS cost comparison works through the totals.
Step 1: create the fallback origin
The fallback origin receives the traffic sent to your custom hostnames, and its record must be proxied. In your SaaS zone, create a proxied A, AAAA or CNAME record that points at your origin:
| Type | Name | Content | Proxy status |
|---|---|---|---|
A | proxy-fallback | 192.0.2.1 | Proxied |
Then open the Custom Hostnames page, enter that record's hostname under Fallback Origin, select Add Fallback Origin, and wait for the status to read Active. Cloudflare is explicit that Active only reflects that it is "ready to send traffic to that DNS record". It does not test your origin.
Step 2: create the CNAME target (optional)
Customers need something to point at. You can give them the fallback origin's name, but Cloudflare encourages a separate CNAME target: a proxied CNAME in your zone, such as customers.yourproduct.com, that points at the fallback origin. Customers then CNAME to the target, and you can move your origin later by changing one record of your own. Traffic flows customer domain, then CNAME target, then fallback origin.
Step 3: add the customer's custom hostname
On the Custom Hostnames page, select Add Custom Hostname, enter the customer's hostname (for example app.customer.com), and choose the minimum TLS version, the certificate validation method and, if needed, a custom origin. The same operation exists as the Create Custom Hostname API endpoint; its POST response may not include the DCV validation_records, so fetch the hostname again a moment later to read them.
Two things to know. Do not create a custom hostname that matches the zone name itself. And Cloudflare issues two certificates for each hostname, one P-256 (ECDSA) and an RSA 2048-bit fallback for older clients. Choosing a certificate authority, uploading your own certificate and enabling wildcards are Enterprise options (create custom hostnames, plans).
Step 4: choose when the certificate is validated
Cloudflare validates two separate things before a hostname works: the certificate, after which it deploys globally, and the hostname, after which it proxies traffic. Both must complete. What you choose here decides whether the customer sees downtime when they change their DNS, as set out on the certificate validation page:
| Method | How it proves control | Can finish before the DNS change? |
|---|---|---|
| TXT validation | The customer adds a TXT record to their authoritative DNS. | Yes. Required for wildcard custom hostnames. |
| Delegated DCV | A one-time record at the customer's authoritative DNS lets Cloudflare renew every future certificate order automatically. | Yes. |
| Automatic HTTP validation | The certificate authority fetches a token from the hostname. | No. The hostname must already point at your target, so it can route to Cloudflare before the certificate is active. (Manual HTTP validation, a TXT record at your origin, can finish earlier.) |
Hostname pre-validation also exists, to activate a hostname before the cutover. If brief downtime is unacceptable, use TXT or delegated DCV. If you would rather ask the customer for one record, automatic HTTP validation is less work for them.
Step 5: the customer adds their CNAME
The customer creates a CNAME at their authoritative DNS pointing at your target:
mystore.example.com CNAME customers.yourproduct.com
This step is the one you do not control, and it is where most support tickets start: the customer has to find the right DNS editor, enter the host in that provider's format, and wait for it to publish.
Step 6: confirm it is live
Treat a hostname as production-ready when both of these read active and the customer's record points at your target:
| Field | Means | Ready value |
|---|---|---|
result.status | Hostname validated for proxying. | active |
result.ssl.status | Certificate issued and deployed. | active |
The bare domain (apex) case
DNS does not allow a CNAME at the apex, so a customer who wants customer.com rather than app.customer.com cannot use the flow above. Cloudflare's answer is apex proxying: it assigns static IP prefixes to your account (or uses yours, with BYOIP), and the customer creates ordinary A records pointing at them. Cloudflare describes the prefixes as having an associated cost and lists Apex proxying/BYOIP on its plans page as a paid Enterprise add-on, so confirm eligibility with your account team before you promise it. Many products offer subdomains first; the apex domains page covers the patterns that work.
Where DoDomain fits
Cloudflare for SaaS handles the traffic side: it terminates TLS, issues the certificates and proxies requests to your fallback origin. It does not put the records into your customer's zone, and steps 4 and 5 are exactly that. DoDomain is the DNS side. Mint a session with the CNAME to your target and, if you use TXT validation, the TXT record Cloudflare gives you, and the hosted flow shows the customer the exact records for their provider, writes them with one click where the provider supports it, and verifies them against the authoritative nameservers. A signed connection.verified webhook then tells you the DNS is live. DoDomain does not issue certificates or sit in the request path; Cloudflare stays on the traffic side. The SSL notes cover the Cloudflare for SaaS handoff, and the five jobs of a custom-domain feature puts it in context.
Frequently asked questions
Do I need a fallback origin before I can add a custom hostname?
Yes. The fallback origin is where Cloudflare sends traffic for your custom hostnames, and its DNS record must be proxied. Create a proxied A, AAAA or CNAME record in your SaaS zone, then enter its hostname under Fallback Origin on the Custom Hostnames page. Active on that page only means Cloudflare is ready to send traffic to that record, not that your origin works.
Is the CNAME target required?
No, but Cloudflare encourages it. It is a proxied CNAME in your zone that points at the fallback origin, and customers point their own CNAME at it instead of at the fallback origin directly. That gives you one name you can repoint later without asking customers to change anything.
When is a custom hostname ready for traffic?
When both result.status (hostname validated for proxying) and result.ssl.status (certificate issued and deployed) are active, and the customer's DNS record points at your target. Cloudflare validates the hostname and the certificate separately and both have to finish.
Can I create a custom hostname that matches my own zone name?
No. Cloudflare's documentation says not to configure a custom hostname which matches the zone name.
Which certificate validation methods can finish before the customer changes DNS?
TXT validation and delegated DCV can both be completed before the DNS cutover. Automatic HTTP validation needs the hostname to already point at your target, so the hostname may route to Cloudflare before the certificate reaches ssl.status active, which can cause a short outage. Wildcard custom hostnames require TXT validation.
What if a customer wants to use their bare domain?
A CNAME is not allowed at the zone apex, so the CNAME flow does not cover it. Cloudflare's answer is apex proxying: it assigns static IP prefixes to your account so customers can create ordinary A records. Cloudflare's plans page lists Apex proxying/BYOIP as a paid Enterprise add-on, so check eligibility with your Cloudflare account team.
Start on the free plan
No card, no sales call — create an app, mint a session, and watch the first domain verify.
Sources
All Cloudflare pages retrieved 2026-10-07. Cloudflare revises these steps; check the page before relying on a field name.
- Cloudflare, Get started. The prerequisites, the fallback origin, the CNAME target, the per-hostname steps and the two status fields.
- Cloudflare, Create custom hostnames. The dashboard and API creation path, the zone-name restriction and the Enterprise-only options.
- Cloudflare, Validate certificates. The certificate validation methods and when each can run relative to the DNS change.
- Cloudflare, Apex proxying. What serving a customer's bare domain takes, since a CNAME is not allowed there.
- Cloudflare, Plans. Which custom hostname options are Enterprise-only.