The URLs you paste are not the URLs recipients get
A generic link checker — a website crawler or a paste-a-list tool — is good at exactly what it was built for. Pointing one at an email campaign fails in two structural ways: it checks the wrong URLs, and it opens links that must never be opened. Here is the fair version of that comparison.
Where a generic checker is the right tool
Checking your website for dead links, sweeping a docs site after a restructure, validating a pasted list of URLs that came from anywhere but an email — a generic checker does these well, and SendProofs does not do them at all. SendProofs accepts exactly one input: a delivered test email saved as a .eml file. If your URLs live outside an email, a crawler or list checker is the correct tool and there is nothing to replace.
The two tools, side by side
- Input: whatever URLs you give it — a site to crawl or a list to paste. For an email, that usually means the template or draft URLs.
- Requests every URL it is given. Correct for a website crawl; hazardous for a campaign that contains unsubscribe and account actions.
- Output: a status per URL — exactly the right shape for finding dead links on a site.
- No notion of an email: no MIME parsing, no link-versus-image distinction, no tracking review.
- Input: the .eml you saved from your own inbox — the message after your sending platform rewrote the links and added tracking.
- Classifies every URL before any request; links recognized as action-bearing are marked Protected and never requested.
- Records the redirect chain to the final URL per link, reviews UTM values on that final URL, and checks image content types.
- Reports six states — Healthy, Warning, Broken, Protected, Blocked, Inconclusive — each mapped to a next action, instead of a bare status list.
The input problem: which URLs get checked
A checker can only check what you feed it, and for an email the feedable thing is usually the template — the links as you wrote them. Wherever click tracking is on, the sending platform rewrites those links through its own domain and appends parameters, so the delivered message carries different URLs than the draft. A clean run over the template list is then a true statement about URLs your audience never clicks.
The delivered .eml is the artifact that carries those final links in a form you can hand to a checker — which is why it is the input SendProofs accepts. Why delivered-email checks.
The action problem: some links must not be opened
Requesting every URL is a generic checker doing its job — on a website, every page is meant to be fetched. A campaign email is different: it carries unsubscribe and preference links, sign-in and reset links, order and confirmation actions — links designed to do something when opened. Run a request-everything tool over a real campaign and the QA step itself can trigger those actions.
SendProofs classifies every URL before any request is made. Links recognized as action-bearing by URL and link-text patterns are marked Protected and never requested — and if an ordinary-looking link redirects toward such an action, the check stops at that hop. Protected items appear in the report marked "Not opened", handed to you for deliberate manual review. How protected actions work.
Evidence a bare status list cannot carry
| Resource | State | Evidence |
|---|---|---|
| campaign.example/launch?utm_source=email&utm_campaign=aug-launch | Healthy | 200 after 2 redirects · 312 ms · 14:02 UTC |
| example.com/unsubscribe/%5BREDACTED%5D | Protected | Not opened — action-bearing link, review manually |
| partner.example/offer | Inconclusive | 403 — destination limited automated access, review manually |
Sample data, consistent with the full sample run: 24 unique resources (18 links, 6 images), of which 20 consumed a check; one broken destination left the campaign outcome Failed. Checks are bounded and identified — HEAD-first, up to 3 redirect hops, strict timeouts, the SendProofs/0.1 user agent, 0 retries. Redirect evidence in depth.
Where neither is the answer
- How the email renders in different clients — neither a link checker nor SendProofs renders anything. That is a job for a rendering-testing suite.
- Whether the campaign reaches inboxes — neither tool measures placement, and that is a job for deliverability tooling, not either of these.
Check the email that actually arrived
Free workspace — 100 resource checks each month, no card at signup.