Pointing your own domain at a tagging server: the CNAME, the certificate, and Cloudflare error 1014

Two reasons, and they are different. To an ad blocker, a request is third-party if its hostname is on a list, and signalhost.io is not on any list today but could be tomorrow; yoursite.com will never be. To a browser, a cookie set by a response from metrics.yoursite.com is a first-party cookie for yoursite.com, while one from another domain is third-party, and Safari refuses it outright. That is the cookie that keeps an ad click for Google Ads, Meta and TikTok until the purchase. It does not buy a longer life: Safari still caps cookies from a server at a different address to seven days. The tagging server is the same either way. The hostname is what changes how it is treated.

Setting up a tagging server from scratch? How to set up server-side Google Tag Manager, step by step.

One CNAME, at your DNS provider, pointing the subdomain you chose at our DNS-only endpoint:

metrics.yoursite.com.   CNAME   tenants.signalhost.io.

Not at your random tenant hostname, and not at a wildcard. tenants.signalhost.io is a name we publish specifically for this, and the reason it has to be that name is the next section.

If your own domain is on Cloudflare, create the record with the proxy OFF — the grey cloud, "DNS only". A proxied record would route your visitors' requests through your Cloudflare account to us, and the certificate step below cannot complete through it.

Our own hostnames sit behind Cloudflare. If a customer points their CNAME at one of our proxied names — the wildcard, or a tenant hostname — their traffic arrives at Cloudflare for a hostname that belongs to a different Cloudflare account than ours. Cloudflare refuses that with error 1014, "CNAME Cross-User Banned". The page that shows it is Cloudflare's, mentions neither of us, and nothing in your DNS, your site or your browser explains it.

tenants.signalhost.io is unproxied on purpose: it resolves straight to our servers, so a CNAME at it simply works. The dashboard's DNS check recognises the proxied-target case by name and says what to change, but it is faster to never make it.

Once the record resolves, we request a Let's Encrypt certificate for your hostname. The validation is HTTP-01: Let's Encrypt fetches a specific path over plain HTTP on port 80 from the name, and we answer it. Plain HTTP because there is no certificate yet — that is what is being obtained — and this is the only unencrypted path our edge answers at all. It is a nonce comparison; nothing else is reachable that way.

Expect a few minutes. The dashboard shows three steps in order: the CNAME resolves, the certificate is issued, the hostname is serving. A step stuck on the certificate with the CNAME green almost always means a proxied record on your side — Cloudflare answers the validation request with its own certificate and its own page, and Let's Encrypt sees the wrong thing.

The Google tag in your web container carries the server container URL. When the hostname starts serving we rewrite it to your custom domain and republish the container — and rewrite it back to the tenant hostname if you remove the domain. From that moment your hits go to your own domain.

One thing is left for you: the snippet on your site still loads Tag Manager from your signalhost.io address. It keeps working, but it is the one request a filter list could still match, so replace it. The container page shows the new snippet as soon as the domain is serving, and we email it to you at the same moment. Replace it rather than adding a second one: two snippets load the container twice.

Removing a domain is the same in reverse. Remove it in the dashboard, put the snippet the container page then shows back on your site — it loads from your signalhost.io address again — and delete the DNS record last. Delete the record first and, until the dashboard notices, your site loads its tags from a name that no longer resolves.

• Error 1014 in the browser: the CNAME points at a proxied name of ours. Change the target to tenants.signalhost.io.
• CNAME green, certificate pending for more than fifteen minutes: your record is proxied. Turn the cloud grey at your DNS provider.
• CNAME never goes green: check for a conflicting A or AAAA record on the same name — a CNAME cannot coexist with them — and give propagation up to an hour.
• Serving, but the container page shows no traffic from the new name: the web container has not republished yet. It happens within a couple of minutes of the hostname going live; the container page shows which hostname the tag currently points at.
• Serving, but your site still loads Tag Manager from signalhost.io: the old snippet is still on the page. Replace it with the one on the container page.