There is a question that comes up, with remarkable regularity, in the inbox of every email signature designer, IT administrator, and marketing professional who has ever tried to maintain a polished brand presence in email communications. The question goes something like this: "Our signature looked amazing when we first sent it. But now, after a few replies, it's a mess. What went wrong with the signature?"
The answer - and this is the point that must be stated clearly and without qualification - is that nothing went wrong with the signature. The signature did exactly what it was designed to do. What happened was something else entirely: the email client got involved.
This article explains, in precise terms, exactly what Gmail, Microsoft Outlook, and Apple Mail do to HTML email signatures as messages pass through reply chains — and why no signature software, no developer, and no amount of clever HTML coding can fully prevent it.
The First Send: A Controlled Environment
When an email is composed and sent for the first time, the email client renders the signature in what is effectively a controlled environment. The HTML is intact. The images are present. The CSS is unmodified. The client has had no reason to interfere with the structure because it is delivering an outbound message, not processing an incoming one.
This is why the first send almost always looks exactly right. The layout is clean, the logo renders correctly, the typography is consistent, and the contact details are properly aligned. The signature designer's work is faithfully represented. There is nothing to criticise. The signature is doing its job.
The problems begin when someone hits Reply.
The Reply Chain: Where Email Clients Take Liberties
When a reply is composed, the email client must take the previous message - including its HTML signature - and embed it into the new message as quoted content. This is where things begin to unravel, and it is entirely the email client's doing.
Each of the major clients handles this process differently, and none of them handles it particularly well for HTML signatures.
Gmail
Gmail is arguably the most aggressive modifier of quoted HTML content. When Gmail wraps a previous message in a reply, it applies its own inline styles, strips certain CSS properties it considers unnecessary, and frequently rewrites HTML structure to conform to its own rendering model.
Gmail is particularly prone to stripping or modifying <style> block declarations when they appear in quoted content. Because Gmail does not support embedded stylesheets in general email rendering and instead relies on inline styles, any signature that depends on class-based CSS styling will begin to lose its formatting on the first reply pass. Classes are ignored; declarations disappear; the rendering engine substitutes its own judgement for the designer's.
Image handling in Gmail replies is another significant source of degradation. Gmail may block externally hosted images in quoted portions of a message, particularly where those images have been seen before and are being rendered in a collapsed or partially-loaded state. A logo or social media icon that appeared clearly on the first send may appear as a broken image icon, a grey placeholder, or simply vanish from the layout entirely within a few rounds of replies.
Gmail also has a well-documented behaviour involving what it calls the "clipping" of long messages. When a thread becomes lengthy, Gmail truncates the visible HTML and presents the familiar "[Message clipped]" link. The signature, sitting at the bottom of the message, is often the first casualty of this clipping. Even if the HTML itself is technically intact, it may not render at all for a recipient viewing the thread in Gmail.
Microsoft Outlook
Outlook presents a different set of challenges, largely rooted in the fact that Outlook for Windows (as distinct from the newer Outlook for Mac or Outlook on the web) uses the Microsoft Word rendering engine to process HTML. This decision, which has attracted sustained criticism from email developers for well over a decade, means that Outlook applies Word's understanding of HTML and CSS rather than that of a modern browser.
When Outlook processes a reply chain, it converts HTML content - including signatures - through this Word-based rendering pipeline. The consequences are significant and largely predictable: CSS properties that are standard in modern web development are either ignored or reinterpreted. max-width declarations, display: flex, and many background properties are either stripped or have no effect. Padding and margin values may be collapsed or misapplied.
More problematic still is what Outlook does with images in quoted content. Outlook frequently converts externally hosted images to attachments, or strips them from the quoted portion of a reply entirely. An image that was referenced by a URL in the original signature may, after one or two rounds of Outlook processing, be absent from the thread entirely or appear as an attachment with a generic filename — completely disconnected from its original context in the layout.
Outlook also has a long-standing behaviour of adding its own paragraph spacing, line heights, and font declarations to quoted HTML content. These additions override the designer's specifications. Font sizes change. Line spacing expands or contracts. The careful typographic choices embedded in the original signature are quietly overwritten by Outlook's defaults.
In corporate environments where Outlook is the dominant client, email threads involving contacts who use different versions of Outlook - desktop versus web versus mobile - introduce additional layers of inconsistency, because each version applies slightly different rules to the HTML it processes.
