Every remote image accounted for before your recipients load it

Every remote img[src] URL in the HTML part of your delivered test email — the image URLs recipients' email clients will request, after your sending platform rehosted or rewrote them. Only http and https URLs qualify; each is normalized and deduplicated, so an image referenced five times is checked once, however many times it appears in the email.

Classification comes first. Image URLs with open, pixel or beacon path segments are treated as likely tracking pixels: they are marked Protected and never requested — a pre-send check should not register as an open.

Eligible images then receive the same bounded check as links:

• a HEAD-first request with a bounded GET fallback, identified as SendProofs/0.1, redirects followed up to 3 hops with every hop recorded;
• a content-type sanity check — a destination that answers 2xx with a content type outside image/* is reachable but flagged Warning, because a URL that returns an HTML error page instead of image bytes is not the image you meant to send;
• response bodies read up to 64 KB and then truncated, with the truncation recorded as a warning on the resource.

Pixel detection is pattern-based, on open, pixel and beacon path segments. That catches the common shapes, but it is not a guarantee that every tracking pixel is recognized — a pixel served from an unusual path can be classified as an ordinary image and checked once. The check itself stays narrow either way: HEAD-first, standard ports only, 2 s connect, 5 s read and 10 s total budgets per resource, no retries, and at most 64 KB of any response body read. A Healthy image is evidence that the URL resolved to image content at check time — not a claim about how the image looks or how quickly it loads for a recipient.