zintara.io

Deliverability · Practical guide

Sending domain vs tracking domain: trace separate identities

Map the visible sender, authenticated domains and link hostnames before attributing a delivery issue to a tracking setting.

Reviewed · Examples are illustrative

Who this helps: Operators diagnosing authentication, receiving-policy and delivery failures.

Define the decision

A tracking hostname serves links or measurement requests. It does not replace the SMTP envelope identity, DKIM signing domain or visible From domain. A custom link domain can still have DNS, certificate or redirect problems of its own.

Work through the procedure

  1. Inspect the received From, Return-Path and DKIM signature.
  2. List every link host and its final destination.
  3. Test redirects and TLS without entering recipient credentials.
  4. Change only the identity or link path implicated by the evidence.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Visible From: [email protected]
DKIM signer: example.com
Click host: links.example.com
Final destination: example.com/resources
SPF failure diagnosis still begins with smtp.mailfrom, not the click hostname

Read the result

The map prevents a cosmetic domain change from being mistaken for an authentication repair. It also exposes unrelated third-party links that a branded first hop can conceal.

Check before moving on

  1. Inspect the final received links, not just the editor.
  2. Recheck redirect destinations after a campaign edit.

Limits and next action

Do not claim a branded tracking hostname guarantees placement. Use only tracking capabilities available in the deployed configuration and keep opt-out links functional.

Source: Zintara deliverability product context

Source references

Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.

Related guides

Explore the Zintara workflow