Custom Email Tracking Domains: Setup, Link Safety and Troubleshooting
Understand custom tracking domains, DNS roles, verification, historical links and the limits of open and click events before changing your setup.
TL;DR
- A tracking domain is the hostname used by tracked links or an open pixel; it is distinct from the visible sender and the MAIL FROM domain.
- Configure a dedicated subdomain using the exact record returned by the email platform, then verify DNS and HTTPS behavior.
- Preserve old tracking host records while links in previously sent emails still need to work.
- Open and click events are observations, not proof that a person read a message, and a branded hostname does not guarantee inbox placement.
What an email tracking domain does
A tracked link sends a browser through a redirect before reaching the intended destination. The tracking hostname is the domain name in that redirect URL. A custom tracking domain lets that hostname use a subdomain you control, such as links.example.com, instead of the email platform's shared hostname.
Open tracking uses a different mechanism: an image reference in the message is requested by a mail client or an intermediary. The platform can associate that request with the tracked email. Whether an actual person opened and read the message is a separate question.
Custom tracking changes the hostname used for these requests. It does not turn the email platform into your website host, replace sender authentication or make every recipient's mail client load images. Treat it as one part of the message's link and measurement behavior.
Keep the domain roles separate
The same organization may use several related hostnames for different functions. Troubleshooting is easier when the team knows which record belongs to which role.
| Role | Illustrative value | What it affects |
|---|---|---|
| Visible From address | updates@example.com | Sender identity displayed in the email |
| MAIL FROM subdomain | send.example.com | Envelope sending and related authentication or bounce routing |
| Tracking hostname | links.example.com | Redirect and pixel requests |
| Destination website | www.example.com | The page opened after following the link |
These are examples, not records to copy into a real DNS zone. Use the exact values generated for your account. A working tracking CNAME does not establish that SPF, DKIM or DMARC is configured correctly, and a verified sending domain does not prove a new tracking hostname is ready.
The sending-subdomain guide explains the sender-side separation. Keep that work distinct from the link-host setup described here.
Choose a hostname with a clear owner
Pick an unused subdomain that the team can maintain over the lifetime of the emails. A short label such as links can be convenient, but the operational requirement is ownership and lack of conflict with existing DNS services.
Before adding a CNAME, inspect the existing records at that exact hostname. Do not replace a website, verification record or other service merely because the requested label looks available in the email dashboard. If another team owns that hostname, select a different one or coordinate an intentional migration.
Record who manages DNS, who manages the email provider and who will respond if tracked links stop working. This matters when the sending team and website team use different accounts or vendors. A small configuration change can otherwise become an incident with no clear owner.
Configure and verify the actual route
In MailBlastr, open and click tracking settings are configured per sending domain. Setting a custom tracking subdomain returns the tracking CNAME to publish. New sends use the shared tracking host until the custom hostname is verified.
Copy the generated host and target into the authoritative DNS provider. Confirm how that provider handles the zone suffix so the saved name is the intended hostname. Follow any hosting or proxy instructions supplied for the integration rather than changing proxy settings by guesswork.
After verification, send an authorized test message and inspect one ordinary web link. Confirm that its first hostname is the intended custom host, HTTPS loads without a certificate warning and the final destination is correct. Check a message on an actual client used by your audience as well as inspecting its HTML.
A DNS response alone does not test the complete redirect. Certificate provisioning, host routing, destination availability and the message's stored URL can fail at different stages. Capture the failing stage before making unrelated changes to sender-authentication records.
Know which links should stay untracked
Not every link belongs in an engagement redirect. A mailto: action is not a web page, a local fragment is not a normal external destination, and an unsubscribe action should not become a positive engagement signal.
MailBlastr's current link rewriting excludes non-web schemes, its unsubscribe and preference links, and links already wrapped by its tracker. The relevant product documentation explains the supported behavior. Test your actual template because a custom footer or unusual link format may need closer inspection.
For sensitive actions such as account verification or password reset, evaluate whether tracking is appropriate at all. Link scanners may follow URLs automatically. The application should use a carefully designed confirmation flow rather than treating an initial URL fetch as proof of the user's intent.
Preserve links in already-sent email
An email already in someone's inbox contains the URL written when it was sent. Changing the provider setting does not edit that old message. If the old hostname is removed from DNS, its link can stop working even when new messages look correct.
MailBlastr retains prior tracking host bindings and record entries when custom tracking is changed or disabled for new sends. You must also keep the corresponding DNS records at your DNS provider while those old links need to remain reachable. Deleting the sending domain is a separate operation and should be reviewed accordingly.
For a provider migration, inventory the old hostnames and keep representative historical test messages. Verify their links after the new sender goes live. Plan any eventual retirement around the lifetime of those links, rather than deleting records simply because no new email uses them.
Interpret events with appropriate caution
An open event can be caused by image prefetching or privacy services. A click event can come from a security scanner. Conversely, a person can read a message without loading the pixel. These behaviors make an engagement count an imperfect observation of human attention.
Use downstream application activity when it answers the real question. A completed booking, an authenticated preference update or a confirmed purchase is more specific than a redirect request. Keep those events distinct rather than relabeling every click as a conversion.
The open-rate accuracy guide discusses interpreting these signals. A custom hostname can improve consistency and ownership of the visible links, but it does not remove client-side privacy behavior or establish a guaranteed deliverability improvement.
Diagnose a broken tracked link by stage
First check the hostname that appears in the affected email. It may be an older host, not the one currently displayed in settings. Then check whether that hostname resolves and whether its HTTPS endpoint is reachable.
If the redirect loads but the destination fails, inspect the destination URL and application route. If only one message fails, compare its link with a known working message from the same period. If all old messages fail while new messages work, investigate a retired hostname or provider binding before changing the new setup.
Preserve enough context for support: the message identifier, tracking hostname, approximate send time, failing stage and a safe reproduction. Avoid posting private tokens or recipient-specific tracking URLs into public tickets. Redact sensitive portions while keeping the original available through an appropriate private support channel if needed.
Frequently asked questions
Is a tracking domain the same as a sending domain?No. The tracking domain handles link or pixel requests. Sender authentication and envelope routing have different roles, even when all the hostnames belong to the same organization.
Can I turn off a custom tracking domain?MailBlastr supports disabling custom tracking for new messages. Keep old DNS records while previously sent links need to work, and distinguish this setting from deleting the sending domain.
Will a custom tracking domain stop emails going to spam?It does not guarantee inbox placement. Authentication, recipient expectations, message content and sending behavior still need their own review.
Does a tracked click prove the recipient clicked?No. Automated scanners can request links. Use click events as observations and combine them with meaningful application activity when evaluating outcomes.