Why Is My Email Signature Showing as an Attachment?

The attachment problem is one of the most frustrating recurring issues in email signature management, and it stems from how different email clients handle images in HTML email.

When you set up a signature using Microsoft Word's Insert Picture function, or when Outlook is configured to use Rich Text Format (RTF) internally, images are attached to the email as separate files and referenced from the HTML. When this email is sent and received by another email client — especially non-Microsoft clients like Gmail, Apple Mail, or Proton Mail — the image attachment gets separated from the HTML and displayed as an unnamed attachment at the top or bottom of the email. The recipient sees your email with a paperclip icon and a cryptic attachment like 'ATT00001.jpg' or 'winmail.dat'.

The winmail.dat problem is specifically a Microsoft artifact. Outlook uses a proprietary format called TNEF (Transport Neutral Encapsulation Format) when sending to certain recipients, which packages all attachments and formatting into a single 'winmail.dat' file. Non-Microsoft email clients cannot always decode this format, and the resulting attachment appears instead of the correctly formatted signature.

The second trigger is when the signature HTML references images using local file paths (like C:\Users\yourname\logo.png) or intranet URLs that are not accessible to recipients outside your network. The image link breaks, and some email clients create a placeholder attachment to indicate where the image was supposed to appear.

Gmail's behavior is somewhat different. Gmail generally handles image links gracefully by either loading the image if the URL is accessible or showing a broken image placeholder. However, Gmail and Google Workspace will sometimes flag signature images as inline attachments when they are received from Outlook, particularly when the sending account has rich text formatting enabled.

HTMl signatures built with base64-encoded images bypass this entire category of problems. Because the image data is embedded directly in the HTML string — not stored as a separate file or referenced by URL — there is no separate attachment to detach, no external URL to evaluate, and no TNEF packaging to confuse cross-platform recipients.

The most reliable fix is to rebuild your signature using base64-embedded images and install it through your email client's native signature settings, not through Microsoft Word or an external HTML file.

In Outlook: go to File → Options → Mail → Signatures. Create or edit your signature in the built-in signature editor. Do not paste from Word or drag and drop image files. Instead, use a signature HTML file generated by a tool like SignatureFox, which produces base64-encoded images that Outlook handles without creating phantom attachments.

Also check your Outlook message format. Go to File → Options → Mail → Compose Messages and ensure the format is set to HTML, not Rich Text. Rich Text Format (RTF) is what triggers the winmail.dat and ATT00001 attachment issues. HTML format with base64-embedded images eliminates both problems.

For Gmail: install your signature through Settings → See All Settings → General → Signature. Gmail's built-in editor does not support pasting raw HTML, but you can use a signature installed via Google Workspace admin or by copying the formatted output from a generator into the Gmail signature editor. Avoid linking to external image URLs — Gmail renders them inconsistently depending on the recipient's email client and security settings.

If your signature was set up correctly and the attachment problem appeared recently, check whether Outlook was updated or whether your organization's Exchange server settings changed. Some Exchange transport rules transform outgoing messages from HTML to RTF, reintroducing the attachment issue even in properly built signatures.