Skip to content
DNS & Domain Setup

Custom Tracking Domain for Click URLs — AcelleMail Setup

By default every link in your emails routes through acellemail.com's tracking redirect. Replace with click.yourdomain.com — same redirect mechanics, your own brand. This guide walks the setup + the CNAME + the link-report verification.

5 min read Intermediate

Why a custom tracking domain matters

Every link in your AcelleMail campaign is auto-rewritten at send time to route through a tracking redirect. The default redirect lives at acellemail.com/c/abc/... — AcelleMail records the click, then forwards to your real URL.

Two problems with the default:

  1. Brand inconsistency — recipient sees acellemail.com in the hover preview before clicking. For B2B audiences, that breaks trust ("why is this routing through a third party?").
  2. Deliverability signal — Gmail's "show original" pane displays the rewritten URL. Some receivers cross-check sender domain vs link domain; mismatched values can downgrade reputation.

Custom tracking domain = click.yourdomain.com (or any subdomain you pick) handles the redirect instead. Same mechanics, your brand throughout.

The setup in 4 steps

Step 1: Pick your subdomain

Convention: click.brand.com or track.brand.com or links.brand.com. Pick a subdomain you don't already use for anything else (it'll be reserved for tracking redirects).

Step 2: Publish the CNAME at your DNS host

At your DNS provider (Cloudflare, Route 53, Namecheap, etc.), add:

Type:  CNAME
Name:  click.yourdomain.com   (or whatever subdomain you picked)
Value: track.acellemail.com   (the AcelleMail tracking endpoint — varies per install)
TTL:   3600 (or default)

Wait for DNS propagation (typically 5-60 minutes; can take up to 24h for stubborn caches).

Step 3: Register the tracking domain in AcelleMail

In AcelleMail, Sending → Tracking domains → Add tracking domain. Enter click.yourdomain.com + click Verify. AcelleMail dig-checks the CNAME, flips to Verified when propagation is complete.

Step 4: Attach to your sending server

Open the sending-server detail → Configuration → Tracking domain dropdown → pick the newly verified domain. Save.

Sending server detail — tracking domain field in Configuration

From the next campaign send onwards, every link uses your custom tracking domain.

Verify it's working

After a send, open the campaign report's Links tab:

Links report — click destinations

Hover over any link — the rewritten URL should now show click.yourdomain.com/... not the AcelleMail default. If still showing the default, the sending server config didn't pick up the change (re-save the server config + send a fresh test).

The Click map visualization shows where clicks land — independent of which tracking domain rewrites them:

Click map

Common UI signals + fixes

Symptom Likely cause UI fix
Tracking domain stays Pending after 1 hour CNAME not propagated Wait up to 24h; if still pending, verify CNAME at your DNS host points to the correct target
Tracking domain Verified but new campaigns still use acellemail.com Sending server's tracking-domain field not updated Sending server detail → Configuration → Tracking domain → re-pick + save
Hover preview shows weird URL (mix of yours + acellemail) Cached email body from before the change Send a fresh test; old campaigns retain their snapshot of tracking URLs
Click reports show clicks but tracking domain says 0 traffic DNS resolving differently for some recipients Test with dig click.yourdomain.com from multiple regions
CNAME conflicts with existing record at subdomain Duplicate subdomain reservation Pick a different subdomain name; can't have CNAME + A record on same name

Common conventions

Pattern Used by
click.brand.com Most common; explicit "this is a click-tracker" signal
track.brand.com Same intent, slightly more technical wording
links.brand.com Friendly; works for marketing-facing audiences
t.brand.com Short for higher-engagement industries (e-commerce flash sales) — saves URL chars in SMS-too

Stick with one convention across your account — don't have some campaigns route via click. and others via track. (recipients learn to trust the pattern; switching mid-stream creates confusion).

Advanced: HTTPS-only redirects, multi-region tracking, and security headers

HTTPS-only redirects:

By default AcelleMail's tracking domain serves the redirect over both HTTP + HTTPS. To enforce HTTPS-only (recipients clicking via HTTP get auto-upgraded to HTTPS first):

  1. AcelleMail admin → Sending → Tracking domains → [your domain] → Settings
  2. Toggle "Force HTTPS"
  3. Ensure your DNS host's TLS certificate covers the subdomain (Let's Encrypt + Caddy on the AcelleMail host is the common setup)

For Cloudflare-fronted setups, the redirect honors Cloudflare's TLS settings — set Full/Strict mode to prevent downgrade attacks.

Multi-region tracking:

If your audience is global, latency on the redirect matters. A US-hosted AcelleMail receiving Asia-side clicks adds ~200ms per hop. Two patterns:

  1. CloudFront / Cloudflare CDN in front of your tracking domain — most installs route via Cloudflare for free; the CDN's POP nearest the user handles the redirect
  2. Multi-region AcelleMail clusters — separate AcelleMail instance per region, each with its own tracking subdomain (click-us.brand.com, click-eu.brand.com). Per-campaign router selects the right tracking subdomain based on recipient region

For most senders, Cloudflare front-end is sufficient + free.

Security headers on the tracker:

The tracking endpoint redirects external URLs. Best practices:

HTTP Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Configure at your nginx / web-server layer. The AcelleMail tracking endpoint doesn't set these by default — you add them via your reverse-proxy config.

Programmatic verification:

# Check tracking domain is rewriting links
campaign_uid="..."
acelle_token="..."

# Fetch a campaign's links report
curl -sH "Authorization: Bearer $acelle_token" \
  "https://acellemail.com/api/v1/campaigns/$campaign_uid/links" \
  | jq '.data[0].url'

# Should show click.yourdomain.com/..., not acellemail.com/...

Run as a daily cron after sends — catches misconfiguration before customer complaints.

Rotating tracking domains:

For very large operations, multiple tracking domains can isolate reputation per campaign type:

click-marketing.brand.com  — marketing emails
click-txn.brand.com        — transactional (password resets)
click-ann.brand.com        — announcements

Different sending servers route through different tracking domains. If click-marketing ever gets blocked (rare), transactional is unaffected.

Related articles

Tagged

18 comments

11 comments

  1. Lucas
    Easy win: set up dmarcian.com (free tier) to receive your DMARC RUA reports. The first 2 weeks of reports tell you everything you didn't know about who's sending as you.
    1. Admin
      RUA is worth turning on, though it sits one layer away from what this article covers. A tracking domain is a CNAME for click URLs, it isn't authenticated, so nothing you do there shows up in a DMARC report. The reports cover your From domain's SPF/DKIM alignment. Where they do overlap: if your tracking CNAME and your sending domain are different registrable domains, some receivers get twitchy about the mismatch between the visible link host and the signing domain. RUA won't flag that, but it's the same class of problem. One caveat on the two-week claim. Most of what lands in the first reports is forwarders and mailing lists failing SPF, which looks alarming and is usually fine. The real spoofers show up as unaligned sources with volume from IPs you don't recognise. Worth knowing before someone panics at their first XML. I'll add a "related, but not this" note pointing at DMARC monitoring so people don't assume the tracking domain needs its own policy record.
  2. Marcus
    our dkim rotation broke for 2 days because we updated the active selector first, then waited to delete the old. should be the other way — publish new, wait 48h for cache, switch sending, then remove old.
    1. Admin
      That ordering is right, and it's the same reason the tracking domain setup in this article says to put the CNAME in place before you flip the domain on the sending server. Publish the new selector, let it propagate, verify it resolves from a couple of resolvers, then switch signing, then leave the old selector up for another day or two before deleting. Nothing signed with the old key should still be in flight by then, but resolver caches don't care about your schedule. We don't spell out the rotation order anywhere in the DKIM docs right now, which is our gap. I'll add it as a short ordered list.
  3. Brian
    quick question: do receivers actually enforce the spf -all hard fail, or do most just downrate? i've heard mixed things and i'm hesitant to switch from ~all.
    1. Admin
      Mixed things is the honest answer, because it genuinely varies. Gmail and Microsoft treat SPF as one input into a composite score rather than a kill switch, so a bare -all fail usually gets downranked or foldered rather than bounced outright, especially if DKIM and DMARC alignment are still passing. Smaller receivers running stock rspamd or a strict milter are the ones that will actually reject on -all. The thing that decides it in practice is DMARC, not the SPF qualifier. If you're at p=reject, an SPF fail on an unaligned source is dead either way and -all vs ~all barely changes the outcome. If you're at p=none, -all is mostly a signal nobody acts on hard. My take: don't switch until you're confident every sender is in the record. Run DMARC aggregate reports for a couple of weeks first and look for sources you forgot about, that's usually a transactional app or a helpdesk tool. ~all costs you almost nothing while you do that. Worth saying this is off-topic for this article, the tracking domain here is a CNAME for click URLs and doesn't touch your SPF record at all. Your tracking domain is not a sending source, so adding it changes nothing about the -all decision.
  4. Anna
    What's your recommendation for sub-domains? We send from mail.example.com AND notifications.example.com. Same DKIM selector or separate?
    1. Admin
      Separate keypairs, but the selector name can be the same since the records are namespaced under each subdomain. One track.example.com covers both.
  5. Tomas
    How do you handle DNS for clients in white-label setups? The customer would need to add records to their domain — is there a clean way to bulk-verify those?
    1. Admin
      There's no bulk DNS verifier in the product today. Each tracking domain gets checked one at a time when the customer hits verify, and the check is just a CNAME lookup against the host they entered. What people in your position usually do is skip the per-customer domain entirely and give everyone a subdomain of yours, like click.yourbrand.com, with a wildcard CNAME. One record, you own it, no customer DNS involved. You only need the customer's own domain if they care that the click URL shows their brand, and most white-label resellers care about their own brand showing, not their end client's. If you do need real per-client domains, the verify path is scriptable. Same lookup logic, so you can loop your list and re-check on a cron rather than waiting for someone to click a button. A proper bulk view with status per domain is on the list, it just hasn't been worth building yet. If enough people are in this setup, tell me how many domains you're managing and I'll move it up.
  6. Akira
    Worth noting: our DNS provider (Cloudflare) caches negative responses for 1 hour. We added a TXT record, dig showed it, but mail-tester said missing for another 40 minutes. Almost lost our minds. TTL was set to 300 but the parent zone NS cache held.
  7. Vera
    Thanks for the explicit cautionary tales. The alignment-vs-pass distinction is exactly where I lost a week last year.
    1. Admin
      A week sounds about right. SPF passes on the bounce domain, From points elsewhere, and nothing complains until you move off p=none.
  8. Carlos
    DNS setup is one of those things where you dont know what you don't know. This article should be required reading for anyone running their own mail.
    1. Admin
      The "don't know what you don't know" part is exactly why this one got written. Tracking domains fail quietly, the CNAME resolves, links look fine, and you only find out weeks later when your click numbers are wrong or half the clicks 404 because the record points somewhere stale. The bit that still catches people is TTL. If you set the CNAME wrong the first time, fix it, and then test from the same machine, you may be reading a cached answer for hours. Test from a resolver you haven't hit yet before you conclude it's broken. If there's a DNS failure mode you hit that isn't in the article, tell me what it was and I'll add it.
  9. Isabella
    the SPF flattening explanation finally made it click for me. Id been hitting the 10-lookup limit and didn't understand why nesting includes counted
  10. Ravi
    hit the 10-lookup spf limit when we tried to layer ses on top of an existing google workspace setup. flattened with a tool (spfwizard.com) and it's been fine since. that tool's worth a mention. 👀
  11. Emma
    if you use vercel or netlify for the apex, watch out — they sometimes override txt records via their auto-dns feature. bit us once with a stripped spf record. 👀

Related reading

More in DNS & Domain Setup

Run your email marketing on your own server, your own terms

Join thousands of companies that have taken control of their email marketing with full source code, no recurring fees, and unlimited sending. One-time $80 license, lifetime updates.

Get the AcelleMail newsletter

Monthly issue with new releases, deliverability tips, and self-hosting playbooks. No spam.