Tracking domains: what they do and where they fit in cold email

A tracking domain is not the domain that sends the email.

It is the hostname a sequencer uses for open-tracking requests, click redirects, or both. The visible From address and the authenticated sending path still have their own jobs.

That distinction matters because teams often change a tracking CNAME while trying to fix an SPF, DKIM, mailbox, or list problem it cannot solve.

Separate the domain roles

Visible From
person@mail.example.com
        |
        | message is authenticated and sent
        v
Google Workspace or Microsoft 365

Tracking request or clicked link
track.example.com
        |
        | CNAME points to the sequencer's documented target
        v
sequencer tracking or redirect service
        |
        v
final landing page

One domain can contain several hostnames, but each hostname needs a documented role.

Do not call all five “the sending domain.”

Use the sequencer's current setup source

lemlist, Smartlead, and Instantly each document a custom tracking-domain path using a CNAME. The exact host, target, validation, proxy, SSL, and URL rules belong to that platform.

Do not copy the CNAME target from an old article, screenshot, or another sequencer. Open the current provider instructions while making the DNS change.

Keep each sequencer's record separate

A current provider guide may specify a hostname pattern, CNAME target, validation step, account location, proxy rule, or certificate wait. Those details can change. The safe reusable process is to record the source and verify the path, not memorize the target.

For each provider:

• lemlist: use the current custom tracking-domain help page for the subdomain, CNAME target, verification flow, and campaign or account assignment. Keep its separate guidance about open and click tracking attached to the measurement decision, not the DNS record.
• Smartlead: use the current help-center workflow for the host, target, workspace or client assignment, and validation state. Do not copy a record from another Smartlead workspace without confirming how the provider maps it.
• Instantly: use the current custom tracking-domain guide for the host, target, account or workspace assignment, and documented SSL or redirect behavior. Confirm current proxy guidance before changing a DNS-provider setting.

If the team changes sequencers, do not point the old CNAME at the new platform by analogy. Create a new source record, test the new target, update campaign ownership, and retire the old path with a rollback window.

The setup record

sequencer:
official_source_url:
source_checked_at:
account_or_workspace:
tracking_hostname:
record_type: CNAME
cname_target:
dns_proxy_state:
dns_owner:
sequencer_owner:
validation_result:
ssl_result:
redirect_test:
tracking_enabled_for:
rollback_record:

If the DNS provider supports proxying, confirm the sequencer's current instruction before enabling it. A proxied CNAME can change how validation, SSL, or redirects behave.

Do not place secrets in this record. It should identify the account or workspace and owner without copying credentials, tokens, or recovery codes into the handoff.

Understand the request path

Open tracking generally loads a remote resource when a message is opened. Click tracking generally rewrites a link so the browser requests the tracking hostname before redirecting to the final destination.

That creates several independent states:

An operator should be able to identify which state failed. “Tracking is broken” is not enough for the DNS owner to act.

Verify the path

After DNS has updated:

1. Resolve the CNAME from outside the DNS account.
2. Confirm the returned target matches the provider's current documentation.
3. Complete the sequencer's validation step.
4. Check HTTPS and certificate behavior for the tracking hostname.
5. Send an internal test message through the real campaign path.
6. Inspect the open or click URL.
7. Confirm the redirect reaches the intended final destination.
8. Disable or roll back tracking and confirm the campaign still has a safe path.

Do not test on a live prospect list.

Capture the test evidence

Use a test record with:

test_message_id:
sent_at:
from_domain:
tracking_hostname:
sequencer_workspace:
tracking_mode: open / click / both
resolved_cname:
https_result:
redirect_chain:
final_destination:
event_visible_at:
tested_by:

Inspect the redirect chain without publishing a live prospect URL. Confirm the final destination, expected query parameters, and certificate. If the platform validates DNS but HTTPS fails, keep the problem in the certificate or provider-provisioning layer rather than rewriting authentication records.

Repeat the test after a DNS-provider, sequencer, workspace, or tracking-setting change. The earlier green check does not prove the new path.

Decide whether the measurement is worth it

Open and click tracking can be useful. It can also add redirect infrastructure, pixels, scanners, bot traffic, privacy noise, and another moving part to the message.

The decision should be explicit:

lemlist's own current guidance discusses the tradeoff and recommends limiting or disabling open and click tracking in some cold-email workflows. That is lemlist's guidance, not a universal law. It is still a useful reminder that more measurement is not automatically better measurement.

Choose the event that changes a decision

If nobody will act differently after an open, the pixel may be collecting noise. If a click is required to evaluate the campaign, keep the redirect path owned and monitored. If replies are the real outcome, do not let open counts become a substitute because they are easier to graph.

Write the decision before enabling tracking:

event used:
decision it changes:
known measurement limits:
owner:
review cadence:
disable condition:

That makes “turn tracking off” a reversible operating choice instead of an argument about generic best practice.

Troubleshoot without touching the sending path

Keep a before-and-after test. Change one variable. A tracking problem should not become a reason to replace every mailbox or republish authentication.

Make rollback a real procedure

Before enabling the hostname, decide how the campaign behaves when tracking is disabled or the DNS record is removed.

The rollback record should contain:

• previous DNS value or intentional blank state;
• sequencer setting to disable open, click, or both;
• campaigns and workspaces affected;
• owner allowed to make each change;
• internal message used for validation;
• method for confirming direct final links still work;
• evidence and timestamp after rollback.

During an incident, disable the smallest affected layer. If click redirects fail but authentication and sending are healthy, pause or remove click tracking according to the tested path. Do not improvise a new CNAME target from memory.

After migration, remove abandoned tracking records once the rollback period and active-campaign review are complete. An old CNAME can leave an unexplained dependency on a provider the organization no longer uses.

Include tracking hostnames in domain offboarding. Confirm whether the hostname is referenced by active campaigns, templates, saved links, or historical reports; disable the platform setting; test direct destinations; remove the DNS record after the approved window; and record the final state. Do not let a canceled sequencer keep control of a branded redirect path by accident.

Review the inventory whenever a new sequencer or client workspace is added. One hostname should not be silently reassigned across unrelated owners.

Run the rollback test before the first important campaign, not during the first redirect incident. Save the direct destination, disabled-tracking result, DNS result, and owner approval together. The exercise should prove that replies and sending continue normally when the optional measurement layer is removed.

Repeat it after changing sequencers or DNS providers; the old evidence no longer proves the current path.

Do not buy the deliverability shortcut

Sequencer pages often describe custom tracking domains using deliverability or reputation language. Treat that as vendor positioning unless a controlled test supports the claim for your setup.

A custom tracking domain can give the tracking path a branded hostname and separate it from a vendor's generic tracking hostname. It does not repair:

• invalid prospect data;
• broken SPF, DKIM, or DMARC;
• a disabled mailbox;
• poor audience fit;
• an aggressive schedule;
• a provider restriction;
• a misleading offer;
• broken suppression.

If the symptom is broader than tracking, use the deliverability diagnostic. The cold email infrastructure checklist shows where the tracking hostname belongs in the wider domain and mailbox system.

Cheap Inboxes supports domain and DNS operating workflows. The sequencer remains the source of truth for its tracking CNAME and tracking behavior. Keep those owners separate, and rollback stops being a scavenger hunt.

Sources

• lemlist custom tracking domain setup
• lemlist guidance on tracking clicks and opens
• Smartlead custom tracking domain setup
• Instantly custom tracking domain setup
• Cheap Inboxes developer overview