Almost every troubleshooting guide for “Outlook inline image showing as attachment” was written for Exchange or Microsoft 365 accounts. If you’re on IMAP or POP — Gmail via IMAP, a custom domain through a hosting provider, a Yahoo account, a small-business mailbox on cPanel — most of that advice is irrelevant at best and actively misleading at worst. The behaviour is different because the architecture is different, and applying Exchange fixes to an IMAP problem is why you’ve spent two hours not getting anywhere.

Here’s what’s actually going on, and what to do about it.

Why IMAP and POP behave differently

When you send a message from an Exchange or Microsoft 365 account, the message goes through a server-side transport pipeline. That pipeline can apply transport rules, rewrite headers, convert formats, and inspect content before delivery. If something goes wrong with inline images on Exchange, there’s a reasonable chance the cause is server-side — a transport rule stripping HTML, an EOP policy, or a connector misconfiguration. (We cover the Exchange-specific causes in the Outlook Classic Exchange inline images guide.)

IMAP and POP have no equivalent. The mail server stores and forwards. It doesn’t reformat. Everything that determines how your image is encoded and delivered happens on your machine, inside the Outlook client, before the SMTP handoff. That means every fix has to be a client-side fix, and the diagnostic flow is completely different.

This also means IMAP/POP image problems are almost always reproducible. Send the test, look at the result, change one setting, send again. There’s no caching layer, no transport rule cache, no propagation delay to wait through. If a fix is going to work, it works on the next send.

The format trap nobody mentions first

Before touching the registry, check your message format. With an IMAP or POP account, the single most common cause of “my inline image arrived as a weird attachment called winmail.dat” is that Outlook is sending in Rich Text Format.

Rich Text Format is a proprietary Microsoft format. When you send RTF to a non-Outlook recipient — and that includes most webmail, Apple Mail, Thunderbird, any phone client, every spam filter — the message gets wrapped as a TNEF envelope. The body and any inline images end up inside an attachment called winmail.dat that the recipient’s mail client cannot open. From their perspective, your beautifully formatted email with embedded logo arrived as a blank message and a mystery attachment. From your Sent Items perspective, everything looks fine.

The fix takes thirty seconds. In Outlook Classic, go to File → Options → Mail. Under “Compose messages”, set “Compose messages in this format” to HTML. Below that, find “When sending messages in Rich Text format to Internet recipients” and set it to “Convert to HTML Format”. Both settings need to be right; the second one is the safety net for any draft that somehow ended up in RTF.

This single change resolves more IMAP inline-image complaints than anything in the registry. Do it first, send a test, and only proceed if the problem persists.

The Send Pictures With Document registry key

If HTML format is set and images still arrive as attachments — or worse, arrive as broken image placeholders, red Xs, or the recipient gets the inline image PLUS an attached copy — the next stop is the registry. (If the recipient sees red Xs specifically with the text “linked image cannot be displayed”, that’s a related but distinct problem covered in the linked image cannot be displayed fix.)

The key is HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\Mail, with a DWORD value called Send Pictures With Document.

For most IMAP/POP setups, the value you want is 1. Setting it to 1 tells Outlook to embed the picture data directly inside the message as a CID-referenced attachment, which is the standard MIME approach. The image arrives inline, the recipient’s mail client renders it inline, and no separate attachment shows in the attachment row.

Setting it to 0 is for a specific advanced case: you want Outlook to send the image as an <img src> HTML link to an externally hosted version of the picture, with no image data embedded in the message at all. This is what enterprise signature platforms do for bandwidth reasons, and it requires the image to be publicly accessible at a stable URL. Don’t set this to 0 unless you know that’s what you want; on a standard IMAP setup it will produce broken image references for every recipient.

A few important notes on this registry key:

  • The version number in the path is 16.0 for Outlook 2016, 2019, 2021, LTSC 2024, and all current Microsoft 365 builds. There is no 17.0. Microsoft has been on 16.0 since 2016.
  • If the Mail subkey doesn’t exist under Options, you create it (right-click Options → New → Key → name it Mail). Then create the DWORD inside.
  • Recent Microsoft 365 builds — roughly Version 2503 (build 16.0.18623) onwards — appear to ignore this registry value entirely. Outlook embeds images correctly regardless of the setting. If you’re on a current 365 build and the registry tweak doesn’t change anything, that’s why. The setting still matters for Outlook 2016, 2019, 2021, and earlier 365 builds, which is most enterprise installations even today.

Close Outlook fully before editing the registry. Reopen, compose a test message, and send. You should see the difference immediately.

The Gmail-via-IMAP case

Gmail accounts configured in Outlook as IMAP have their own quirks worth calling out. The image-handling itself works the same as any other IMAP account once the format and registry are right, but Gmail does two things on the server side that cause confusion:

First, Gmail’s web interface renders inline images differently depending on whether the image was sent as a CID-referenced attachment or as an externally hosted link. If you’re checking your own sent message by opening it in Gmail’s web interface, you may see the image displayed differently than the recipient will see it in their own client. Always test by sending to an external recipient on a different platform, not to yourself.

Second, Gmail aggressively rewrites the Content-Disposition headers on inbound messages. An image marked as inline; filename="logo.png" may be rewritten in ways that affect how some clients display it. This isn’t something you can fix from your end. It’s a known characteristic of Gmail and it’s why a message that looks perfect in Outlook-to-Outlook can look slightly different when Gmail is in the middle.

If your specific complaint is “images look fine to me but broken to Gmail recipients”, the answer is usually that your images are hosted on URLs that Gmail’s image proxy can’t reach reliably, or that you’re sending in a way that produces extremely large embedded images that hit Gmail’s display thresholds. Switch to standard embedded images at sensible resolutions (logos at 200×60 pixels max, not 2000×600) and the problem typically resolves.

The Trust Center settings that affect outgoing images

Most discussion of Outlook’s Trust Center focuses on what it does to incoming messages — blocking external pictures, automatic download settings, that sort of thing. Almost nothing is written about its effect on outgoing messages, because in most cases there isn’t one. But there are two settings worth knowing about.

In File → Options → Trust Center → Trust Center Settings → Email Security, there’s a section called “Encrypted email”. If you have S/MIME encryption enabled, and you send a signed or encrypted message with inline images, the way those images get packaged inside the encrypted envelope can confuse recipients whose clients handle S/MIME differently from Outlook. This is uncommon outside specific regulated industries, but if you’re in one of those industries and you’ve recently turned on S/MIME, that’s a candidate cause worth checking.

The second is in Mail → Stationery and Fonts → Personal Stationery. If you’ve set a stationery template that includes a background image or graphic, that image gets embedded in every outgoing message and can interact unpredictably with your inline images in the body. The fix is to not use stationery; it’s a feature most people enabled by accident years ago and never disabled.

What recipients see versus what you see

A diagnostic step almost nobody recommends: actually look at the raw MIME source of your sent message. In Outlook Classic, with the message open in Sent Items, go to File → Properties → Internet headers. That only shows you the headers, which isn’t enough. The better approach is to send a test message to a webmail account you control (Gmail, Outlook.com, anywhere with a “show original” or “view source” option) and inspect the raw message there.

What you’re looking for:

  • Are there Content-Type: multipart/related sections? Good — that’s the inline-image container.
  • Is the image part labelled Content-Disposition: inline with a Content-ID header? Good — that’s correctly inline.
  • Is the image part labelled Content-Disposition: attachment? That’s your problem, and it confirms it’s a sending-side issue, not a rendering issue.
  • Is there a winmail.dat part anywhere? You’re sending RTF. Go back to the format trap section above.

This inspection takes five minutes and tells you definitively where the problem is. Most users never do it because the troubleshooting articles tell them to start changing settings. The Microsoft Support pages on this topic are particularly bad about jumping straight to registry edits without ever asking the user to verify what’s actually in the message they’re sending.

For completeness, here’s what to skip:

“Clear the Outlook secure temp folder.” This affects what you see when reading messages, not how outgoing messages are encoded. It’s irrelevant to the inline-image-as-attachment problem on the sending side.

“Disable add-ins.” If you have a signature add-in that’s mangling outgoing messages, sure. Otherwise this is generic advice that won’t help.

“Repair Office.” Worth a try only after the format and registry checks. Image handling is configuration-driven, not corruption-driven, in 95% of cases.

“Switch to plain text.” Plain text doesn’t support inline images at all. If a forum suggests this as a fix for inline-image problems, they’ve misunderstood the question.

“Re-add your account.” Sometimes resolves profile-corruption cases, but it’s a sledgehammer for a screwdriver problem. Try the targeted fixes first.

The configuration that actually works

For a standard IMAP or POP account in Outlook Classic, here’s the configuration you want:

  1. Message format set to HTML, with RTF-to-HTML conversion enabled for internet recipients.
  2. Send Pictures With Document registry value set to 1 (or absent, on current 365 builds where it’s ignored).
  3. Images inserted via Insert → Pictures → This Device, not pasted from a browser or screenshot tool that may bring exotic formatting along.
  4. Images sized appropriately — under 1 MB each, reasonable display dimensions — to avoid the Gmail-proxy issue and to keep total message size manageable.
  5. No RTF-only formatting in the signature (no embedded Office objects, no rich-formatting flourishes that force RTF mode). If you’re specifically chasing a signature image that won’t embed properly, the diagnostic flow is similar but with a few extra wrinkles covered in the Outlook signature images attachment guide.

With those five conditions met, inline images will arrive inline for the overwhelming majority of recipients on the overwhelming majority of mail clients. If they don’t, the problem is almost certainly on the recipient side — their image-blocking, their preview pane, their corporate gateway — and is not something you can fix from your end.

The bigger point: IMAP and POP image handling in Outlook Classic is fundamentally solvable client-side, because every decision about how the message is encoded happens on your machine. There’s nothing magical and nothing hidden once you know where the levers are. Most of the time online advice doesn’t help because it’s solving an Exchange problem you don’t have.