White label link domains: CNAME, HTTPS and redirects

Your product sends an email, and every link in it goes through track.yourplatform.example. A customer looks at the message, sees your hostname in the status bar, and asks whether those links can say links.theirbrand.example instead. Short links, invite links and click-tracking redirects all raise the same request. It sounds like a DNS tweak. It is one DNS record, one certificate problem and one security decision, and the certificate problem is where most of the time goes.

We make CustomDomain™, a product of EverJust Company in Minneapolis. This post is on our blog, so it may lean toward the idea that handling customer domains is work worth handing off. We have tried to keep every technical claim tied to a primary source, and where we could not verify something we say so instead of guessing. The broader idea of putting a customer's name on your product's domain is covered on our white label domain page. This post is only about the link domain.

Why a branded link domain is almost always a subdomain

The usual setup is a CNAME: the customer creates a record for a name like links.theirbrand.example that points at a hostname you control. Because the record points at a name instead of an address, you can move your edge without asking every customer to edit anything.

That record cannot sit at the bare domain. RFC 1034 says no other data should accompany a CNAME, and RFC 2181 makes that exclusive in section 10.1. The same document, in section 6.1, requires NS and SOA records at the zone origin. The apex always has those, so it can never also hold a CNAME. A customer who wants theirbrand.example itself to be the link domain hits a wall that no registrar setting fixes. Our apex versus CNAME glossary page covers the difference in more detail.

There is a newer record type aimed at exactly this gap. RFC 9460, published in November 2023, defines AliasMode in section 2.4.2, which aliases a service to a target name for zone apexes where a CNAME is not allowed. Whether you can rely on it for visitors is a separate matter. A 2024 study found that only Safari followed AliasMode targets. A Firefox bug for the same gap is marked fixed, but we have not verified which release shipped it, and we have not verified what current Chrome does. Treat AliasMode as something to watch, not something to put customer links on.

So the practical advice is dull and reliable: ask customers for a subdomain, and give them a suggested name. Which name to suggest, and why, is the subject of our post on choosing a hostname for each customer.

The CNAME is the easy half

Once the subdomain points at you, plain HTTP links work. Most customers will not accept that. A branded link that lands on a browser warning, or that gets blocked as mixed content inside a secure page, is worse than the unbranded one it replaced. You need a certificate for the customer's hostname, and you need to serve it.

The Amazon SES documentation shows the shape of this clearly. In its custom tracking domain guide, you add a CNAME on your subdomain that points at the SES tracking domain for your Region. That alone gets you HTTP. For HTTPS, the guide says to put a CDN in front, with CloudFront as the example, using r.us-east-1.awstrack.me as the origin and forwarding the Host header, and to attach a certificate from a certificate authority. The guide also exposes a setting called HttpsPolicy with three values: OPTIONAL, which is the default, REQUIRE and REQUIRE_OPEN_ONLY. We are not going to restate what each one does; read the guide for the semantics before you choose.

A CNAME alone does not give a customer HTTPS, and the SES guide treats the second half as its own setup. If your product emits links, which includes any email you send for customers (see our post on white label sending domains), you inherit the same two jobs: terminate TLS for hostnames you do not own, and keep those certificates valid.

Issuing the certificate

The common route is an automated certificate authority. For Let's Encrypt, the challenge types page says the HTTP-01 challenge uses port 80 only. It also says the validator follows redirects up to 10 deep, and only to http or https on ports 80 or 443.

Two things follow. A port 80 handler that redirects everything to HTTPS is fine for validation, provided the redirect stays on those ports. Our own reading of the rule: do not bounce port 80 traffic to some other port, because validation will not follow it. We also cannot tell you what HTTP-01 does with a CNAME in the path. That page mentions CNAME only in the DNS-01 section, and we have not verified the HTTP-01 behavior, so test issuance for a real customer subdomain before you promise anything.

What HSTS does when something breaks

HTTP Strict Transport Security is specified in RFC 6797. Three details matter for a link domain. Section 6.1.2 says includeSubDomains covers every subdomain of the host that sent the policy. Section 8.3 says a browser rewrites an http request to https (port 80 becomes 443) and does not refuse it. Sections 8.4 and 12.1 say any TLS or certificate error terminates the connection, with no way for the user to override.

Here is how we read that for a branded link domain. If a customer's main site sends HSTS with includeSubDomains, their link subdomain is covered whether or not you knew. From then on, an expired or mismatched certificate on your edge is not a warning the visitor can click past. The links stop working until you fix the certificate. That is our inference from the RFC, not something it says outright.

For you, it means a lapsed certificate on one customer's link domain is a customer-visible outage even when everything else is healthy. Monitor expiry per hostname, and monitor that the CNAME still points where you expect. When a link domain misbehaves, our troubleshooting guide and the read-only Domain Health Check are a starting point.

Choosing the redirect status code

A tracking or short-link domain is mostly a redirector: look up a token, record the click, send the visitor on. The status code you choose is a real decision. The codes are in the IANA registry, and MDN's redirection guide describes how they behave.

For click tracking, the case for a temporary code is that you want the request to come back to you each time, so the click is counted. A permanent code tells clients the move is lasting, and clients may be happy to remember it. We have not verified the exact caching rules in RFC 9110, so we are not going to cite section numbers or promise how long any given browser keeps a 301. If counting every click matters to you, use a temporary code and test with the clients your customers use. If a link is truly permanent and the count does not matter, a permanent code is a legitimate choice. If a link has to carry a POST through, 307 or 308 is the pair that keeps the method.

Link creation is an open redirect by design

A redirector that sends visitors to a destination chosen by whoever created the link is, structurally, an open redirect. CWE-601, URL redirection to untrusted site, covers redirects to user-controlled links, and notes that the trusted host name is what makes the phishing look credible. A branded link domain makes that worse in one specific way: the host name belongs to a company the recipient trusts.

The inference is ours, not CWE's: if anyone can create a link on your link domain, you have handed them a trusted-looking redirector. Restrict who can create links, tie each link to an authenticated account, and be able to disable a customer's link domain quickly.

Before you give customers a link domain

1. Decide that it is a subdomain, and tell customers which name to use.
2. Confirm the CNAME target is a name you control and can repoint.
3. Issue and renew a certificate for every customer hostname, and alert before expiry.
4. Test issuance with a real customer subdomain, since we could not verify how HTTP-01 treats a CNAME.
5. Keep port 80 redirects on ports 80 and 443 so validation can follow them.
6. Pick a temporary or permanent redirect code on purpose, not by default.
7. Restrict link creation to authenticated accounts, and keep a kill switch per customer.
8. Assume the customer may add HSTS to their domain, and treat certificate failures as outages.

How CustomDomain™ relates

CustomDomain™ is a widget that SaaS platforms embed so their customers can connect their own domains, with DNS automation, certificate issuance and a reverse proxy edge behind it. The certificate and edge jobs above are the parts it is built for. We do not claim features specific to link tracking or to short-link redirects, and we do not publish a status code policy for your product; that logic stays yours. The how it works page shows the connection path. Branding it as your own is a separate matter from the technical setup, and white-label resale is an Enterprise feature by contract, listed on pricing. The customer-facing side is covered on the white label custom domain page, and the white label domain overview is the place to start for the wider picture.