Custom return-path and tracking domains are the two branding and authentication settings that most senders skip, and they matter for different reasons. A custom return-path lets SPF align with your From domain, so DMARC has two ways to pass. A custom tracking domain puts your own name in click and open links. This guide explains both, shows the DNS records involved and describes how to test them.
The three domains in every email
A single message carries several domain names, each used for a different check. Understanding the difference explains why these settings exist.
| Name | Where it appears | Used for |
|---|---|---|
| From domain | The visible address in the From header | DMARC compares the other checks against this domain |
| Return-path domain | The envelope sender (MAIL FROM), shown in a Return-Path header | SPF is checked here, and bounces are delivered here |
| DKIM signing domain (d=) | The signature header | DKIM verification, and alignment with the From domain |
| Tracking domain | Inside links and tracking pixels in the body | Link reputation, security scanning and brand trust |
Alignment: why the return-path domain matters
DMARC requires that at least one of SPF or DKIM passes and that the passing domain is aligned with the From domain. Aligned means related: with relaxed alignment, which is the default, a subdomain of the same organisational domain counts. If your platform uses its own domain as the return-path, SPF passes for that domain but it does not match yours, so SPF does not help DMARC. With a custom return-path on your own subdomain, SPF passes and aligns.
| Setup | SPF result | DMARC outcome |
|---|---|---|
| Return-path on the platform domain, aligned DKIM | Pass, not aligned | Passes through DKIM only |
| Custom return-path on your subdomain, aligned DKIM | Pass and aligned | Passes through both; more resilient |
| Custom return-path, DKIM broken in transit | Pass and aligned | Still passes through SPF |
| Platform return-path, DKIM broken in transit | Pass, not aligned | Fails |
SPF does not survive forwarding. When mail is forwarded, SPF is checked against the forwarder, so it usually fails. DKIM is the signal that survives. That is why aligned DKIM is the primary goal and a custom return-path is a second layer, not a replacement.
Setting up a custom return-path
- Choose a subdomain. Pick a name such as bounce.mail.example.com that is used only for bounces. Keep it separate from your tracking subdomain.
- Add the record your platform specifies. This is commonly a CNAME to a platform name, or an MX record that routes bounces to the platform. Copy it exactly.
- Check the SPF record for the subdomain. The platform normally manages the SPF policy behind the CNAME. If it does not, publish an SPF record for the subdomain that authorises the platform.
- Wait and verify. Allow the record TTL to pass and use your platform to verify the domain, as described in our guide to verifying a sending domain.
- Send a test and read the headers. Confirm that the Return-Path header uses your subdomain and that the authentication results show SPF pass with that domain.
Return-Path: <bounce+abc123@bounce.mail.example.com>
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=bounce.mail.example.com;
dkim=pass header.d=mail.example.com;
dmarc=pass header.from=mail.example.comIn the example, the return-path domain is a subdomain of the From domain, so relaxed alignment holds and SPF contributes to the DMARC pass.
Setting up a custom tracking domain
Link tracking rewrites each link in your message to pass through a redirect, so that clicks can be counted. Open tracking adds a tiny image whose load is counted. Both use a domain. By default that domain belongs to the platform and is shared by many customers. A custom tracking domain replaces it with a subdomain of yours.
- Choose a subdomain. For example links.example.com. Use a name that looks natural to a recipient.
- Publish the CNAME. Point the subdomain at the name your platform gives you. A CNAME must be the only record at that name.
- Wait for the certificate. The platform requests a certificate for the subdomain once the CNAME resolves. This can take minutes to hours.
- Enable it for sending. Select the tracking domain in your sending settings or per stream, so new messages use it.
- Click a test link. Open a message, click a tracked link and confirm that it loads over HTTPS with no browser warning and lands on the right page.
Why HTTPS is not optional
A tracked link is the first thing a recipient, a browser and a security scanner touch. A link that begins with http, or that shows a certificate warning, invites suspicion and loses clicks. Some corporate gateways rewrite or block such links altogether. Confirm that the certificate is valid before you switch tracking on, and check that renewal is automatic.
Benefits and trade-offs of a custom tracking domain
| Benefit | Trade-off |
|---|---|
| Link reputation is yours alone, not shared with unknown senders | Your own mistakes also fall on your domain, so keep it clean |
| Links look consistent with your brand | Another subdomain and certificate to maintain |
| Easier to separate streams, with one tracking domain per stream | More DNS records to document |
| Fewer surprises if another sender on a shared domain is blocklisted | A new domain has no history, so introduce it gradually |
Introduce a new tracking domain gradually. A domain that has never been seen in links has no reputation, good or bad, and sending large volumes with it from day one can look unusual. Follow the same cautious ramp described in our warm-up guide.
Should you turn tracking off for some messages?
Open and click tracking are conveniences, not requirements. For password resets, login codes and similar security messages, many teams switch tracking off. The links should go straight to your site, and rewritten links can make a genuine message look like phishing to users and filters. Note too that open tracking has become unreliable as mail apps preload images. Treat opens as a rough signal and clicks and conversions as the metrics that matter.
A worked example: two streams on one domain
Imagine a shop that sends order confirmations and weekly promotions. It keeps the root domain example.com for staff email and creates two sending subdomains, one for each stream. Each gets its own set of records, so the two reputations never mix.
| Stream | From domain | Return-path | Tracking domain |
|---|---|---|---|
| Transactional | orders.example.com | bounce.orders.example.com | none, tracking off for security messages |
| Promotional | news.example.com | bounce.news.example.com | links.news.example.com |
With this layout, a spike in complaints on the promotional stream hurts news.example.com and its link domain, while order confirmations keep their own clean history. Every return-path is a subdomain of its own From domain, so SPF aligns under relaxed alignment. Each stream signs with its own DKIM selector, which also makes it easy to rotate one key without touching the other. The cost is a handful of extra DNS records, which is a small price for the separation.
When you add a stream later, copy the pattern rather than inventing a new one. Consistent naming makes it obvious in a header, a DMARC report or a blocklist notice which stream a message belongs to, and that speeds up every investigation.
Troubleshooting
| Problem | Likely cause | Fix |
|---|---|---|
| Return-Path still shows the platform domain | Custom return-path not enabled for the stream | Select the domain in sending settings and resend |
| SPF passes but DMARC fails | Return-path domain not aligned with From | Use a subdomain of the From domain |
| CNAME cannot be added | Another record exists at that name | Use a fresh subdomain for the CNAME |
| Tracked link shows certificate warning | Certificate not issued or expired | Check the CNAME and the platform domain status |
| Tracked links return an error | CNAME points to the wrong target | Compare with the value in your account |
| Links blocked by a recipient gateway | New tracking domain with no reputation | Ramp up gradually and avoid shorteners |
Keep it maintained
- Document every subdomain and its purpose in one place.
- Check the records after any DNS migration or registrar change.
- Monitor certificate expiry for tracking domains.
- Re-test alignment after changing platforms or adding a new sending service.
- Review DMARC reports for sources that fail alignment.
Want a second pair of eyes on your DNS? Send us your sending domain and we will check the return-path and tracking records.
Further reading and sources
Frequently asked questions
What is the return-path address?
It is the envelope sender, also called MAIL FROM or Return-Path, to which bounces are sent. It is separate from the From address that people see. SPF is checked against the domain in this envelope address, not against the visible From address.
Why does a custom return-path matter?
DMARC passes when SPF or DKIM passes and aligns with the From domain. If the return-path uses your platform domain, SPF passes but does not align with your From domain. A custom return-path on your own subdomain lets SPF align, giving DMARC a second route to pass in addition to DKIM.
Do I need a custom return-path if DKIM is aligned?
DMARC needs only one aligned pass, so aligned DKIM is enough. A custom return-path is still worth having as a second layer, because it keeps DMARC passing if a DKIM signature breaks in transit and it keeps bounces branded to your domain.
What is a tracking domain?
It is the domain used in rewritten links and open-tracking pixels. With a custom tracking domain, links point to your own subdomain such as links.example.com instead of a shared platform domain, which looks more trustworthy and keeps your link reputation separate from other senders.
Why does the tracking domain need HTTPS?
Browsers and mail clients warn about, or block, insecure links. Links that start with http can trigger warnings and lower click-through, and some security scanners treat them with suspicion. Make sure the platform issues and renews a certificate for your tracking subdomain.
Can I use the same subdomain for bounces and tracking?
It is better not to. The two roles use different record types and are handled by different systems. Using separate subdomains avoids conflicts, such as a CNAME clashing with an MX record on the same name.
Why is my tracking link showing a certificate warning?
The certificate for the tracking subdomain has not been issued yet, has expired, or the CNAME does not point where the platform expects. Check the record, wait for issuance and confirm that the platform shows the domain as active.
Will a custom tracking domain improve deliverability?
It can help indirectly. A branded link domain on your own reputation avoids sharing a link domain with unknown senders, and it makes the message look consistent. It does not override poor list quality or complaints.
Can I turn off link tracking?
Yes, in most platforms you can disable click and open tracking, per message or by default. For sensitive messages such as password resets, turning tracking off is common, because rewritten links can confuse users and security tools.