Answer First
Email link wrapping is why your beautifully branded campaign URL never actually appears in the email your recipients open. Before you hit send, your email service provider (ESP) rewrites every tracked link so clicks first pass through its click-tracking redirect — and only then reach your branded subdomain entry, which forwards to the landing page. That extra hop in front of your entry changes what you can verify, count, and fix after the send. Here’s what it is, why it happens, and what to check.
Definition: Email link wrapping (also called ESP click tracking or URL wrapping) is when an email platform replaces the destination URL of every tracked link with its own tracking URL on the ESP’s domain. When a recipient clicks, the browser first hits the ESP’s tracking redirect, which records the click and then redirects to the original URL — in this case, your PushULink branded subdomain entry — which forwards to the final landing page.
Why: The ESP needs to count clicks and attribute them to a campaign, recipient, and send — which requires the click to pass through infrastructure it controls. So it inserts its own redirect first: the recipient never reaches your entry until the ESP has logged the click.
Example: You build a campaign entry at https://go.yourbrand.com/spring-sale that 301-forwards to https://www.yourbrand.com/sale?utm_source=email&utm_campaign=spring. Your ESP rewrites the href to https://t.your-esp.example/click?u=abc123&dest=https%3A%2F%2Fgo.yourbrand.com%2Fspring-sale. A recipient’s click now travels: ESP tracking redirect → your branded subdomain entry → landing page. Two redirects, two systems, two sets of logs.
Key Facts
- Link wrapping is standard behavior in essentially every major ESP — it’s how click-throughs are measured.
- The wrapped URL is what ships: recipients never click your branded URL directly, so your entry only sees traffic that already passed through the ESP’s tracking redirect — and every click makes at least two hops: the ESP’s redirect (usually a 302), then your entry’s redirect (commonly a 301).
- Query parameters must survive both hops: UTM parameters and click IDs like
fbclidandgclidare useless if they don’t arrive intact at the landing page. - ESP click counts and your console’s access statistics measure different events: the ESP counts requests to its tracking redirect, your console counts requests that reach the entry. They will differ — legitimately.
- Email security tools can add yet more layers: Microsoft Defender for Office 365 Safe Links rewrites scanned URLs through
safelinks.protection.outlook.com. - A sent email is immutable: the wrapped href is baked in at send time, so if it breaks, the fix lives in the entry it points to, not in the email.
Expert Explanation
How the chain works
Each redirect is one extra HTTP round trip: the browser requests the URL in the Location header of the 3xx response (RFC 9110; MDN’s Redirections guide). Link wrapping stacks two of them in front of your landing page:
- The recipient clicks the wrapped link, which points to the ESP’s tracking domain.
- The ESP logs the click and responds with a redirect (typically 302) to the entry URL you configured in the Console.
- Your entry redirects to the final destination.
Your branded subdomain entry is the second hop, not the first: the ESP sees every click before you do, and if your entry fails, the ESP still counts the click. That ordering is why choosing between 301 and 302 for campaign entries matters — a cached 301 changes how repeat clicks behave across the chain.
What breaks silently
The most common failures are invisible at send time:
- Query parameters get lost or mangled. The wrapped URL encodes your entry URL, parameters included, and most ESPs preserve them — but some normalize, append, or truncate query strings. If
utm_source,utm_campaign, or a click ID likefbcliddoes not survive both hops, attribution silently breaks. - The entry changes after the send. The wrapped link resolves to whatever the entry does now, not at send time. Pause it, change its destination, or rotate it, and every previously sent email pointing at it changes too.
- Redirect codes interact badly. A cached 301 can bypass the ESP’s tracking redirect on repeat clicks, deflating click counts even though traffic still flows.
Why reconciliation is a two-system problem
Your ESP counts a click when its tracking redirect fires; your Console counts a request when it arrives at the entry, and its access statistics and logs show what actually got there — query strings attached, if you look. Bots, pre-fetching clients, security scanners, and double clicks widen the gap. It’s the same discipline as checking the campaign entry before rewriting ads when clicks arrive without conversions: confirm the chain delivered the right URL and parameters before blaming creative.
Traceable changes: diagnosing a dead campaign
A sent email cannot be edited, so “what broke my wrapped link?” almost always answers “something changed in the entry.” PushULink records changes to entries — who, what, when — so when clicks stop resolving after a send, you check the change history before resending. A link that dies at 2 p.m. on Tuesday lines up against a destination edit at 1:55 p.m. That’s the same evidence trail auditors review in how entry management supports compliance audits.
Decision Framework
Run this checklist before every send through a branded entry.
| # | Check | Why it matters | Where to verify |
|---|---|---|---|
| 1 | Entry destination matches the final landing page, including path | The wrapper points at the entry, not the page | Console entry detail / OpenAPI |
| 2 | Entry status is active and stays active through the send window | A paused or expired entry turns clicks into dead ends | Console status field |
| 3 | UTM parameters and fbclid/gclid survive both hops | Lost parameters mean lost attribution | Test send → click → inspect final URL and entry logs |
| 4 | ESP click counts reconciled against console access statistics | Distinguish normal gaps from real failures | Compare ESP report with Console stats after delivery |
| 5 | Entry change history noted before send | Correlate later breakage with a change | Console change log |
| 6 | Test send clicked from a real inbox, not just a preview | Previews don’t exercise the ESP’s live redirect | Real device, real email client |
Two items deserve extra weight. For item 1, verify the destination the way a recipient would — mirroring what to do when the ad is approved but the landing page changed: the link you promised and the link that ships must be the same. For item 3, never assume parameter survival: click the wrapped link from a test send and confirm every parameter still arrives, then check the entry’s logs for the exact request.
Practical limits of the checklist: it verifies what you control, not what happens after delivery. Your ESP may strip parameters in configurations you don’t manage, recipient-side scanners may wrap links you never touch, and click counts will still diverge because the two systems count different events. Its job is to make those gaps explainable before a campaign goes live.
Key Takeaways
- Link wrapping puts the ESP’s tracking redirect directly in front of your branded subdomain entry — your entry is the second hop in a chain you only partially control.
- Verify the entry’s destination and status before the send; the wrapped link resolves to whatever the entry does at click time, not send time.
- Test query-parameter survival with a real click from a real inbox — UTM and click IDs that die in transit make the whole campaign unmeasurable.
- Reconcile ESP click counts against console access statistics and logs: the systems count different events, and bots and scanners widen the gap.
- When a wrapped link breaks after the send, the email is not the fix. Check the entry’s traceable change history first, then fix the entry.
FAQ
Q: Is link wrapping the same thing as my branded subdomain redirect?
A: No — two separate hops. Link wrapping is the ESP’s click-tracking redirect inserted in front of your URL at send time; your branded subdomain entry is the second redirect to the landing page. Different systems, different logs: the ESP counts clicks on its tracking URL, your Console counts requests that reach the entry.
Q: Why do my ESP click counts and my console access statistics never match?
A: Because they count different events. The ESP counts every request to its tracking redirect — bots, pre-fetching clients, security scanners, repeat clicks included. Your console counts requests that reached the entry. Expect the ESP number to be higher and use the console logs to see which traffic made it through — reconciliation, not a discrepancy.
Q: A wrapped link broke after the send. Do I need to resend the email?
A: Usually not. The wrapped href is fixed at send time, but the wrapper simply resolves to your entry — so whatever the entry does now is what recipients get. Check the change history first: a destination edit or status change is the most common cause. Fix the entry, and existing clicks work again.
Q: Will UTM parameters and fbclid survive link wrapping?
A: Usually yes, but never assume it. The wrapped URL encodes your full entry URL, parameters included, and most ESPs preserve them; the entry must then forward the query string to the destination. Verify with a test send: click the wrapped link from a real inbox and confirm the landing page URL still contains every parameter. If one is missing, the console logs show the request that reached the entry.
Sources
- RFC 9110: HTTP Semantics — defines 3xx redirect responses and how clients follow them.
- Redirections in HTTP — MDN Web Docs — permanent vs. temporary redirects, and why each hop adds a round trip.
- Use UTM parameters to track website traffic — Google Analytics Help — reference for campaign tracking parameters.
- Safe Links in Microsoft Defender for Office 365 — Microsoft Learn — documents how email security tools rewrite and wrap URLs in delivered mail.