Skip to content

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.

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

18 bình luận

11 bình luận

  1. lucas.bernard.…
    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
      Solid addition — adding to the article on the next refresh.
  2. m.schmidt78
    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
      Solid case study material here. If you're open to it, we'd love to write this up as a blog post — happy to credit you anonymously or otherwise
  3. bos.devops
    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
      for your specific case, I'd recommend testing with `--dry-run` first. The behavior under high load isn't 100% deterministic and we want you to see your own pattern before committing.
  4. anna.k.pm
    What's your recommendation for sub-domains? We send from mail.example.com AND notifications.example.com. Same DKIM selector or separate?
    1. admin
      there's no built-in way today. two workarounds: (1) cron + custom script polling the api every n minutes, (2) webhook-driven if your event source supports it. most operators go with #2.
  5. tnovak.cz
    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
      We don't recommend that approach in production. It works in dev but has subtle race conditions under concurrent load. Stick with the documented pattern.
  6. akira.tnk88
    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. v.petrova.ru
    Thanks for the explicit cautionary tales. The alignment-vs-pass distinction is exactly where I lost a week last year.
    1. admin
      thanks. Pass it along if it helps your team.
  8. cmendoza.mx
    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
      Thanks for the kind words. We try to keep these source-grounded so they age well.
  9. i.rossi.mil
    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.kumar.del…
    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.whitaker
    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. 👀

More in DNS & Domain Setup