Capability

One bounded check per link, evidence either way

"Link checking" can mean almost anything. Here it means something exact: each unique link in your delivered test email that clears protected-action and safety screening gets one safe, tightly bounded HTTP check, and whatever happens — an answer, a restriction, a timeout — is recorded as evidence you can act on.

What is inspected

Every unique public link extracted from the delivered email, deduplicated before checking — a link that appears five times is checked once, however many times it appears. Links recognized as action-bearing (unsubscribe, sign-in, reset, purchase and similar) are listed Protected and never requested; destinations refused by network safety policy are listed Blocked. Both wait for your manual review — how protected actions work.

How the checker handles it

Safety screen before anything is sent
The hostname is DNS-resolved and every resolved address must be public. Only standard ports qualify — 80 for http, 443 for https — and URLs with embedded credentials are refused outright.
HEAD request first
One request identified as SendProofs/0.1, sent to the pre-resolved address with TLS certificate verification on. No cookies, no stored credentials, no proxies.
Bounded GET fallback
If the destination rejects HEAD with 405 or 501, a single bounded GET follows. Response bodies are read up to 64 KB, then truncated with a recorded warning.
Redirects followed up to 3 hops
Every hop is recorded and re-screened before it is followed — redirect evidence covers the chain in detail.
Terminal classification, no retries
Each check runs inside a strict budget — 2 s to connect, 5 s to read, 10 s total per resource — and ends in exactly one recorded state.

The terminal states

Healthy: The final destination answered 2xx with no warnings.
Warning: 2xx, but something needs a human decision — a tracking issue on the final URL, an HTTPS downgrade mid-chain, a truncated oversized body.
Broken: Any other error status, a timeout, a connection or TLS failure, or a redirect fault — recorded with the HTTP status or a named error code.
Inconclusive: The destination answered 401, 403 or 429. That is a remote restriction: the site limited automated access, so review the link manually.

A remote restriction is recorded as exactly that. SendProofs never calls it a pass and never calls it a failure — the state exists so a human looks before anyone approves the send.

What every check records

Timestamp: When the check ran.
Duration: How long the whole check took.
Redirect chain: Every hop from the URL in the email to the final destination.
Final URL: Where the chain ended, shown redacted in reports.
Status or error code: The HTTP status when a response was received; when none arrived — a timeout, a connection or TLS failure — an explicit error code carries the evidence instead. Nothing is left as an unexplained blank.

Synthetic exampleA server that refuses HEAD is not automatically broken

Destination	Observed response	Interpretation
campaign.example/help/shipping	HEAD 405, bounded GET 200; no other warnings	Healthy. The fallback supplied the evidence.
campaign.example/offers/expired	HEAD 404	Broken. Correct the destination before a fresh test.
partner.example/event	HEAD 429	Inconclusive. Assign an authorized reviewer; do not repeatedly probe it.

Invented reserved-domain responses, not customer measurements. A HEAD refusal alone is different from a terminal failure. Record the final evidence and a human decision for unresolved destinations.

Safety and limits

One attempt per destination, zero retries, standard ports only, private and internal network addresses blocked before any request — the full request path is documented in the security model. A failed TLS handshake is recorded Broken with its error code, not retried insecurely. And the result means what it says, no more: a Healthy link is evidence that its public destination answered at check time. It is not proof of deliverability, of rendering, or of overall campaign correctness.

Not included

No JavaScript execution and no browser — checks are plain HTTP requests, so script-driven behavior on the destination page is not exercised.
No bot-protection bypass — a destination that refuses automated access is reported Inconclusive and handed to you. SendProofs does not disguise its user agent or work around the restriction.
No mailbox-existence checks — SendProofs checks the destinations of links in your email, not whether any recipient address exists.

Redirect evidence

Redirects followed up to three hops with every step recorded — source, target and status — plus warnings for HTTPS downgrades, loops and dead ends.

Protected actions

Unsubscribe, sign-in, reset and purchase links are identified before any request and never opened. SendProofs lists them for your manual review instead.

Campaign tracking

UTM review on the final URL after every redirect: missing required keys, duplicate keys, blank values and non-canonical casing, recorded per link.

Put your campaign's links on the record

Upload the delivered test — one bounded check per unique link, evidence for each.

Create workspace