A personalized image is a URL that your recipient's email client fetches. Which sounds simple, until you learn that no two clients fetch it the same way.
One proxies the request through its own servers and caches the result. Another fetches it before the recipient has even seen the email. A third refuses to fetch it at all until the reader clicks something. Each of those behaviours changes what your recipient sees, what you can measure, and how quickly a change reaches them.
This is what actually happens, client by client, and what to do about it.
The three behaviours that matter
Before the specifics, the patterns:
Proxying. The client fetches the image through its own infrastructure rather than letting your server see the recipient. Protects the recipient's IP address and gives the provider a caching layer.
Caching. The image is stored somewhere between you and the reader. Means a second view may never reach your server, and an updated image may take time to propagate.
Prefetching. The image is fetched before, or independently of, the recipient opening the message. Breaks the assumption that a request means a person looked at something.
Blocking. The image is not fetched at all until the reader explicitly allows it.
Almost every complication below is one of those four.
Gmail
Proxies and caches. Gmail routes image requests through Google's own servers rather than fetching directly from yours, and caches the result on Google's infrastructure.
Images display by default, which is the good news - your personalized image will be seen by most Gmail recipients without them doing anything.
What it means in practice:
- You do not see the recipient's IP address or device; you see Google's proxy.
- A second open by the same person may be served entirely from Google's cache, so your server never hears about it.
- An updated image may take time to reach Gmail readers, because Google is serving what it already has. Cache headers influence this but Google applies its own judgement.
Practical implication: Gmail is the easiest client to get right and the hardest to reason about for measurement.
Apple Mail
Prefetches, then caches. This is the one that surprises people. With Mail Privacy Protection active, Apple fetches the images in an email when it is delivered, through Apple's proxy, whether or not a human ever opens it. That can happen hours after delivery, with the device idle on Wi-Fi.
What it means in practice:
- Your image is generated and served for recipients who never read the email.
- The genuine open, when it happens, is served from Apple's cache and never reaches your server.
- So for Apple Mail recipients you are effectively measuring delivery, not opens. Any metric built on image loads reads high.
- An update to the design may not reach someone whose copy Apple already cached.
Practical implication: Apple Mail is where image-based metrics break down, and where "the image updates when they reopen" is least reliable. Neither is fixable at your end - it is how MPP is designed.
Outlook
Blocks external images by default on the desktop clients, which remains the most consequential single behaviour in email. The recipient sees your alt text and a prompt until they choose to download images.
Microsoft has been transitioning classic Outlook to "new Outlook", and in the newer client the control is less about whether images load and more about whether they route through Microsoft's proxy service. Behaviour differs between versions, and both are in the wild.
What it means in practice:
- A meaningful share of Outlook recipients will never see your image at all.
- Alt text is not a nicety - for those readers, it is the entire message.
- Where images do load, they may pass through Microsoft's proxy, adding another caching layer.
Practical implication: if your email only works when the image loads, it does not work in Outlook. This is the client to design defensively for.
What this means for how you build
Five things follow directly.
1. Alt text carries the message. Write it as though it is the only thing some readers will see, because for a proportion of your Outlook audience it is. Put the personalization in it too - alt="A message for {{ first_name }}" rather than alt="banner".
2. Never put essential information only in the image. A discount code, a date, a call to action - if it exists only as pixels, some readers get nothing. Put it in text as well.
3. Set an explicit width. Clients that block images reserve space based on the attributes you give them. Without a width, blocked images collapse the layout.
4. Do not treat image loads as opens. They include Apple prefetches that no human saw, and they exclude Gmail readers served from cache. The number is a blend of things, not a measurement of attention.
5. Expect updates to propagate unevenly. If you change a design after sending, cache headers give you some control, but Gmail and Apple both cache on their own terms. Assume "most recipients, eventually" rather than "everyone, immediately".
The testing checklist
Before any significant send, check the render in:
- Gmail on desktop and mobile - the largest audience, easiest case
- Outlook desktop with images blocked - the failure case that matters most
- Apple Mail on iPhone - the largest mobile audience
- One webmail client your audience actually uses
And check specifically:
- Does the email still make sense with images off?
- Is the personalization visible in the alt text?
- Does the layout hold when the image does not load?
- Is the image legible at phone size?
That is twenty minutes and it catches nearly everything.
What no tool can fix
Worth being straight about, because vendors in this category are often vague on it.
No image generation service can stop Outlook blocking images, make Apple's prefetches distinguishable from real opens at the recipient's end, or force Gmail to bypass its cache. These are decisions made by the mail clients, and every provider is subject to them equally.
What a tool can do is render reliably and quickly, serve standard formats over standard HTTP, and set sensible cache headers. Anything promising more than that - guaranteed rendering everywhere, accurate open tracking, instant updates for all recipients - is claiming control it does not have.
Frequently asked questions
Do personalized images render correctly in Gmail, Outlook and Apple Mail? They render wherever ordinary images render, because they are ordinary images served over HTTP. The differences are in how each client fetches them - Gmail proxies and caches, Apple prefetches at delivery, Outlook desktop blocks by default until the reader allows them.
Why do my images not show in Outlook? Outlook desktop blocks external images by default as a privacy measure. The recipient sees alt text and a prompt to download. This affects all remote images, not just personalized ones.
Does Gmail cache my images? Yes. Gmail fetches through Google's proxy and caches the result, so repeat views may never reach your server and updates can take time to appear.
What is Apple Mail Privacy Protection doing to my images? Fetching them when the email is delivered, through Apple's proxy, whether or not anyone opens it - then serving the cached copy when the person does open. The consequence is that image loads overstate real opens for Apple recipients.
Can I tell whether a real person saw my image? Not reliably. An Apple prefetch looks identical to a human open from the server's perspective. Clicks are the more trustworthy signal, since they require a person.
How do I make sure my email works when images are blocked? Write meaningful alt text including the personalization, keep essential information in text as well as the image, and set an explicit width so the layout holds. Then test in Outlook with images off.
If I update the image after sending, who sees the change? Recipients whose client requests it again. Cache headers control how long copies stay valid, but Gmail and Apple apply their own caching on top, so expect gradual rather than instant propagation - and Apple Mail recipients may not see it at all if their copy was already cached.
Which client should I test first? Outlook with images blocked. If the email works there, it works everywhere.
Design for the hardest case
The practical takeaway is that the client you should build for is not the one most of your audience uses - it is the one that shows the least. Get the email working with images blocked and meaningful alt text, and every other client is an improvement on that baseline.
OKZest serves standard image formats over standard HTTP with explicit cache headers, so images behave predictably wherever remote images are allowed. What each client does with them after that is, as ever, up to the client.
Create a free account, no credit card required.
Sources
- The Ultimate Guide to Email Image Blocking - Litmus
- New Outlook's blocked images problem - Office Watch
- Block external images from automatically being loaded - Microsoft
- Apple Mail Privacy Protection FAQs - Mailchimp
Related reading: personalized images and open rates, updating images after sending, put every recipient's name inside your email image.