Capability

Check the email that arrived, not the draft you designed

By the time a campaign reaches an inbox, most sending platforms have rewritten its links through a click-tracking domain, appended their own parameters and often rehosted images. The draft no longer describes what recipients get. SendProofs inspects the delivered test email — the .eml file you save from your own inbox — because that is the artifact that contains the final links.

What is inspected

One saved test email file with the .eml extension, uploaded from your machine. It works with an email saved from Gmail, Outlook on the web or Apple Mail — exact saving steps are in the guides for Gmail, Outlook on the web and Apple Mail.

The draft, the template and the editor preview all show the URLs you typed. The delivered copy shows the URLs your recipients will click: the tracking-rewritten links with every appended parameter. Those are the ones worth checking before send.

How the checker handles it

From the HTML part, SendProofs extracts every a[href] link and every remote img[src] image; plain-text emails fall back to link extraction from the text. Only http and https URLs qualify. Each URL is normalized and deduplicated, with occurrence counts kept — a link that appears five times is checked once and reported with its count. A duplicate upload of the same submission is idempotent: it is recognized and not ingested twice.

One .eml filethe saved test email; other formats are rejected with an explicit error

2 MB maximumlarger messages are rejected during ingestion, before any resource is stored or checked

100 MIME partsmore parts, or pathological nesting, and the email is refused

500 unique resourcesper email; beyond that the upload is rejected with an explicit error

Limits produce explicit errors, not partial runs — an email over a limit is rejected during ingestion, before any resource is stored or checked.

What the report shows

Sample data August launch — final test · saved from the inbox, uploaded as .eml

Resource	State	Evidence
campaign.example/launch?utm_source=email&utm_campaign=aug-launch	Healthy	200 after 2 redirects · 312 ms · 14:02 UTC
img.campaign.example/hero-aug.png	Healthy	200 · image/png · 96 ms
campaign.example/pricing/summer-2026	Broken	404 at final destination — fix in your sending platform, then recheck

Sample data. The full sample run covers 24 unique resources — 18 links and 6 images: 15 Healthy, 2 Warning, 1 Broken, 3 Protected, 2 Inconclusive and 1 Blocked, with the campaign outcome Failed until the broken destination is fixed and rechecked.

Safety and limits

The raw message body and attachment bytes are processed transiently and never persisted. What a report keeps is deliberately small: subject, sender address, message id, timestamps, the extracted URLs with occurrence counts, and short snippets of visible link text so you can tell links apart. The canonical stored URLs are encrypted at the application level, and visible reports show redacted copies — data handling in full. Checking itself is bounded and request-safe, described in the security model.

Not included

No inbox connection — SendProofs never asks for mailbox access or credentials. The workflow is file-based: you save the delivered email and upload it.
No draft or pasted-HTML checking — a draft does not contain the rewritten links, so checking it would reopen exactly the gap this page describes.
No rendering — no screenshots and no client matrix. SendProofs reports on links, images and tracking, not on how the email looks.

Link checking

Every unique public link in the delivered email, requested once with bounded, safe HTTP checks and the resulting status recorded as evidence.

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.

Evidence reports

Timestamped, human-readable evidence for every checked resource, with a clear next action for each state — not an opaque score or a pass stamp.