Most of the advice circulating online about Outlook images was written by people using IMAP accounts and assumes the rest of the world is too. Exchange isn’t IMAP. The image takes a different path through the server, gets handled by different code, and breaks for different reasons. If you’ve spent an afternoon working through the standard fix list — switch to HTML, clear the cache, disable add-ins, reinstall Office — and the image is still arriving as winmail.dat or showing up as an attachment to half your recipients, that’s because none of the standard advice is actually about Exchange.

This is the Exchange-specific version. The fixes here address what your mail server is doing to the image, not what your client is doing to the file.

How Exchange actually moves an inline image

Outlook Classic doesn’t send your message as straightforward MIME the way Thunderbird or Apple Mail would. When you paste a screenshot into a message body and click send to another Exchange mailbox, the message moves between Exchange servers in a format Microsoft calls S/TNEF — Summary Transport Neutral Encapsulation Format — which is a binary encoding of the MAPI properties your client built. Exchange uses this format for internal transport between servers because it preserves the full set of properties, including how the image was attached, where it sits in the body, and whether it’s inline or a true attachment.

That’s fine inside your organisation. The problem starts at the boundary. Exchange never sends S/TNEF to external recipients, so the last hub before the message leaves your tenant has to convert it. By default that conversion produces MIME with HTML and an inline image referenced by Content-ID. By exception — and the exceptions are where every problem lives — the conversion produces a TNEF-wrapped message with a winmail.dat attachment that only Outlook can read.

The single fact every Exchange admin should have tattooed somewhere visible is this: selecting RTF as the format for sending an email implicitly enables TNEF encoding instead of MIME. Rich Text Format is not a formatting choice. It’s a transport choice. And on Exchange, it’s almost always the wrong one for messages leaving the organisation.

The May 2026 OWA inline image problem (still relevant as of writing)

If you arrived here in the last two weeks because inline images suddenly broke for OWA users on Exchange Server 2019 or 2016, you’re hitting a known issue. On May 14, 2026, Microsoft disclosed CVE-2026-42897, a cross-site scripting vulnerability in Exchange OWA, and automatically deployed mitigation M2.1 through the Exchange Emergency Mitigation Service (EEMS), which adds a URL Rewrite rule to the OWA frontend web.config. The mitigation, by tightening Content Security Policy on OWA, prevents OWA from rendering inline images that arrive inside TNEF containers — which is exactly what Outlook desktop produces when you paste a screenshot into a message.

The diagnostic signature: the image shows fine in Outlook Classic on the desktop, but the same recipient opening the same message in OWA sees either a blank space or a Download link. Message headers show Content-Type: application/ms-tnef; name="winmail.dat".

This is a server-side problem caused by a security mitigation. The “fix” on the client side is to stop producing TNEF-wrapped messages in the first place, which is the same fix Exchange admins should have implemented years ago anyway. Everything in the rest of this article applies — the urgency is just higher right now because OWA is the canary.

There’s also a separate, unrelated Outlook desktop bug in classic Outlook build 19929.20164 and later that affects inline images independent of OWA. If you’ve already fixed the TNEF issue and images still misbehave in the desktop client specifically, that’s the other problem.

Why Exchange accounts have their own image problems

Three things go wrong on Exchange accounts that don’t go wrong on IMAP or POP. Understanding which one you’re hitting is most of the work.

Rich Text Format is the silent killer

The Outlook setting for message format is in File → Options → Mail → Compose messages in this format. If it’s set to Rich Text, every inline image you send to an external recipient gets wrapped in TNEF and the recipient sees winmail.dat. Even if the option is set to HTML globally, individual contacts in your address book can override it: open a contact, look at the email properties, and check whether the format is set to “Send using Outlook Rich Text format.” If it is, every message to that one person produces winmail.dat — regardless of your global setting.

This is the cause of roughly half of the “image appears as attachment” reports I’ve seen from Exchange users. It’s also almost never mentioned in the forum threads, because the people writing those threads aren’t on Exchange.

Transport rules quietly rewrite messages

Exchange admins have broad latitude to modify messages in transit. Transport rules can block specific attachment types, modify content, redirect messages, and apply rights protection. A transport rule that strips attachments above a certain size, or rejects HTML email from external senders, or applies attachment scanning, can interfere with inline images even though no human wrote a rule “remove inline images.” Inline images are technically attachments — they’re MIME parts referenced by the HTML body via Content-ID. A rule that treats them like attachments gets in the way.

If you administer the tenant, audit the transport rules. If you don’t, ask whoever does.

On-prem Exchange and Exchange Online aren’t identical

The two environments have the same documentation but different defaults and different patch cadence. Exchange Online tends to apply mitigations like the May 2026 one automatically through service updates; on-prem servers receive them through EEMS but admins can disable EEMS or unpick specific mitigations. Hybrid environments — where mailboxes move between on-prem and Online — produce a third class of problem, where the conversion happens at the hybrid boundary and the message arrives in a different format than the sender intended.

If you have one mailbox on Exchange Online and one on-prem inside the same hybrid, and inline images work for one but not the other, that’s the boundary doing it.

The fixes, in diagnostic order

Don’t try fixes in the order they show up on Google. Try them in the order that matches what Exchange is actually doing to your message.

1. Force the message format

This is the single highest-yield fix on Exchange accounts. Open Outlook Options, set the compose format to HTML, then individually check any contact whose messages have been arriving as winmail.dat — there’s a real chance the address book entry has RTF locked in at the contact level. While you’re in Options, go to Mail → Message format and confirm that under “Internet format,” the option “When sending Outlook Rich Text messages to Internet recipients, use this format” is set to either “Convert to HTML format” or “Convert to Plain Text format” — not “Send using Outlook Rich Text format.”

That last setting is the global escape hatch. If your organisation has it set to “Send using Outlook Rich Text format,” every external Exchange-formatted message produces TNEF, regardless of what individual users do.

2. Check the per-message format on send

Before you send a problem message, look at the Format Text ribbon. If “Rich Text” is highlighted instead of HTML, the message will be sent as RTF and the inline image is going into winmail.dat. Click HTML.

This is the fix when sporadic messages produce winmail.dat and the rest are fine — a single message got switched to RTF, often because the user replied to a message that was originally RTF, and Outlook helpfully matched the format.

3. Audit organisational TNEF settings (admin)

In Exchange admin centre, TNEF conversion options can be set at the remote domain level, at the user level via mail user/contact configuration, or at the organisation level, with the higher-level setting overriding lower-level ones. The default is that TNEF messages are converted to HTML for external recipients, which is what you want. If someone has changed it — either deliberately or by following bad advice — set it back.

Check Get-RemoteDomain | Format-List Identity,TNEFEnabled in Exchange Online PowerShell. The TNEFEnabled property should be $null (which means “convert to HTML, the default”) or $false. If it’s $true for a domain you send to externally, that domain is receiving TNEF and inline images are at risk.

4. Audit transport rules

Open Exchange admin centre, navigate to Mail flow → Rules, and look for any rule that touches attachments, modifies messages, or applies content scanning. Look specifically for: rules with conditions on “any attachment” properties, rules that strip MIME parts, rules that re-encode messages, rules that apply rights management. Disable rules one at a time and re-test. If the problem disappears, you’ve found it.

This is also where third-party email security products live. Mimecast, Proofpoint, Barracuda — all of them sit in front of Exchange and can modify messages in ways that affect inline images.

5. Check the Send Pictures With Document registry setting

Outlook respects a registry value at HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Common\MailSettings\Send Pictures With Document which, if set to 0, instructs Outlook to send links to images rather than the images themselves. This is rare but not unheard of in locked-down corporate environments. Set it to 1 or delete the value.

I’ve put this fifth, not first, because the forum advice that promotes it as the universal fix is misleading on Exchange accounts. It does exist, it does break inline images when misconfigured, and it’s worth checking — but on Exchange, the TNEF problem is overwhelmingly more common.

What you’ll find on forums that won’t help

The Outlook image fix lists on Spiceworks and Reddit are written largely for IMAP and Outlook.com users. Several of the recommendations are actively wrong for Exchange:

  • “Switch to Plain Text and back to HTML.” This does nothing for the TNEF/RTF distinction. The format selector and the transport encoding are different mechanisms.
  • “Repair Office / reinstall Outlook.” If the message is arriving as winmail.dat at the recipient, the problem is on the server side or in the message-level format, not in your client installation.
  • “Disable hardware acceleration.” Hardware acceleration affects rendering, not transport. It’s irrelevant to whether the recipient sees the image.
  • “Clear the Outlook cache (OST).” Only relevant if Outlook is displaying corrupted images to you locally. Has no effect on what recipients see.
  • “Check your antivirus.” Plausibly relevant if you have an aggressive endpoint product that scans outgoing mail, but unlikely on a managed corporate machine, and even then the fix is at the antivirus level, not in Outlook.

If you’ve been working through that list for an hour and nothing’s working, that’s not a coincidence. The list isn’t wrong for everyone — it’s wrong for Exchange.

When this isn’t really an Exchange issue at all

There are three patterns that look like Exchange image problems but aren’t:

Signature images specifically. If only the signature logo is breaking but body images work, that’s a different problem with its own causes — typically the signature image being stored on disk in a way Outlook can’t embed reliably, or the signature being constructed in an editor that doesn’t produce embeddable CID references.

The linked-image error message. If recipients see “The linked image cannot be displayed” rather than the image arriving as an attachment, that’s the BlockHTTPimages registry behaviour or a remote image policy, not a TNEF problem.

New Outlook for Windows. If you’ve moved to New Outlook, the image-handling architecture is entirely different — closer to the OWA codebase than to Outlook Classic. The fixes here don’t apply. The New Outlook differences are covered separately.

Diagnostic flow

When an Exchange user reports that inline images are arriving as attachments, work through it in this order:

  1. Look at a sample message header. If it says application/ms-tnef, the problem is RTF/TNEF and the fix is in section 1, 2, or 3 above. If it says multipart/related with proper MIME parts and Content-ID references, the problem isn’t TNEF and the rest of this article doesn’t apply to you — move to transport rules or third-party mail security.
  2. Check the sender’s compose format and the contact-level format override. Most cases end here.
  3. Check organisation-level TNEF settings. Get-RemoteDomain in PowerShell.
  4. Check transport rules. Disable suspects one at a time.
  5. Only then start looking at the client. Registry settings, Office repair, the works.

If you’re hitting the May 2026 OWA-specific regression, the answer is the same: stop producing TNEF. The CSP-tightening mitigation isn’t going away, and even after the permanent patch ships, TNEF-wrapped inline images are a fragility you don’t need to keep in your mail flow.

The Exchange image problem is solvable. It just isn’t solvable with the IMAP playbook.