One flag. proxied=False flipped to proxied=True on one DNS record. That is the entire diff that closed the ticket. Getting to that one flag took the better part of an afternoon, two wrong root causes, and a live test domain nobody wanted to risk breaking.

Here’s the setup that flag lived in. The production app runs Cloudflare for SaaS. Customer domains are custom hostnames inside a single primary zone, each pointed at a custom origin via custom_origin_server = cf-origin.<your-zone>, which resolves to a dedicated fallback IP. A *.<your-zone> Origin CA cert covers SNI=cf-origin, so the edge can reach the origin and present a valid cert. The open question that day was whether a customer could put their apex, not just www, on Cloudflare through ALIAS or CNAME flattening.

To test it, we moved a test domain onto a second Cloudflare account, separate from the primary zone’s account, and grey-CNAMEd the apex to the SaaS fallback hostname. Cloudflare provisioned a cert. The cert issued. We called it done and moved on.

We never loaded the page. When we finally did: Error 1014, CNAME Cross-User Banned.

Theory one: the cert was proof enough

A cert issuing through Cloudflare for SaaS proves exactly one thing: DNS ownership validation passed. It says nothing about whether a request to that hostname returns a page. That gap between “the cert exists” and “the page serves” is why this ticket ate an afternoon instead of ten minutes. Theory one went out as soon as the page failed to load.

Theory two: cross-account CNAMEs are banned

The second theory sounded better than the first and was still wrong. 1014 is named “CNAME Cross-User Banned.” We had grey-CNAMEd across two different Cloudflare accounts, so we reasoned the ban was a permanent, structural property of cross-account CNAMEs. Test method invalid, throw it out, retest with a registrar that supports true ALIAS instead. That story cited the exact error name and reached a tidy conclusion about methodology. It also would have killed a test that had nothing wrong with it.

The side-by-side diff

We had two domains in nearly identical configurations behaving differently, so we stopped guessing and put them next to each other.

Domain A, a customer not on Cloudflare, had the identical grey cf-origin custom-origin record. Its hostname status was active, with a warning attached: The custom origin hostname you specified is a gray clouded DNS record. Please update the record to be proxied.

Domain B, the CF-on-CF customer, had the same grey cf-origin record, but its hostname stayed stuck: The custom origin hostname you specified does not exist on Cloudflare as a DNS record (A, AAAA or CNAME) ... in your zone: <your-zone>.

Same custom_origin_server value. Same record. One account tolerated it as a warning, and the other treated it as if the record didn’t exist. The account boundary was never the variable. The cloud color was.

The fix

The fix was the one-flag flip: cf-origin from DNS-only to proxied. The app commit that closed it out reads:

commit-14DE cf-origin must be PROXIED, not DNS-only
(CF for SaaS requires proxied custom origin; cross-account/CF-on-CF
customers fail validation on grey; verified 2026-06-01)

Re-validating the domain moved it off the stuck state to active_redeploying. www lagged behind because its own grey CNAME hadn’t propagated yet, and once it caught up both records served through Cloudflare. Domain A had never broken in the first place.

Our own docs had it backwards

Two of our own locked docs, the architecture doc and the origin-server reference doc, both said cf-origin was supposed to be DNS-only. That was the documented design, and it had been wrong since before this ticket existed. It survived every prior test because every prior test ran against non-CF customers, where grey gets you nothing worse than a warning nobody reads. The correction landed in both docs the same afternoon, alongside the plan-of-record for the wider Cloudflare migration this ticket sits inside.

The test domain is still live, left in place on purpose as a reference case. We still don’t have a general answer for how many other “documented but never actually re-verified against the edge case” settings are sitting in that same architecture doc, correct on paper and untested against the one customer type that would break them.

An issued certificate only shows that DNS ownership validation passed, so ask for proof that the page actually loads before calling a domain onboarding done. And check that the settings in your design docs have been tested against every customer type, not only the common one.