By default, Senddera rewrites every campaign link through a tracking URL on the Senddera host's domain (e.g. https://mail.example.com/t/abc123/redirect). When recipients hover over a link, they see your Senddera-host's domain, not your brand's domain — and on shared/multi-tenant hosts, every customer's links go through the same domain, exposing all customers to any reputation hit on that domain. The fix: a custom tracking domain (https://track.example.com/...) per sending domain.
This article covers when to use a custom tracking domain, the DNS + certbot setup, Senddera's TrackingDomain model config (per app/Model/TrackingDomain.php), and the operational gotchas.
Why custom tracking domains matter
Three reasons:
1. Brand consistency
Recipients hover over a link in your campaign. If they see mail.Senddera-host.com/t/..., the message looks like a third-party broadcast tool. If they see track.example.com/t/..., it looks like a first-party communication. Brand consistency matters more than most operators give it credit for — psychologically, hover-domain mismatch is a small trust deduction that compounds over thousands of recipients.
2. Deliverability isolation
When Senddera hosts multiple customers' tracking on a shared domain (Senddera-host.com), one customer's bad-actor behavior (link to a phishing destination, obviously spammy URL) can land the shared domain on URL-reputation lists like:
- Spamhaus DBL — domain-block list
- SURBL — URL-block list
- URIBL — URL-block list
A listing on any of these affects EVERY customer using that shared tracking domain — every link in every campaign hits a "this URL is in a spam blocklist" filter. The fix: per-customer tracking domains so each customer's URL reputation is isolated.
3. Tracking-URL preview
Some receivers (like Gmail) preview the destination of links in their UI. A track.example.com URL renders as your brand; a mail.Senddera-host.com URL renders as a third party. Same UX argument as #1.
DNS setup
The tracking domain is a CNAME pointing to the Senddera host:
CNAME track.example.com → mail.Senddera-host.com
The CNAME means traffic to track.example.com resolves to whatever IP the Senddera host is using — no separate hosting infrastructure needed. Senddera handles the request (its nginx vhost listens for the tracking-domain hostname).
After CNAME publishes, verify:
dig +short track.example.com
# Should return the Senddera host's IP via CNAME chain
TLS via certbot
The tracking domain needs HTTPS — modern browsers warn loudly on HTTP. From the Senddera host:
sudo certbot --nginx -d track.example.com \
--non-interactive --agree-tos --email you@example.com --redirect
Certbot validates ownership via HTTP-01 challenge, issues a certificate, configures nginx to serve the tracking domain over HTTPS. The renewal cron handles future certs.
For multi-tenant Senddera hosting many tracking domains:
# Bulk renewal cron (already runs daily via /etc/cron.d/certbot)
# All certs renew via the same cron; just keep adding domains.
Senddera config
Admin → Domains → Tracking Domains → New
Name: track.example.com
Customer: <customer assigned this tracking domain>
The TrackingDomain model (per app/Model/TrackingDomain.php) verifies the CNAME resolves correctly — it queries DNS and confirms the CNAME points at the configured Senddera host. If verification fails, the config is rejected.
After creation, link the tracking domain to the customer's sending domain:
Admin → Customers → <customer> → Edit → Tracking Domain
= track.example.com
Or set it per-campaign in the campaign editor.
Verify it's working
Send a test campaign. In the received message, hover over a link. The URL should be:
https://track.example.com/t/<encoded-recipient>/<campaign-id>
Click it. The redirect should:
- Hit
https://track.example.com/... - Log the click in Senddera (TrackingLog row created)
- Redirect to the original destination URL
If any step fails, check:
- DNS:
dig track.example.comreturns the Senddera host - TLS:
curl -sI https://track.example.comreturns200 OKwith valid cert - Senddera: TrackingDomain row is
verified=true
Per-customer rotation strategy
For multi-tenant Senddera with high-volume customers:
Customer A: track.customer-a.com
Customer B: track.customer-b.com
Customer C: track.customer-c.com
Each customer's URL reputation is fully isolated. If Customer A gets a SURBL listing, Customers B and C are unaffected.
The cost: each customer needs a domain or subdomain + certbot cert. For a host with 100+ customers, this is ~$500/year in certs (Let's Encrypt is free; the cost is just certbot renewal infrastructure) and ~10 hours/year of management.
Related reading
- Complete DNS Setup for Email Sending — foundational DNS
- Multi-Server Rotation Pattern — for the multi-tenant isolation pattern
- Sender Reputation Monitoring Stack — includes URL reputation checks
- Return-Path and Envelope Sender — companion bounce-handler config
FAQ
Do I need a separate certbot cert per tracking domain?
Yes — each domain gets its own cert. They auto-renew via the same cron.
Can I use a wildcard cert?
Yes, but it requires DNS-01 challenge (more setup) and the wildcard must cover all your tracking subdomains. For 100+ customers, wildcard makes sense; for < 10, individual certs are simpler.
What if my Senddera host changes IP?
The CNAME chain auto-updates — no DNS change needed. If you change the Senddera host's hostname (not just IP), update the CNAME target.
Does this affect email delivery itself?
No, only link tracking. The DKIM-signing, SMTP delivery, bounce-handling are all on different infrastructure (sending IP). Tracking domain only affects the click-redirect path.