Product

What happens when you upload a delivered test email

SendProofs inspects the message that actually reached your inbox — after your sending platform rewrote the links and added tracking — and turns it into evidence a human can approve against. Here is the whole system, end to end, including what it will not do.

1. The delivered email is the artifact

The email your recipients get is not the template you designed. Sending platforms rewrite every link through their click-tracking domains, append tracking parameters and rehost images. SendProofs therefore inspects the received test email — the .eml file you save from your own inbox — because that is the artifact that carries the final links in a form you can hand to a checker. More on delivered-email checks.

2. Accepted input and hard limits

One .eml filethe saved test email, uploaded from your machine
2 MB maximumlarger messages are rejected with an explicit error
100 MIME partsdeeply nested or oversized structures are refused
500 unique resourcesper email, deduplicated before counting

Limits are enforced before anything is stored or requested — an email over a limit produces an error, not a partial run.

3. Extraction and deduplication

From the HTML part, SendProofs collects 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, so a link that appears five times is checked once and reported with its occurrence count.

4. Protected destinations are classified before any request

Before a single request leaves SendProofs, every URL is classified. Links recognized as action-bearing by URL and anchor-text patterns — unsubscribe and preference-center links, sign-in and password-reset links, verification, invitation and order/purchase actions — are marked Protected and are never requested. Likely tracking pixels are treated the same way. Protected items still appear in the report, marked “Not opened”, so you can review them by hand. How protected actions work.

5. Bounded public checks

Eligible public destinations receive a bounded HTTP request identified by the SendProofs/0.1 user agent: private and internal network addresses are blocked, redirects are followed up to 3 hops with every hop recorded, and each resource gets strict connect, read and total-time budgets. There is no browser, no JavaScript, no cookies and no retries. Full security model.

6. Deterministic tracking checks

For links, UTM review runs on the final URL after HTTP redirects — missing required keys, duplicates, blank values and non-canonical casing are each recorded as named issues on the resource. Campaign tracking review.

7. Evidence states and next actions

Healthy
Destination answered 2xx with no warnings. No action.
Warning
Reachable, but something needs a human decision — a tracking issue, an HTTPS downgrade, an unexpected content type. Review before approval.
Broken
Failed a deterministic check — an error status, timeout or dead redirect. Fix in your sending platform, send a fresh test, recheck.
Protected
Recognized as action-bearing and not opened. Review manually.
Blocked
Stopped by network safety policy (for example a private address). Review manually.
Inconclusive
The destination limited automated access (401/403/429). Neither a pass nor a failure — review manually.

When a run completes, the campaign outcome rolls up honestly: any Broken resource marks the campaign Failed; Blocked or Inconclusive items make it Incomplete — manual review required; interrupted runs are always Incomplete, never a silent pass. How to read a report.

8. What a report looks like

Sample data August launch — final test · 24 unique resources · 18 links, 6 images
ResourceStateEvidence
campaign.example/launch?utm_source=email&utm_campaign=aug-launch Healthy 200 after 2 redirects · 312 ms · 14:02 UTC
campaign.example/pricing/summer-2026 Broken 404 at final destination — fix in your sending platform, then recheck
campaign.example/blog/whats-new?utm_source=email Warning 200, but the workspace's required utm_campaign is missing on the final URL
example.com/unsubscribe/%5BREDACTED%5D Protected Not opened — action-bearing link, review manually
img.campaign.example/hero-aug.png Healthy 200 · image/png · 96 ms
partner.example/offer Inconclusive 403 — destination limited automated access, review manually

Sample data. Full sample run: 15 Healthy, 2 Warning, 1 Broken, 3 Protected, 2 Inconclusive, 1 Blocked — campaign outcome Failed until the broken destination is fixed and rechecked. 20 of the 24 resources consumed a check; the 3 Protected items and 1 Blocked item were never requested.

9. Data lifecycle

Raw message body and attachment bytes are processed transiently and never persisted. What the report keeps: subject, sender, timestamps, the extracted URLs (stored encrypted, shown redacted) and short link-text snippets. Visible reports replace token-like values with [REDACTED]. Data handling in full.

What SendProofs explicitly does not test

  • Deliverability, inbox placement or spam filtering — no prediction of where the email lands.
  • Visual rendering across email clients — no screenshots, no client matrix.
  • Whether recipient mailboxes exist, or anything about your sender reputation — SendProofs does not measure either.
  • Destinations behind sign-ins or bot protection — those are reported Protected or Inconclusive, not guessed at.
  • Fixing anything automatically — SendProofs reports evidence; you fix the campaign in the platform where you built it.

Capabilities in depth

Check your next campaign before you approve it

Free workspace — 100 resource checks each month, no card at signup.

Create workspace