Short answer: a custom tracking domain is a customer subdomain, such as track.customer.example, that points at your click and open tracker with a CNAME. To serve those links over HTTPS, something on your side has to hold a valid certificate for that exact hostname. You don't need every customer to set up Cloudflare or another CDN to get one. Verify the customer's CNAME, then either issue the certificate yourself on proxies that use on-demand TLS, or route the hostname through a managed custom-domain proxy that issues and renews it for you.
How a custom tracking domain works
Email platforms track opens and clicks by changing the message before it is sent. For opens, Amazon SES documents adding a 1 by 1 pixel transparent image hosted on its own servers. When the image loads, SES knows which message was opened. For clicks, the platform rewrites each link so it passes through its own redirect server first. Postmark describes the same model: the click is recorded and the reader is sent on to the original URL.
By default those rewritten links use the platform's own hostname. A custom tracking domain swaps in a hostname the sender owns, so the links carry the sender's brand:
- The customer creates a CNAME record, for example
track.customer.examplepointing attracking.yourplatform.example. - Your platform writes links such as
https://track.customer.example/c/abc123into that customer's messages. - A reader clicks. DNS follows the CNAME to your tracker, which reads the hostname and path, records the click, and redirects to the destination.
Over plain HTTP, that is all you need. Over HTTPS, the browser starts a TLS handshake for track.customer.example before it sends the request. Your certificate for tracking.yourplatform.example doesn't cover that name, so the handshake fails. Postmark explained this in a 2016 engineering post: certificates belong to specific domains, so HTTPS tracking couldn't support arbitrary customer CNAMEs. As of November 2, 2026, Postmark's migration guide says it doesn't support custom domains for click tracking at all. Every platform that offers branded HTTPS tracking needs a certificate per customer hostname.
Why HTTPS tracking links matter
Some links fail outright over HTTP. HTTP Strict Transport Security (HSTS) tells browsers to replace http with https for a host, and for its subdomains when the policy includes them. When an HSTS host has a certificate error, the browser doesn't offer the reader a way to continue. The whole .app top-level domain is on the browser preload list, and its registry states that HTTPS is required on every .app website. So an HTTP-only tracking link on track.customer.app is upgraded to HTTPS and then fails if your tracker has no certificate for it. The same happens under any parent domain that a reader's browser has learned an HSTS policy with includeSubDomains for. Buttondown described this in a 2021 post: tracked links for senders on HTTPS-only domains were broken in some browsers until it moved to HTTPS tracking.
Readers can see warnings. The Amazon SES documentation notes that when a custom tracking domain uses HTTP and the email contains HTTPS links, readers may see a warning message when they click.
Mailbox providers may care. When AWS added HTTPS open tracking for custom domains on September 30, 2024, it said HTTPS tracking helps with security compliance and reduces the chances of delivery issues with mailbox providers that reject non-secure links. That is AWS's statement. We haven't found a primary source that measures the effect on inbox placement, so treat it as a risk you remove rather than a number you gain.
Open pixels can be affected too. Browsers auto-upgrade HTTP image requests on HTTPS pages, according to MDN. If an email renders in an HTTPS page and loads the pixel directly, the link can fail if the tracking domain has no valid certificate. Email clients load remote images in different ways, so plan for this as a risk rather than a measured loss.
The common workaround: ask each customer to add a CDN
The usual way around the certificate problem is to put a CDN in front of each customer's tracking hostname. The CDN holds the certificate and forwards requests to the platform's tracker. The Amazon SES guide for HTTPS custom tracking domains follows this pattern. It tells the sender to create an account with a CDN such as Amazon CloudFront, point the origin at the regional SES tracking domain while passing the Host header, acquire a certificate, and upload it to the CDN. Twilio SendGrid documents a similar setup, including a guide to using Cloudflare as the CDN.
It works, and it costs more than it looks:
- Support load. Each customer sets up a different account, record, SSL mode, and caching rule. When a link breaks, the cause sits in an account your team can't see.
- Customer DNS skills. Many senders aren't infrastructure engineers. A CNAME is a reasonable request. A CDN distribution, an origin, and a certificate are a project, and some customers will stop at that step and stay on HTTP.
- Certificate ownership. The certificate lives in the customer's CDN account. If their plan lapses, a setting changes, or the certificate isn't renewed, their tracked links break and your platform learns about it from support tickets.
- An uneven fleet. Some customers end up on HTTPS, some on HTTP, and some halfway. Your link rewriting and support playbooks have to handle all three.
The alternative is for your platform to own the certificate. There are two practical ways to do that.
Option 1: issue certificates yourself with on-demand TLS
You can run your own reverse proxies in front of the tracker and have them obtain a certificate for each customer hostname. Caddy's on-demand TLS is built for this case. It obtains a certificate during the first TLS handshake that needs one, and Caddy recommends it when you don't control the domain names, such as customer domains. That first handshake is held while the certificate is issued. Caddy says the delay is usually a few seconds and only affects that first connection.
Running it in production means owning several pieces:
- A permission check. Caddy requires on-demand TLS to be restricted, normally by an “ask” endpoint that approves only hostnames you serve. The Caddyfile options documentation says it should answer in a few milliseconds and avoid DNS queries or other network requests. Caddy's author warns that an endpoint that approves too much can get your server blocked by certificate authorities as an abuse vector.
- A permission check that stays up. The check also gates loading certificates that are already in storage. On the Caddy forum, Caddy's author confirmed in September 2026 that this is intended, in reply to a user who lost TLS after a restart while their endpoint was down. Keep the endpoint local and reliable.
- Shared storage. Caddy instances that use the same storage share certificates and coordinate issuance. More than one proxy means running a shared storage backend and keeping it available.
- Rate limits. Let's Encrypt's rate limits (page last updated August 5, 2026) allow 300 new orders per account every 3 hours, refilling one every 36 seconds, and 5 failed validations per hostname per account per hour. A hostname that keeps failing validation is eventually paused. Two of the limits can be raised through an override form, which Let's Encrypt says takes a few weeks to process. Customers who add domains in batches draw on the order limit quickly.
- Shorter certificate lifetimes. The default Let's Encrypt certificate lasts 90 days as of November 2026. Its default moves to 64 days on February 10, 2027 and to 45 days on February 16, 2028. Renewal has to be automatic, and Let's Encrypt recommends ACME Renewal Information (ARI) over a fixed schedule.
This route gives you full control. It also makes your team responsible for issuance retries, storage, monitoring, capacity, and on-call response for every customer's links. Caddy also adds ZeroSSL as a fallback issuer to Let's Encrypt when an account email is configured, which helps when one certificate authority has trouble.
Option 2: use a managed custom-domain proxy
A managed custom-domain proxy runs that layer for you. You register each customer's tracking hostname through an API, with your tracker as the target. Customers point their CNAME at a hostname you control, and you point that hostname at the proxy. The proxy issues and renews the certificate, terminates TLS, and forwards the request to your tracker with the original hostname so it can find the right account.
Keeping an intermediate hostname such as tracking.yourplatform.example in the path matters. If your customers already CNAME to it, you can move it to a new proxy without asking them to change a record, as long as every customer hostname is registered with the proxy first.
When you compare providers, ask:
- Do customers keep their own DNS provider, or must they move their zone?
- Which certificate authorities issue the certificates, and what happens when one fails?
- How do you learn that a certificate or DNS record has broken: status APIs, webhooks, or a support ticket?
- Does the proxy forward the original hostname and client IP to your tracker?
- How is it priced per hostname, and does that fit thousands of tracking domains?
Our custom domain API comparison walks through these trade-offs for specific providers.
Operational details that keep tracked links working
Verify the CNAME before issuance. HTTP-01 validation reaches the hostname over port 80, so it can only succeed once the customer's record points at you. Check the CNAME in your application during onboarding, and only then approve the hostname for certificates. This keeps the permission check fast, as Caddy advises, and avoids spending failed validations on hostnames that aren't ready. The onboarding checklist breaks this into states your UI can show.
Use a subdomain, not the apex. A tracking domain should be a dedicated subdomain such as track. or links.. A CNAME can't sit at the root of a zone, and pointing customer.example at your tracker would also take over the customer's website. The apex domain guide covers the root-domain options if a customer insists.
Warm the certificate before the first campaign. With on-demand issuance, the first HTTPS request waits for the certificate. Once DNS verifies, make an HTTPS request to the tracking hostname yourself. That way a reader's first click doesn't pay the wait, and you confirm the certificate exists before you mark the domain ready.
Keep the redirect to one hop. Write HTTPS links from the start, and have the tracker redirect straight to the destination. An extra HTTP to HTTPS hop or a second internal redirect adds a round trip to every click.
Monitor expiry and the real response. Let's Encrypt stopped sending expiration emails on June 4, 2025. If you issue certificates yourself, nothing warns you when renewal fails unless you build it. Check each tracking hostname on a schedule: certificate validity, days left, and a test path that proves your tracker answers.
Plan for a customer removing the CNAME. When the record is gone, requests no longer reach you. Tracked links in emails already sent stop working, and renewals for that hostname start failing validation. Detect the DNS change, tell the customer what it breaks, and remove the hostname from your proxy so you stop retrying a certificate that can't be issued. The reverse case also matters. If you delete a customer but their CNAME still points at you, that is a dangling record. The security guide covers how to handle it.
Where Approximated fits
We built Approximated to run this layer for SaaS products, and email and outreach platforms are a common fit. You create a virtual host for each tracking domain through our API with your tracker as the target. Your customers keep their DNS provider and add one CNAME to a hostname you control, which points at your dedicated proxy cluster.
Our proxies obtain a certificate for each tracking domain on demand when the first HTTPS request arrives, and renew it automatically. Only hostnames configured as virtual hosts get certificates, so unknown names are refused before any certificate authority is contacted. We work with multiple certificate authorities, so if one can't issue a certificate, issuance falls back to another. We monitor DNS, SSL, and proxy-hit status for each domain and send webhooks when it changes, so your app can tell a customer their tracking domain is broken before their next campaign goes out.
Your cluster also includes WAF and DDoS protection and support from real engineers. Our pricing is per domain and public. If you later need certificates and traffic on your own infrastructure, we offer a path to self-hosting.
Frequently asked questions
Why doesn't my tracking certificate cover customer tracking domains?
A certificate is valid only for the hostnames listed in it. When a reader opens https://track.customer.example, the browser checks for a certificate covering that exact name before any request is sent. A certificate for your own tracking hostname doesn't qualify, even though the customer's CNAME points at it. Each branded tracking domain needs its own certificate.
How can I get SSL on a custom tracking domain without making customers set up Cloudflare?
Hold the certificate on your side. Ask the customer for one CNAME to a hostname you control, verify it, and then issue a certificate for their tracking hostname on your own proxies with on-demand TLS, or register it with a managed custom-domain proxy that issues and renews it. The customer keeps their DNS provider and never configures a CDN.
Do HTTPS tracking links improve email deliverability?
AWS says HTTPS tracking reduces the chances of delivery issues with mailbox providers that reject non-secure links. We haven't found a primary source that measures the effect on inbox placement. The firmer reasons are in the browser. On HSTS hosts such as every .app domain, HTTP-only tracking links fail, and readers may see warnings on mixed HTTP and HTTPS links.
Can a customer use their root domain as a tracking domain?
Use a dedicated subdomain such as track.customer.example instead. A CNAME can't sit at the root of a DNS zone, and pointing the root at your tracker would also take over the customer's website. A subdomain keeps tracking traffic separate and lets the customer use an ordinary CNAME record at their existing DNS provider.
What happens when a customer removes their tracking domain CNAME?
Requests to that hostname stop reaching your tracker, so tracked links in emails already sent stop working and certificate renewals for the name start failing validation. Detect the DNS change, warn the customer about links in sent mail, and remove the hostname from your proxy so it stops retrying issuance that can't succeed.