Why the signature looked fine and arrived broken
A signature that renders perfectly in the browser you built it in can collapse into a stack of left aligned text with a red cross where the logo was. The reason is not your HTML. It is that one of the clients receiving it is not using a browser engine at all.
| The root cause | Classic Outlook for Windows renders HTML mail with the Microsoft Word engine, not a browser engine. |
| What that costs you | Microsoft documents float, position, z-index, overflow and every background-image property as unsupported. |
| The layout that works | Nested tables with inline styles. Not because it is good practice, but because it is the only thing every engine agrees on. |
| The image problem | Images are blocked until the reader allows them, so a signature made of one image arrives blank. |
| The attachment problem | An embedded logo travels as a MIME part on every single message, which is where the phantom paperclip comes from. |
| Dark mode | A logo on a white background becomes a white rectangle on a dark card. Transparency is not enough on its own. |
Every guide to building an html email signature shows you a template and a generator. Almost none of them explain why the template is built the way it is, which means that the first time you edit it, you break it. This page is the explanation: what the receiving software actually does with your markup, which properties are documented as unsupported, and the subset that survives everywhere.
Outlook renders your signature with Microsoft Word
This is the single fact that explains most of the category, and Microsoft states it directly in its own developer documentation:
“Microsoft Office Outlook 2007 uses the HTML parsing and rendering engine from Microsoft Office Word 2007 to display HTML message bodies. The same HTML and cascading style sheets (CSS) support available in Word 2007 is available in Outlook 2007.”
That documentation is written for Outlook 2007, and it matters in 2026 because the Word based rendering path stayed in classic Outlook for Windows long after 2007. The newer Outlook for Windows and Outlook on the web use a web rendering engine instead, which is why the same signature can look correct for one colleague and collapse for another inside the same company. You are not testing one client. You are testing at least two, sharing a name, and which one a given colleague runs often follows from how their mailbox was added in the first place, as the Outlook connection settings set out.
What Microsoft documents as unsupported
The list below is not folklore from email developer forums. These are properties Microsoft’s own documentation marks as unsupported in the Word rendering path.
| Property | What breaks when you use it |
|---|---|
float and clear | A logo meant to sit left of the text drops below it, and the whole signature becomes a single column. |
position, top, bottom, left, right, z-index | Anything placed by coordinates lands at the flow position instead, usually overlapping or stacked. |
background-image, background-position, background-repeat, background-attachment | Decorative backgrounds and banner strips simply do not appear. |
overflow, overflow-x, overflow-y, clip | Nothing is clipped, so content sized to be cropped spills out at full size. |
list-style-image, list-style-position | Custom bullets fall back to defaults, which is usually harmless and occasionally ugly. |
text-transform, word-spacing | Typography set in CSS rather than in the source text is ignored. |
Read that list and the standard email signature template stops looking like an anachronism. Nested tables, inline styles, fixed pixel widths and spacer cells are not nostalgia for 2003. They are what remains once you remove every property above.
The practical rule
Build the layout with a table, put every style inline on the element it applies to, and give every image an explicit width and height attribute. A stylesheet in a <style> block is worse than useless here: some clients strip it entirely, which leaves the signature unstyled rather than differently styled.
The five ways a signature breaks in the wild
Images are blocked until the reader allows them
Most clients do not load remote images from an unknown sender by default, and that default is a privacy feature rather than a bug: loading an image tells the sender the message was opened. Gmail takes a different route and proxies images through its own servers, which loads them but strips the sender’s view of who opened what.
The consequence for signatures is direct. Whatever the image was carrying, the reader may never see it. If your job title, your phone number or your legal disclaimer lives inside a graphic, it is missing for a meaningful share of your recipients, and it is missing for every screen reader. Text belongs in text.
The logo that becomes an attachment on every message
When you paste an image into a signature rather than linking to one, most clients embed it as an inline MIME part and reference it by content ID. The image now travels with every message you send. Two visible effects follow: recipients see a paperclip on a message with no real attachment, and every message carries the file’s weight, which in a long reply chain gets attached again at each turn.
The alternative, hosting the image on your own domain and referencing it with an absolute URL, avoids both, at the price of being subject to image blocking. There is no option that is free of trade-offs, which is the real answer to a question most signature guides skip.
Dark mode turns your logo into a white brick
Clients that offer a dark theme handle message content differently: some leave it alone, some invert colours, some recolour backgrounds while leaving images untouched. A logo exported as a PNG with a white background survives none of that gracefully, because the surrounding card goes dark and the logo keeps its white rectangle.
Transparency helps and does not solve it. A transparent logo in dark navy disappears against a dark background just as thoroughly as a white box announces itself. The versions that survive are a logo with an outline, a light neutral monochrome mark, or a small solid colour panel behind the mark that is intended to be visible.
The signature that is only an image
Designers reach for this because it guarantees the layout: export the whole block as one PNG and nothing can reflow. It is the worst option available. It is invisible when images are blocked, unreadable to screen readers, unselectable when someone wants to copy your phone number, blurry on high density displays unless served at twice the size, and it pushes the message toward a text to image ratio that filters treat as a signal. It is one of the recurring contributors to messages landing in spam rather than the inbox.
Threads accumulate signatures
A signature appended to every message in a long exchange produces a message that is mostly signature. Where a company mandates a legal disclaimer, the effect compounds: ten replies means ten copies of the disclaimer quoted below each other.
The fix is a client setting rather than markup. Most clients let you define a different signature for replies and forwards than for new messages, and the reply version should be two lines: your name and one way to reach you. This is supported differently across desktop, web and mobile clients, so it is worth checking what yours offers before mandating a policy nobody can implement.
The subset that survives everywhere
Everything below is what remains after removing the unsupported properties and accounting for image blocking. It is not a design system. It is the intersection of what a browser engine and a word processor engine both agree to do.
| Do this | Instead of |
|---|---|
Nested <table> elements for layout, with cellpadding="0" cellspacing="0" border="0" | div with float or flexbox |
Inline style on each element | A <style> block or an external stylesheet |
Explicit width and height attributes on every <img> | Sizing images in CSS alone |
Descriptive alt text on every image | Empty or missing alt |
| Web safe font stacks with a generic fallback | A webfont loaded with @font-face |
| Fixed pixel widths, kept under roughly 600 pixels | Percentage widths and viewport units |
A solid bgcolor or inline background-color | background-image |
| Real text for name, title, phone and disclaimer | Any of those baked into an image |
| Hyphens or the word “to” in phone numbers | Relying on client autolinking to guess |
Two extras worth the effort. Serve images at twice their display size and set the displayed size in the attributes, so the logo stays sharp on high density screens. And keep the whole signature under a few tens of kilobytes: Gmail clips long messages behind a “view entire message” link, and a heavy signature on a long thread is one of the ways to trigger it.
Hosted image or embedded attachment
This is the one genuine decision in signature engineering, and it is a trade rather than a best practice.
| Hosted on your domain | Embedded as a MIME part | |
|---|---|---|
| Shows when images are blocked | No | Sometimes, since some clients treat inline parts as trusted |
| Adds weight to every message | No | Yes, on every send and every reply |
| Shows a paperclip on the message | No | Frequently |
| Can be updated after sending | Yes, by replacing the file | No |
| Depends on your web server staying up | Yes | No |
For most organisations the hosted route wins, because the ability to rebrand without asking every employee to reinstall a signature is worth more than the blocked image case, and because the alternative quietly inflates every mailbox in the company. Host the file on a domain you control rather than on a file sharing link, give it a stable path, and set a long cache lifetime.
One warning about hosted signature images: a unique image URL per recipient is a tracking pixel, whatever it is called in the product that generated it. Several signature management platforms do exactly this by default. That is a decision to make deliberately, with your legal position in mind, not one to inherit from a tool’s defaults.
Testing, in the order that finds problems
- Classic Outlook for Windows first. It is the strictest engine and it is where the signature will break. If it survives there, the rest is likely fine.
- Then Gmail on the web and Gmail on mobile, which is where clipping and image proxying show up.
- Then Apple Mail on iPhone, for the width. A signature wider than the screen forces horizontal scrolling on the whole message.
- With images blocked. Turn remote image loading off in one client and read what is left. If a phone number or a disclaimer has disappeared, it was in an image and should not have been.
- In dark mode, in at least one client that inverts, before you standardise the logo file.
- On a fourth reply in a thread, which is the only way to see the accumulation problem.
Send the tests from the account that will really use the signature. Client configuration matters here: a signature applied by a server side rule behaves differently from one stored in the client, and the way the mailbox is connected determines which of the two you actually get.
The last point is the one that survives every redesign. A signature is a contact block, not a campaign. The version that works in every client is closer to plain text than anyone expects, and the effort is better spent making sure it is legible than making it elaborate.
Frequently asked questions
Why does my HTML email signature look broken in Outlook but fine everywhere else?
Because classic Outlook for Windows does not use a browser engine. Microsoft documents that Outlook renders HTML message bodies with the Microsoft Word HTML parsing and rendering engine, and that engine does not support float, clear, position, z-index, overflow or any of the background-image properties. A layout built with modern CSS has nothing to fall back on there, so it collapses into a single column. Rebuild the layout with nested tables and inline styles and it will render in both engines.
Can I use CSS flexbox or grid in an email signature?
Not if Outlook for Windows is in your audience. Flexbox and grid depend on layout behaviour that the Word rendering engine does not implement, and there is no graceful degradation: the elements simply stack in source order at full width. Tables remain the only layout mechanism that every engine in the mix agrees on, which is why every signature template you have ever seen uses them.
Why does my logo arrive as an attachment with a paperclip icon?
Because the image was pasted into the signature rather than linked, so the client embeds it as an inline MIME part referenced by content ID and sends it with every message. Many clients show a paperclip for any message carrying parts, which is why recipients think you attached something. Hosting the image at an absolute URL on your own domain removes the attachment and the paperclip, at the cost of the image not rendering when the recipient blocks remote images.
Should I just make my signature one image?
No. It looks like the safe option because nothing can reflow, but it fails in more ways than a table layout does: it is invisible when images are blocked, unreadable to screen readers, impossible to select or copy, blurry on high density screens unless served at double size, and it pushes the message toward a text to image ratio that spam filters weigh. Keep the name, title, phone number and any legal disclaimer as real text, and let the image carry only the logo.
How do I stop my signature from breaking in dark mode?
Choose the logo file for the worst case rather than the ideal one. A PNG with a baked white background becomes a white brick on a dark card, and a transparent dark logo vanishes. What survives is a monochrome or light version of the mark, a mark with a visible outline, or a deliberate solid colour panel behind it. Avoid setting colours only in one direction: text fixed to near black on an assumed white background is unreadable the moment a client inverts the card.
How do I add an HTML signature in Gmail?
Gmail’s signature editor does not accept pasted source code, so the route is to render the HTML in a browser, select the rendered result, copy it, and paste it into the signature box in settings. Copy from a browser that preserves table structure on copy, because some do not, and check the result immediately: styles that were in a stylesheet rather than inline are lost in the transfer. Gmail also lets you set a different signature for replies, which is the setting that prevents accumulation in long threads. On a Workspace mailbox, how the account is connected to your client decides whether the client signature or the Gmail one is the one that actually goes out.
Does an email signature affect deliverability?
Not on its own, but it contributes. A signature that is one large image on a short message produces a text to image ratio that filters treat as a weak negative signal, and a heavy embedded logo repeated through a long thread inflates every message. Neither is what decides most filtering outcomes, which the bulk sender requirements from Google, Yahoo and Microsoft set out, and neither will send a legitimate business email to spam by itself. Both are avoidable, and on cold outreach in particular, where the message is already under scrutiny, the recommendation is a plain text signature with no image at all on the first contact, consistent with the rest of the cold outreach playbook.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
