Article 0433

How to Configure a Custom Tracking Domain on a New Email Platform

A custom tracking domain replaces generic click or view-tracking hostnames with a domain associated with the sender’s brand. It is distinct from the visible From domain and from the domain used for SPF or DKIM. Its DNS target and certificate process are provider-specific. This guide addresses branded tracking domain setup. The practical objective is to make the change observable and reversible: define the source of truth, document the destination behavior, test representative records, and retain evidence that the result matches the intended business process.

What must be controlled

Branded tracking domain setup is not complete simply because a setting was copied or an import reported success. The important question is whether the downstream user, system, or recipient experiences the intended result. Identify the record or event that starts the process, the system that owns the data, the rule that changes it, and the evidence that proves the result.

Before making changes, record the current behavior and the intended behavior side by side. Include the affected audience, relevant fields, timing, exceptions, and dependencies. Preserve a dated source export or configuration snapshot where appropriate. Limit access to personal data and secrets, and do not place API credentials or private subscriber information in public files or screenshots.

Implementation procedure

1. Choose a dedicated subdomain, such as links.example.com, and confirm that it is not already used for a website, mail routing, or another tracking vendor. Record the current DNS record before making a change.
2. Copy the exact CNAME or other DNS value from the new provider. Do not guess the target, proxy the record, or reuse an old vendor target. Check for conflicting A, AAAA, or CNAME records.
3. Publish the record at the authoritative DNS host. Allow for DNS caching, then query the record from more than one resolver and compare the returned target with the provider’s instructions.
4. Complete the provider’s domain verification and certificate provisioning. Test a real campaign link in a controlled send and inspect the final hostname, redirect destination, HTTPS certificate, and query parameters.
5. Update templates, link branding settings, and documented allowlists. Keep the old tracking domain available during the transition where the provider permits it, and monitor click redirects after cutover.

Worked example

A tracking CNAME does not itself authenticate the From address. Keep SPF, DKIM, and DMARC checks separate from tracking-domain verification.

For a controlled test, use synthetic or internal test records wherever possible. Give each test a unique identifier, write down the starting conditions, and capture the observed result. This makes it possible to distinguish a real platform defect from a test record that had unexpected history or stale data.

Verification and acceptance criteria

Accept the change only when the expected result can be reproduced. At minimum, check one normal case, one boundary or missing-data case, one duplicate or retry case where relevant, and one case that must be excluded. Compare the source and destination values rather than relying only on a dashboard status message.

• Correctness: the destination value, message, route, or event matches the approved rule.
• Completeness: required records and dependencies are accounted for, including rejected or unresolved items.
• Safety: suppression, access restrictions, privacy controls, and rollback arrangements remain effective.
• Traceability: a reviewer can find the test input, timestamp, observed output, exception, and approval.

If the test fails

Pause the affected rollout or workflow before making repeated edits. Preserve the error message, request or event identifier, relevant timestamp, sanitized input, and current configuration. Classify the issue as a data-mapping problem, permission or authentication failure, timing issue, provider limitation, or unexpected business rule. Correct one cause at a time and rerun the same test case. If the failure affects consent, unsubscribe handling, security, or live transactional messages, follow the organization’s incident escalation process.

Completion checklist

• Purpose, owner, scope, and source of truth are documented.
• Current and destination behavior have been compared.
• Relevant records, dependencies, and exception cases are accounted for.
• Normal, boundary, and failure tests have recorded results.
• Personal data and credentials are handled with appropriate access controls.
• Unresolved risks have an owner, due date, and explicit decision.
• A reviewer has approved the evidence before production use.

Frequently asked questions

Can this task be completed by copying the old platform settings?

Not safely in every case. Platform features, field types, event timing, and defaults can differ. Translate the intended business rule, then verify it in the destination with test records.

What evidence should be retained?

Keep the approved mapping or configuration, test inputs and outputs, timestamps, error details, reconciliation totals where relevant, and reviewer sign-off. Store only the personal data needed for the purpose and follow the organization’s retention policy.

When should the change go live?

Only after the acceptance criteria pass, high-impact exceptions are resolved, and the accountable owner approves the rollout. If a safe rollback is not available, treat that as an unresolved risk rather than assuming the change is ready.