What happens between the click and the page

When click tracking is on, your sending platform replaces each destination with a URL on its tracking domain. A click hits the tracker first, gets recorded, and is redirected onward. Add a link shortener, a partner's own tracker or a legacy URL that itself redirects, and the shape becomes tracking domain → intermediate → destination. The address printed in the delivered email is only the first stop; the page your reader lands on is at the other end of the chain.

A redirect is an HTTP response that says "not here — go there": a 3xx status plus a Location header naming the next URL. Each hop is one request, one status and one target. The common statuses, in plain terms:

The email is frozen the moment it is sent; every other part of the chain keeps moving. The most common failures live in the middle, not at the destination:

• Retired campaign slugs. The tracker archives or deletes the campaign, and its short links stop resolving — the destination page is fine, but no click ever reaches it.
• Expired tracker configuration. A custom tracking domain whose DNS or TLS setup lapses turns every link in every past email into an error page.
• Dead intermediate domains. A shortener or partner domain in the middle of the chain shuts down, and the chain ends at hop two.

This is why checking the template's destination URLs is not enough: the destination can answer perfectly while a middle hop is dead. Only the delivered email contains the chain that recipients will actually traverse.

• An HTTPS→HTTP downgrade mid-chain. One hop steps from an encrypted URL to plain HTTP. SendProofs records it as a warning on the resource so you can decide whether that hop belongs in your campaign.
• Loops. A hop points back to a URL already visited. Recorded as broken, with an explicit error code.
• Chains at the hop limit. More than 3 hops is recorded as broken. A chain that deep is fragile even on a good day — every hop is another dependency between your reader and the page.
• A redirect with no target. A 3xx status without a Location header goes nowhere; recorded as broken.
• A hop into an account action. If a redirect leads toward a recognized action link — sign-in, unsubscribe — the check stops at that hop and the resource is reported Protected, with the chain recorded up to that point.

Redirects are followed up to 3 hops per resource, and every hop is recorded — from, to, and the status that caused it. Each next URL is safety-screened before it is followed, exactly like a first request: private and internal addresses are refused, and the protected-action patterns run again per hop. The whole chain fits inside one bounded time budget. Redirect evidence in depth.

SendProofs follows HTTP redirects only. There is no browser and no JavaScript execution, so a JavaScript redirect or a meta-refresh interstitial is invisible — to SendProofs and to any other non-browser checker. A destination that answers 200 and then forwards with a script is recorded as a 200 at that URL: the chain in the report is the HTTP chain, and the recorded final URL is the last HTTP address, not necessarily the page a browser ultimately shows.