A version of this problem has existed in Outlook for as long as Outlook has had signature support. You insert a logo into your signature. You test it by sending yourself an email. The image looks fine. Then a recipient tells you that all your emails arrive with a paperclip icon, or that your logo shows up as an attachment in the attachments list, or that the recipient’s mail client treats every message you send as having a file attached even when you have not attached anything.
This is the single most common signature complaint in Microsoft’s support forums. It has been the most common signature complaint for fifteen years. And almost every article you will read about it gives you the same advice — turn on HTML format, check your signature settings, reinstall Outlook — which mostly does not fix it because the advice misdiagnoses the cause.
The reason this problem persists is that it is not one problem. It is at least four distinct problems with the same symptom, and they happen on different account types, and the fixes are different. The path to actually solving it is to identify which problem you have, not to run through a generic checklist.
This article is the decision tree, with the account-type branches, with the bad advice called out explicitly so you stop wasting time on fixes that will not work for your situation.
Identify your account type first
This is the part most articles skip, and it is the most important step. Outlook handles signature images differently depending on the underlying account protocol. The fix you need depends on which protocol your mailbox uses.
Microsoft 365 / Exchange Online: Most modern business accounts. The mail account is hosted by Microsoft in the cloud. Even if you connect via Outlook desktop, the underlying protocol is Exchange. Check File > Account Settings — if your account type says “Microsoft Exchange” and your server name ends in .outlook.com or includes outlook.office365.com, this is you.
On-premises Exchange: Less common now but still significant in enterprise environments. Same Exchange protocol, but your server is in your organisation’s data centre. Server name will be an internal hostname.
IMAP: Many small business setups, most Gmail-in-Outlook configurations, and most third-party hosting providers. Account type will say “IMAP” in Account Settings.
POP3: Older personal accounts and some legacy small-business setups. Account type will say “POP” in Account Settings.
If you are not sure which one you have, go to File > Account Settings > Account Settings, select your account, and click Change. The protocol is named there.
The reason this matters: Exchange accounts handle signature image embedding through MAPI, IMAP and POP handle it through standard MIME multipart, and the failure modes are subtly different between the two paths. Generic advice that does not account for this is generic advice that will not fix your specific case.
The four real causes
In rough order of how often they actually cause this problem:
Cause 1: Plain text format somewhere in the pipeline
The most common cause and the most under-diagnosed. Even if your Outlook is set to HTML for new messages, replies often inherit the format of the message they are replying to. If someone sends you a plain text email and you reply, your reply may go out as plain text. Plain text messages cannot embed images inline; the image gets attached as a separate file. The recipient sees a paperclip even though you never explicitly added an attachment.
The format conversion can also happen in transit. A poorly-configured Exchange transport rule, a third-party security gateway, or a virus scanner with Outlook integration can rewrite messages from HTML to plain text mid-flight. You will not see this in your Sent folder because the Sent folder shows the message as you composed it, not as it left your server.
How to verify: Send a test email with your signature to a recipient on a different mail platform (a personal Gmail account works). Have them check the source — the raw email — for Content-Type: text/plain versus Content-Type: multipart/alternative and text/html. If you see plain text where you expect HTML, the format conversion is happening somewhere.
Fix on Outlook: Tools/File > Options > Mail > Compose messages > set to HTML. Check Replies and Forwards specifically — there is a separate setting on some versions for “Use the format of the original message” versus “Always reply in HTML.”
Fix on Exchange side: Check transport rules for anything that rewrites message format. Check your virus scanner’s Outlook integration settings.
Cause 2: The image is correctly embedded, but the recipient’s mail client interprets it as an attachment
This is the cause that none of Microsoft’s official documentation handles well, and it is enormously common. Outlook embeds your signature image correctly using a cid: reference to a MIME-attached image part. This is the standard mechanism for inline images in email. But many recipient mail clients — Apple Mail, Outlook on iOS in certain configurations, Thunderbird, older versions of Outlook itself — will display a paperclip icon for any message that contains MIME-attached image parts, even if those parts are referenced inline. The recipient sees a paperclip; the recipient assumes there is an attachment; the recipient is annoyed.
The image is not actually an attachment in the strict sense. It is an inline image that the recipient’s client is choosing to render with an attachment indicator. From the recipient’s perspective, this distinction is meaningless — they see a paperclip, they look for an attachment, there is no attachment beyond the signature image. They are correctly annoyed.
How to verify: Send a test message to multiple recipients on different mail platforms. If the paperclip appears for some recipients (typically Apple Mail, Thunderbird) but not for others (typically Outlook to Outlook), the cause is recipient-client-side rendering of correctly-embedded inline images.
This is the case where Microsoft’s stock advice does not help. Changing your Outlook settings will not change how Apple Mail renders your messages. The only complete fix is to switch from embedded images to externally-hosted linked images, which has trade-offs of its own (see Cause 4 below).
Cause 3: Virus scanner or third-party Outlook add-in rewriting messages
This is the cause that drives IT support teams to despair because it is invisible until you go looking for it. Many endpoint security products integrate with Outlook through COM add-ins. Some of these add-ins rewrite outgoing messages — re-encoding images, re-formatting HTML, adding security headers, or stripping certain content. Any of these operations can break the inline image embedding such that the image ends up as a separate attachment.
The symptom is highly variable. Sometimes it affects only certain recipients (the security product treats internal vs external recipients differently). Sometimes it affects only certain mail flows (only messages over a certain size). Sometimes it has been happening for years and was never identified because the company’s email looks fine internally and only external recipients complain.
How to verify: Disable all Outlook COM add-ins (File > Options > Add-ins > COM Add-ins > Go > untick everything). Restart Outlook. Send a test message externally. If the paperclip stops appearing, one of the add-ins is the culprit. Re-enable add-ins one at a time to identify which.
Fix: Adjust the offending add-in’s configuration if it has settings for image handling, or accept that this add-in is incompatible with your signature workflow, or switch to externally-hosted signature images that are not affected by message rewriting.
Cause 4: The “correct” Outlook signature workflow that is actually broken
This is the cause everyone wants to know about because it is the one users created themselves. The standard Outlook signature workflow — Insert > Picture, browse to a local image, embed it in the signature — produces inline images that are correctly formatted but that hit Causes 2 and 3 in the wild.
The signature itself is not broken. The Outlook embedding mechanism is not broken. But the result is unreliable across mail clients because of the issues described above.
The fix is to stop embedding the image and start linking to it. Instead of inserting a local image into your signature, host the image on a web server (your company’s website is fine, or a CDN, or a signature management platform) and edit the signature HTML to use an <img src="https://yourdomain.com/signature-logo.png"> reference. The signature now contains a URL, not an image. Every recipient’s mail client fetches the image from the URL when they open the message. No paperclip, no attachment, no rendering inconsistency.
The trade-off is that linked images are blocked by default in many mail clients (this is the “click here to download pictures” prompt). Recipients have to either trust your sender domain or click to load images. For corporate signatures sent to known recipients, this is usually fine. For marketing emails to cold lists, it is a problem.
The full setup walkthrough for hosted signature images is in the platform comparison: Outlook signature platforms compared.
What works by account type
Exchange / Microsoft 365 accounts
The good news: Exchange accounts have the best image-embedding behaviour in Outlook. The MAPI send pipeline preserves embedded images correctly. The bad news: Exchange has the most complex set of moving parts that can break it — transport rules, organisation-level configurations, Office 365 policies.
For Exchange/M365, the practical priority order is:
- Verify outbound message format is HTML (Cause 1).
- Test against multiple recipient platforms to identify whether the issue is sender-side or recipient-side rendering (Cause 2).
- Disable Outlook add-ins to rule out interference (Cause 3).
- If 1-3 do not resolve it, switch to externally-hosted signature images (Cause 4).
Full Exchange-specific troubleshooting including transport rule auditing is in Outlook Classic inline images for Exchange accounts.
IMAP and POP accounts
IMAP and POP accounts behave differently in two ways that matter for this problem. First, the send pipeline is more direct — fewer intermediate hops where format rewriting can happen. Second, image embedding tends to be more fragile because IMAP/POP clients often handle MIME multipart less robustly than Exchange.
Many small business setups in Outlook use IMAP because that is what the hosting provider supports. Some of those setups are running Outlook against a Gmail backend, which adds another layer of behaviour difference. For IMAP and POP specifically, the failure modes around signature images are typically Cause 2 (recipient rendering) rather than Cause 1 (format conversion).
The IMAP/POP-specific guidance is in Outlook Classic inline images for IMAP and POP accounts.
New Outlook (any account type)
New Outlook for Windows handles signatures differently from Classic Outlook. Signatures are stored tenant-side, fetched at compose time, and embedded into the outgoing message through a different code path. The failure modes are different — fewer issues with virus scanner add-ins (because COM add-ins are not supported), but new issues with image fetch delays at compose time and with the way recipient mail clients interpret New Outlook’s more standards-compliant HTML.
For New Outlook specifically, see inline images appearing as attachments in New Outlook and setting up a working signature with images in New Outlook.
The bad advice you should ignore
Three pieces of widely-circulated advice on this problem are wrong often enough that they deserve to be called out.
“Switch to HTML format and the problem goes away.” Sometimes. If your problem is Cause 1, yes. If your problem is Cause 2, 3, or 4, switching to HTML format does nothing because the format is already HTML.
“Resize your signature image to a smaller file size.” This will not fix the attachment indicator. The image is showing as an attachment because of the embedding mechanism, not because of the file size. A smaller image will still be embedded the same way and will still trigger the same paperclip on recipient clients that misinterpret inline images as attachments.
“Just turn off the paperclip icon on your end.” You cannot change what recipients see. The paperclip is rendered by their mail client, not yours. Settings on your end do not affect how their email displays.
If the article you are reading recommends any of these as a primary fix without first identifying which of the four causes you have, the article is offering you a checklist rather than a diagnosis.
Frequently asked questions
Q: Why does the paperclip appear for some recipients but not others?
A: This is the strongest signal that your problem is Cause 2 — recipient-side rendering of correctly-embedded inline images. Different mail clients display inline images differently. Apple Mail and Thunderbird show paperclips for any message with MIME image parts; Outlook-to-Outlook usually does not. The image is embedded correctly; some recipients interpret the embedding as an attachment.
Q: My signature image looks fine in my Sent folder but recipients see it as an attachment. Why?
A: Your Sent folder shows the message as you composed it, before any in-transit transformations. If a virus scanner, transport rule, or third-party add-in is rewriting the message after it leaves your client, the Sent folder will not show the rewritten version. Check the message at the recipient’s end (asking them to view source is the cleanest test) to see what they actually received.
Q: Will switching to New Outlook fix this?
A: Possibly, but not universally. New Outlook avoids some of the Classic Outlook causes (no COM add-ins to interfere) but introduces new behaviours of its own. If your problem is Cause 1 (format conversion) or Cause 4 (the embedded image being interpreted as an attachment by recipients), switching clients alone will not fix it.
Q: I have a signature management platform like Exclaimer or WiseStamp. Why do I still have this problem?
A: Signature management platforms can introduce their own variants of this problem because they rewrite outgoing messages to inject the signature server-side. The injection mechanism varies by platform. Some platforms host images externally (avoiding the embedding problem). Some embed locally (preserving the embedding problem). Some do something in between. Platform-specific behaviour is covered in Outlook signature platforms compared.
Q: Is there any single fix that works for everyone?
A: Externally-hosted linked images. Switch from embedded signature images to <img src="https://yourdomain.com/logo.png">-style references. This eliminates Causes 2, 3, and 4 in one move. The trade-off is the “click here to download pictures” prompt in some recipient clients, which is usually acceptable for known-recipient corporate signatures.
Companion reading: Inline images appearing as attachments in New Outlook for the New Outlook-specific version of this problem; Outlook Classic inline images for Exchange accounts for Exchange-specific server-side considerations; Outlook signature platforms compared for vendor evaluation if you decide to move signature management out of Outlook entirely.
Related: New Outlook vs Classic Outlook image handling for the broader comparison of how the two clients handle images; Microsoft Office image regression timeline for current known image-related bugs across Office.