How do email clients render external images?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
When an email includes an external image (any image hosted on a server, not embedded in the email itself), the email client has to make a separate HTTP request to fetch that image. Here's how it actually works.
First, the client reads the email's HTML and finds an <img> tag with a src attribute pointing to an external URL. That URL might be on your own domain (https://yourbrand.com/images/header.jpg) or hosted on your ESP's CDN (https://cdn.mailchimp.com/...).
Default behavior varies wildly by client:
- Gmail loads images by default for all senders, but routes every request through Google's image proxy. The proxy downloads the image, caches it on Google's servers, and serves it from there. This hides the recipient's IP address and breaks some tracking pixels.
- Outlook (both the web app and desktop versions) blocks images by default unless you're in the recipient's contacts or Safe Senders list. When images are allowed, Outlook also uses a proxy.
- Yahoo Mail uses a proxy similar to Gmail's. Images load by default, but Yahoo rewrites the URLs.
- Apple Mail on macOS and iOS loads images by default without a proxy (direct HTTP request from the recipient's device).
- Corporate clients (Microsoft 365, Google Workspace with custom policies) can block images entirely at the admin level.
When images are allowed, here's the actual flow: the client makes an HTTP GET request to the image URL. If the URL is HTTPS (which it should be), the connection is encrypted. The server responds with the image file. The client then renders the image inside the email layout, applying any width/height attributes or CSS styles you specified in the HTML.
Caching: Most clients cache images after the first load. If the recipient opens the same email twice, or if multiple emails use the same image URL, the client serves the cached version instead of fetching it again. Proxies (Gmail, Yahoo, Outlook) also cache aggressively on their own servers, which means your image might be served from Google's CDN for weeks after you sent the email.
What clients do differently: Some compress images to save bandwidth (especially on mobile). Some strip or rewrite query parameters on image URLs (this breaks naive tracking pixels that rely on unique query strings). Outlook desktop versions have historically had issues with large images or specific image formats (WebP support is still inconsistent). Dark mode can invert image colors if you don't use transparent PNGs or explicitly test for it.
Why this matters for senders: if you're using a tracking pixel to measure opens, proxy caching and image blocking will both cause undercounting. If you're hosting images on your own server, check your server logs. You'll see requests from proxy IPs (Google, Yahoo, Microsoft) instead of individual recipient IPs. And if your images don't load because you're using HTTP instead of HTTPS, or because your CDN is slow, the email looks broken even if everything else is perfect.
Testing tip: send yourself a test email and open it in multiple clients (Gmail web, Outlook desktop, Apple Mail, your phone). Right-click an image and inspect the URL. If it's been rewritten to pass through a proxy (googleusercontent.com, for example), you're seeing proxy behavior. If it's the original URL, the client is loading directly.
For a deeper look at how proxies change image loading behavior, check our answer on image proxies.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.