Skip to main content

Keeping your CSS alive in Salesforce Marketing Cloud

Salesforce Marketing Cloud (SFMC) has an aggressive habit of stripping CSS from your email's <head>. Specifically, it removes any style rule whose selector references a class that does not appear anywhere in the email body. The logic is meant to clean up unused styles — but the side effect is that it quietly deletes your media queries and mobile styles whenever a given module is not included in the email.

The result: emails that look fine in your editor render as un-responsive blocks on mobile the moment they go through SFMC.

Why this happens​

SFMC scans the HTML body for class names before sending. If a class defined in <head> — say .hide-on-mobile or .h-400 — does not appear on any element in the body, SFMC treats the rule as dead code and removes it along with any media query block that depends on it.

This is a problem because a well-structured email system defines all possible utility classes once in the <head>, but only uses a subset of them depending on which modules are included in a given send. Some emails may never use .h-300, but the rule still needs to survive the SFMC parser so it is available if the module is present.

The fix: a hidden class registry at the bottom of the email​

The workaround is to add an invisible block at the very bottom of the email body containing an empty <span> for every CSS class you want to protect. SFMC sees the class names in the body, decides the rules are "in use," and leaves them alone.

The block is wrapped in a non-Outlook conditional comment so it never renders anywhere — it purely exists to satisfy the SFMC parser.

<!--[if !mso]><!-->
<tr>
    <td colspan="3" style="display:none;">
        <span style="display:none;">
            <span class="hide-on-mobile"></span>
            <span class="show-on-mobile"></span>
            <span class="break"></span>
            <!-- Add a <span> for every CSS class defined in your <head> styles -->
        </span>
    </td>
</tr>
<!--<![endif]-->

How it works​

  • <!--[if !mso]><!--> / <!--<![endif]--> — A reverse conditional comment. Outlook ignores everything between these tags. All other clients — including SFMC's parser — see the content normally.
  • display:none on the <td> and the outer <span> — Nothing renders visually. The block is invisible in every inbox.
  • One <span> per class — Each empty span carries a class name. That is enough to convince SFMC that the class is used and that its corresponding style rules should be preserved.

What to include​

Add a <span> for every class that appears in your <head> styles. This typically includes:

  • Responsive layout classes — anything toggled by media queries (hide-on-mobile, show-on-mobile, break, min-width)
  • Spacing utilities — height and width helpers (h-400, w-50p, etc.)
  • Typography classes — font size or weight modifiers applied on mobile
  • Interactive classes — hover effects, button states

If you add a new utility class to your stylesheet, add a matching <span> to this block at the same time. It is easy to forget, and the failure mode (broken mobile layout in a specific send) can be hard to trace back to this cause.

Placing the block​

Put the block as the last row inside your outermost <table>, just before the closing </table> tag. It needs to be inside a <tr> / <td> structure to be valid HTML within a table-based email layout.