If you’ve landed here, you’ve seen this in an Outlook message:

The linked image cannot be displayed. The file may have been moved, renamed, or deleted. Verify that the link points to the correct file and location.

You may also have seen the precursor: a red X where the image should be, with the text “Right-click here to download pictures. To help protect your privacy, Outlook prevented automatic download of this picture from the Internet.” Right-clicking and choosing Download Pictures is what produces the second error. (Both messages are catalogued in the Microsoft Office image error messages dictionary, which covers the broader family of related dialogs.)

Every guide online tells you the same thing: delete the BlockHTTPimages registry value. Sometimes that’s the answer. Often it isn’t. The first thing you need to know is that the most-cited fix simply doesn’t apply to most people who see this error, and forums are full of users who tried the registry edit, found the key doesn’t exist on their machine, and got no further. Here’s what’s actually happening and how to work through it properly.

The cause Microsoft documents

The official Microsoft KB on this error (KB 3096277) is narrow and specific. The error appears when:

  1. The image in the message is hosted at a URL (not embedded in the message itself), and
  2. Outlook is configured to block HTTP-hosted images via the BlockHTTPimages registry value.

When both conditions are true, Outlook shows the red-X placeholder. When you try to download manually, you get the “linked image cannot be displayed” message because the BlockHTTPimages setting is overriding your manual request.

The registry value lives at one of two locations:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Common

The DWORD is named BlockHTTPimages and the problem occurs when its value is 1.

The fix Microsoft documents: open Registry Editor, navigate to whichever location has the key, right-click BlockHTTPimages, delete it, restart Outlook.

If the key is at the Policies path, it’s been set by Group Policy. Deleting it manually will work until the next policy refresh, at which point it will reappear. If you’re on a managed corporate machine, you need to talk to whoever manages the policy — usually IT — to get the policy changed at the source.

When the key doesn’t exist

This is where Microsoft’s documentation runs out of road and where most users get stuck. Open both registry paths above. Neither has a BlockHTTPimages value. You restart Outlook anyway, just in case. The error persists. Now what?

What it means is that BlockHTTPimages is not your cause. The error message text is technically generic — it can be triggered by anything that prevents Outlook from successfully retrieving and rendering the linked image — and the BlockHTTPimages explanation is just the most-documented case, not the only case.

The actual cause when BlockHTTPimages isn’t set is almost always one of three things. Work through them in this order.

Cause 2: the encrypted-pages-to-disk setting

Outlook renders HTML email by handing the content to the Windows HTML rendering stack, which historically was Internet Explorer’s engine and is now MSHTML. That stack respects a setting buried in Internet Options called “Do not save encrypted pages to disk”.

When that setting is enabled, the rendering engine refuses to cache images served over HTTPS. Outlook can’t display them. The error you get is the one you’re looking at.

To check: open Control Panel → Internet Options (or run inetcpl.cpl) → Advanced tab → scroll to the Security section → look for “Do not save encrypted pages to disk”. Uncheck it, click Apply, restart Outlook.

If the checkbox is greyed out, the setting is being enforced by Group Policy via this registry value:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
DWORD: DisableCachingOfSSLPages
Value: 1

Or the policy version:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings
DWORD: DisableCachingOfSSLPages
Value: 1

Change the value to 0 (or delete it). If it’s at the Policies path, same caveat as above — Group Policy will re-apply it. Talk to IT.

This setting is the most commonly missed cause. It’s not in any of the top-ranked Bing or Google results for the error. Microsoft Support engineers in the Microsoft Q&A forums sometimes mention it as a follow-up after the BlockHTTPimages fix fails, but it never makes it into the main troubleshooting articles. If BlockHTTPimages didn’t exist on your machine, check this next.

Cause 3: antivirus or endpoint protection blocking image retrieval

Some endpoint protection products — Symantec, McAfee, certain Bitdefender configurations, occasionally Defender for Endpoint with specific attack-surface-reduction rules — interpose on Outlook’s image retrieval requests and block them. The mechanism varies. Some intercept the HTTP requests directly. Some block the temporary file write to the Outlook secure temp folder. Some inject scripts that interfere with the rendering pipeline.

To test: temporarily disable your endpoint protection (with appropriate authorisation if you’re on a managed machine) and try to display the same image. If it works with protection disabled and fails with it enabled, you’ve found the cause.

The fix isn’t to leave protection disabled. It’s to add an exclusion for Outlook’s process, or for the secure temp folder it uses to cache images, or for the specific scanning behaviour that’s interfering. The vendor’s support documentation will have specifics. Don’t just turn it off and forget.

Cause 4: the secure temp folder is full or inaccessible

Outlook caches images it downloads into a folder called the Outlook Secure Temporary Files folder. The location is a hashed subdirectory under your local AppData. If that folder is full, missing, or unwritable, Outlook can’t cache the image and rendering fails.

The folder location is stored in this registry value:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Security
String: OutlookSecureTempFolder

Open the path stored there in File Explorer. If it has hundreds of files, you can safely delete them all — Outlook will recreate the folder contents as needed. If the path doesn’t exist on disk, that’s the cause; you can either create the folder manually at the stored path, or delete the registry value and let Outlook regenerate a fresh location on next launch.

What I’d skip

A few fixes are commonly suggested for this error and waste time:

Repairing Office. Won’t fix BlockHTTPimages, won’t fix DisableCachingOfSSLPages, won’t fix antivirus interference. It only helps if Office itself is corrupted, which is rarely the cause of this specific error.

Reinstalling Office. Same reasoning. Sledgehammer for a screwdriver problem.

Switching to web Outlook permanently. This is the “well, it works in OWA” workaround that gets recommended on forums when the troubleshooter gives up. It’s not a fix. It just means you’re not using Outlook anymore. (If your specific concern is that Exchange-account messages are affected, the Outlook Classic Exchange inline images guide covers the additional Exchange-side checks worth running.)

Adding senders to the Safe Senders list. This affects whether Outlook automatically downloads pictures, not whether it can successfully render them when you ask it to. If the underlying retrieval is broken, Safe Senders won’t help.

If you’re the sender and recipients see this error

A quick note for the other side of the conversation. If you’re the one sending messages with linked images — most commonly through an email signature platform that hosts the logo on its server and references it via URL — and your recipients are reporting this error, the fix isn’t on your end. The error is happening in their Outlook configuration, for one of the reasons above. (This is also the failure mode that drives the bulk of the Outlook signature images appearing as attachments traffic — same root cause, different symptom.)

What you can do helpfully: switch your signature to use embedded images rather than linked ones, at least for the recipients who are reporting issues. This bypasses the entire BlockHTTPimages / cache-blocking / antivirus-interception problem because the image data travels with the message rather than being fetched on display. The trade-off is larger messages and slightly more friction in updating the signature centrally, but it produces images that render reliably across the broadest set of recipient configurations. Most enterprise signature platforms support both modes; check yours for an embed-images toggle.

The order to actually work through it

Skip the BlockHTTPimages registry path first. Instead:

  1. Open File → Options → Trust Center → Trust Center Settings → Automatic Download. Make sure “Don’t download pictures automatically in standard HTML email messages or RSS items” is the only check, and that you haven’t accidentally enabled the more aggressive options. If you’ve previously experimented here, reset to default.
  2. Then check the DisableCachingOfSSLPages registry value. This is the unsung cause that nothing online mentions.
  3. Then check the BlockHTTPimages registry value at both the user and policy paths.
  4. Then check antivirus interference.
  5. Then check the secure temp folder.

Working through it in that order will resolve the error for the great majority of cases. The reason most guides put BlockHTTPimages first is because it’s the only cause Microsoft formally documents — not because it’s the most common cause in 2026. The bigger picture: this error is one of a small family of generic-text Outlook messages that get pointed at one specific cause in the documentation and a dozen other causes in practice. Knowing the family, not just the textbook fix, is what gets you through it.