Your recipient sees image001.png, ATT00001.htm, or your logo arrives as a downloadable file instead of rendering inline. Here's why mail clients attach signatures instead of inlining them and the fix for each cause.
The MailSigCraft Team
MailSigCraft
You sent a clean HTML signature with a logo and a headshot. The recipient opens the email and sees the body text, no logo, and a row of attachments at the bottom: image001.png, image002.png, sometimes a stray ATT00001.htm for good measure. To them it looks like you sent two files along with a half-empty email. The signature is technically in the message — the mail client just rendered it as attachments instead of inline.
This is one of the most-reported "works for me, broken for them" signature failures, and the cause is almost never the image itself. It's the message format, the path the image takes from your sender to their inbox, or a gateway in the middle that detaches and re-attaches the inline parts. Six specific failure modes account for nearly every case.
Forward the same broken email to a second mail client (a personal Gmail address, view source in your sent folder) before you start changing things. The diagnostic path branches based on whether the attachment is baked into the outgoing message or added by the recipient's mailbox.
Outlook lets you choose between HTML, Rich Text, and Plain Text as the composing format. Plain Text can't render images, links, or formatting — so when you have an HTML signature loaded but you're composing in Plain Text, Outlook strips the inline image rendering and attaches every image as a file. The recipient sees plain text plus image001.png, image002.png, etc.
The same thing happens silently when you reply to a plain-text email: Outlook (and Apple Mail) defaults the reply format to whatever the original message used, so your HTML signature attached to a Plain-Text reply gets converted on the way out.
In Outlook, go to File → Options → Mail → Compose messages in this format and set it to HTML. For per-message control, open the Format Text ribbon in the compose window and click HTML. In Outlook for Mac, Settings → Composing → Compose messages in HTML format. After switching, send a fresh email (don't just resend the broken one — the original still has plain-text framing).
Rich Text Format is Outlook's proprietary third option, and it's a quiet disaster for cross-client signatures. When an Outlook user sends RTF to a non-Outlook recipient, Outlook wraps the entire body — including the signature and every inline image — into a single binary attachment named winmail.dat (also called a TNEF envelope). The recipient on Gmail, Apple Mail, or Outlook for Mac sees an empty message and one downloadable winmail.dat file they can't open.
Never compose signatures in Rich Text Format. Two places to check:
The winmail.dat problem is fully on the sender side — switching to HTML resolves it for every recipient at once.
When Outlook can't fetch a linked image at send time — internal CDN, expired URL, host blocks Outlook's user agent, network share that only resolves on your VPN — it doesn't always show a broken-image icon. Sometimes it embeds a cached copy from your local image cache as an inline attachment and writes the HTML to reference that attachment. To the recipient, it looks like a regular image001.png attachment because Outlook didn't reference it by Content-ID in the HTML.
This is the most common cause of "the signature works for some recipients and arrives as an attachment for others" — you're on the internal network, your laptop fetched the image fine when composing, and Outlook fell back to local-cache-as-attachment on send.
Host signature images on a public HTTPS URL that doesn't require auth, doesn't block hotlinking, and serves a long Cache-Control: public, max-age=31536000 header. Cloudinary, imgix, Cloudflare R2, S3 with public-read, and the MailSigCraft editor all meet this bar. Open the URL in a brand new incognito window from a phone on cellular data — if it loads there, Outlook on every recipient's machine will fetch it cleanly.
The image-not-showing post covers the wider hosting checklist — many of the same root causes show up as broken images for some clients and as attachments for others.
HTML email supports two ways to attach an image: by URL (<img src="https://...">) or by Content-ID reference (<img src="cid:logo"> paired with a multipart/related payload). If the message contains an image part with a Content-ID but the HTML <img> tag uses a URL instead — a common bug when signatures are migrated between tools or pasted from one client to another — the image part travels along the wire as an orphan. The recipient's mail client has no rule to inline an unreferenced part, so it lists it in the attachment row instead.
Pick one mechanism per image and stay consistent. Either embed and reference by CID, or host on a CDN and reference by HTTPS URL — never both. The cleanest path is to render the signature HTML once from a single source (the MailSigCraft editor ships either fully CDN-hosted or fully base64-embedded output, no mixed mode) and paste that exact HTML into Outlook.
If your signature renders fine for some recipients and arrives as ATT00001.htm plus image001.png for others — and the broken recipients are on corporate Microsoft 365, Mimecast, Proofpoint, Exchange Online, or a Content Disarm & Reconstruction (CDR) gateway — the problem is on their side, not yours. Security-focused gateways inspect HTML bodies for tracking pixels, scripts, and embedded threats. Some do this by parsing the inline content out, rewriting the visible HTML to a plain-text simplification, and re-attaching the original HTML as ATT00001.htm so nothing is "lost." Inline images get the same treatment and arrive as image001.png.
There is no fix you can apply to the outgoing message — the recipient's gateway is doing this. What you can do:
Apple Mail (macOS + iOS) handles inline images in new messages cleanly, but when you reply to a thread that already contains a signature with inline-attached images, Apple Mail repackages those original inline images as named attachments (image001.png, image002.png) in the quoted history of the reply. The recipient sees the new message fine; what they also see is two random PNG attachments — the old signature's images, now disconnected from the HTML.
This is a quirk of how Apple Mail rewrites multipart/related containers when threading. Outlook does it too, but more rarely.
There's no sender-side fix because the rewrite happens during reply composition by whoever replies to your message. What you can do is ship signatures that won't be repackaged in the first place: use HTTPS-hosted images referenced by URL (not Content-ID embedded). URL-referenced images don't travel inside the message body, so there's nothing for Apple Mail to detach during a reply — the URL just stays as-is in the quoted history.
The MailSigCraft editor defaults to CDN-hosted images via HTTPS for exactly this reason — the signature you paste once doesn't degrade across the reply chain.
If recipients see a small smime.p7s file attached to your emails, that's not a signature-rendering bug — it's the digital signature attached when S/MIME email signing is enabled on your account. The S/MIME signature lives next to the message body and proves the email genuinely came from you. Some older mail clients (BlackBerry, ancient webmail) can't parse S/MIME and surface it as an attachment.
To remove it, disable S/MIME signing in File → Options → Trust Center → Email Security (Outlook) or Mail → Preferences → Smart Addresses → S/MIME (Apple Mail). Leave it on if you need verifiable identity for compliance.
Compose format is HTML — not Plain Text, not Rich Text.
Every <img src> is an absolute HTTPS URL on a public CDN — not a local path, not a network share, not a file-sync service link.
The signature uses one image-embedding mechanism: either all CDN-hosted by URL, or all base64-inline. Never both.
The signature has no Content-ID-referenced images alongside URL-referenced images.
The MailSigCraft editor renders signatures that already pass this checklist — HTTPS URLs, explicit dimensions, single embedding mechanism, no orphan parts, and paste output verified across Outlook (classic + 365), Gmail (web + iOS), Apple Mail (macOS + iOS), and Outlook for Mac. Most "shows as attachment" reports we get are downstream of one of these six causes, and the editor sidesteps four of them by default.
If you frequently reply to plain-text emails, get into the habit of clicking the HTML option in the Format Text ribbon before adding the signature.
width="120" height="40"This is the one cause on the list you cannot resolve unilaterally, but it's also the rarest — gateways aggressive enough to do this represent maybe 5% of business inboxes.
Forward the test to a Gmail address and a personal Outlook.com address — if it renders inline in both, no corporate gateway is going to attach-ify it unless they're running very aggressive CDR.