Task

Confirm every remote image answers before the send goes out

Upload the delivered test email and each remote image URL that is not a likely tracking pixel gets one bounded check: does the URL answer, and does it answer with an image? Broken image URLs come back with the failing code, a URL that serves something other than an image is flagged for review, and likely tracking pixels are identified and never requested.

How it works

  1. Save and upload the delivered test

    Most sending platforms rehost images or rewrite URLs when the campaign goes out; the .eml saved from your inbox holds the image URLs recipients' mail clients will actually request.

  2. Remote images are extracted

    Every img[src] in the HTML part with an http or https URL, normalized and deduplicated — an image used five times is checked once, however many times it appears in the email.

  3. Likely tracking pixels are set aside

    Image URLs with open, pixel or beacon path segments are treated as Protected and never requested. They stay in the report, marked "Not opened".

  4. Each image URL gets one bounded check

    HEAD-first with a bounded GET fallback, identified as SendProofs/0.1, private networks blocked, redirects followed up to 3 hops, strict timeouts, no retries.

  5. The answer is inspected

    A 2xx with an image content type and nothing else flagged is Healthy. A URL that answers with a content type that is not an image — an HTML error page behind a 200, for instance — is flagged Warning so you look before send.

  6. Fix, fresh test, recheck

    A broken image URL is fixed where the campaign lives — your sending platform or your image host — then confirmed in a freshly delivered test, because the fix has to survive the rewrite.

What the states mean here

Healthy
The image URL answered 2xx with an image content type and nothing else flagged.
Warning
The URL answered, but with a content type that is not an image, or with something else flagged on the response. Look at it before approval.
Broken
The image URL failed — an error status such as 404, a timeout, a connection or TLS failure, or a dead redirect. The code is recorded; fix and recheck a fresh test.
Protected
A likely tracking pixel, recognized by open, pixel or beacon path segments and never requested. Marked "Not opened" in the report.
Inconclusive
The host answered 401, 403 or 429 — it limited automated access. Neither a pass nor a failure; review it manually.
Blocked
The image URL resolved to a private or internal address, so it was not requested by policy. Review it manually.
Sample data Image evidence from the August launch sample run
ResourceStateEvidence
img.campaign.example/hero-aug.png Healthy 200 · image/png · 96 ms
img.campaign.example/products/grid Warning 200, but content-type is text/html — not an image
img.campaign.example/open/%5BREDACTED%5D.gif Protected Not opened — review manually

Sample data. The full sample run counts 6 images among its 24 unique resources — this fragment shows three of them. The tracking pixel was classified Protected at upload and consumed none of the run's 20 checks. Pixel recognition is pattern-based; an unrecognized tracker is checked like an ordinary image, under the same bounded request rules.

What still needs a human

SendProofs verifies that an image URL answers, and with what content type — it does not see how the image looks. A Healthy image state does not mean the creative is the right one, the current one, or cropped the way you intended; it means the URL answered with an image at check time.

There are no screenshots and no rendering across email clients, so an automated 200 alone does not prove the campaign is correct. Open the delivered test in your own client and look at the hero, the product shots and the alt text — then approve with both the report and your eyes on record.

See which images answer before the send

Upload the delivered test — every remote image is part of the report.

Create workspace