Forem: Min8T

How to Inline CSS for HTML Email, The Complete Guide

Min8T — Thu, 14 May 2026 15:16:55 +0000

Crosspost note. Originally published at min8t.com/articles/inline-css-for-email. I'm one of the maintainers of MiN8T, which makes the in-browser CSS inliner referenced at the end. The technical content here applies regardless of which inliner you reach for.

You write CSS in a <style> block, the way you have for two decades on the web. You hit send. Half your subscribers see your beautiful design. The other half see something else: a colorless wall of text, a stack of mis-aligned images, a call-to-action that has lost its rounded corners and bright background and is now indistinguishable from the body copy.

The reason: most email clients strip or partially strip <style> blocks. Gmail mobile, Yahoo, AOL, several enterprise clients. They discard your stylesheet entirely. The fix is older than the problem: inline every style as a style="..." attribute on the element it targets. Inline styles are the only CSS form that every email client supports without exception.

This guide walks through exactly what inlining does, what you can't inline (and what to do with those rules instead), the specificity gotchas that produce the wrong output, and a free in-browser tool that handles the whole thing correctly.

1. Why Email Needs Inline CSS

The same HTML and CSS that renders cleanly in any modern browser becomes hostile inside an email client. Email clients are not browsers. They are a patchwork of rendering engines spanning four decades of decisions, and most of them treat your <style> block as a suggestion rather than a contract.

What gets stripped, where

The behavior varies by client. Roughly:

Gmail web (large viewport): keeps <style> blocks in <head>. Strips them in some forwarded contexts.
Gmail mobile (Android + iOS): strips most <style> blocks. The same campaign that looks fine on desktop Gmail can render unstyled on mobile.
Outlook desktop (Windows, 2007â€“2019): renders through Microsoft Word's HTML engine. Honors a small subset of style rules; ignores everything modern (flexbox, grid, transforms, transitions, custom properties, etc.).
Outlook on the web: closer to a modern browser; honors <style> in head.
Apple Mail (iOS + macOS): the most permissive major client. Honors <style> blocks fully.
Yahoo, AOL, Outlook 2003 and below, several enterprise clients: strip <style> blocks entirely.

Inline styles, styles written directly on an element via the style attribute, are the only CSS form supported by every email client without exception. That's why "inline your CSS before sending" is the universal pre-send hygiene step for HTML email.

If you only remember one rule from this article: inline CSS is the lowest-common-denominator form that every email client respects. Everything you ship to an inbox should pass through an inliner unless you have a build pipeline that already does it.

2. What Inlining Actually Does

An inliner takes HTML with a <style> block and emits the same HTML with each rule's declarations transferred to style="..." attributes on the elements that match. The structure stays identical; only the way styles are attached changes.

A minimal example. Before inlining:

<style>
  .btn {
    background: #28ef91;
    color: #2b312c;
    padding: 12px 24px;
    border-radius: 999px;
  }
</style>
<a class="btn" href="...">Read more</a>

After inlining:

<a class="btn" href="..."
   style="background: #28ef91; color: #2b312c; padding: 12px 24px; border-radius: 999px;">
   Read more
</a>

The rule is gone from the <style> block; the same declarations now live on the element. Yahoo, Gmail mobile, and every other style-stripping client now render the button correctly because the styles are attached to the element they target.

The browser does most of the work

An inliner doesn't need to parse CSS from scratch. Modern browsers expose every parsed rule via document.styleSheets. A well-built inliner loads the user's HTML into a sandboxed iframe, walks the parsed rules, computes which elements each selector matches via querySelectorAll, and writes the matching declarations as inline styles. The browser handles selector parsing, specificity, and rule expansion; the inliner just orchestrates.

3. What You Cannot Inline (And What To Do Instead)

Not every rule can be inlined. Four categories of CSS depend on living in a <style> block, and a competent inliner leaves them there.

1. `@media` queries

A media query says "apply this rule conditionally." That conditional logic doesn't translate to an inline attribute. An attribute fires unconditionally. @media (max-width: 600px) is your responsive-email lifeline; it's how you stack columns vertically on mobile and resize hero images. Leave the <style> block intact for these. Apple Mail, Gmail web (large viewport), and modern Android Gmail all honor @media queries inside <head> <style>.

@media (max-width: 600px) {
  .col { width: 100% !important; display: block !important; }
}

2. Pseudo-classes (`:hover`, `:focus`, `:active`)

Inline styles have no concept of state. Writing style="color: red" inside an <a> applies that color always, not just on hover. So a:hover { color: red } can't be inlined; it has to stay in the <style> block. Apple Mail, Gmail web, and Yahoo support hover; Outlook desktop ignores it; the rule is harmless either way.

3. Pseudo-elements (`::before`, `::after`)

The same logic. ::before creates a virtual element at parse time; an inline attribute can't simulate that. Pseudo-element rules stay in the <style> block. Be aware that Outlook desktop strips them entirely.

4. `@keyframes`, `@font-face`, `@supports`, `@import`

All four are at-rules with no element to attach to. They live in the <style> block (or in some <link> elsewhere) by definition. @keyframes animations work in Apple Mail, Gmail web, and Yahoo, useful for subtle motion. @font-face works in Apple Mail and Outlook on the web; web fonts are stripped from Outlook desktop and Gmail mobile. @supports is rarely useful in email but harmless. @import is dangerous because remote stylesheet loads are mostly stripped by privacy-conscious clients.

The pattern: a good inliner inlines what it can, preserves the rest

The output should always be:

Element-targeted rules, inlined as style="..." attributes.
Conditional + state-dependent rules, left in the <style> block, untouched.
Existing inline styles in your input, preserved unless an !important rule from a <style> block overrides them.

4. Specificity and the Cascade: The Rule That Trips People Up

When two rules in your <style> block both target the same property on the same element, only one wins. CSS specificity decides which. Most cheap inliners get this wrong.

The specificity tuple

Per the CSS Selectors L3 spec, every selector has a specificity score expressed as a 3-tuple (a, b, c):

a = count of #id selectors
b = count of .class, [attr], and :pseudo-class selectors
c = count of element types and pseudo-elements

Comparison is lexicographic: (1, 0, 0) beats (0, 99, 99). (0, 1, 0) beats (0, 0, 99).

An example that goes wrong

Consider:

<style>
  .promo { color: orange; }
  #hero  { color: green; }
</style>
<p class="promo" id="hero">Sale</p>

What color is the text? Green. The id selector #hero has specificity (1, 0, 0); the class .promo has (0, 1, 0). ID wins. A naive inliner that just walks rules in source order would write style="color: green" first then style="color: orange", leaving orange as the final inline value. Wrong.

`!important` overrides specificity

An !important declaration beats any non-important declaration regardless of specificity. So:

.promo { color: orange !important; }
#hero  { color: green; }

now resolves to orange. Inliners that don't track !important separately will get this case wrong too.

Existing inline styles also count

If your input HTML already has style="color: yellow" on the element, that inline value has effective specificity (1, 0, 0, 0). It beats anything in the <style> block except !important rules. A correct inliner preserves existing inline styles by default and only overrides them when an !important rule has a higher claim.

Why most cheap inliners get this wrong

The naive implementation walks <style> rules top-down and writes each one as inline styles, letting "later writes win." That works only for simple cases. Once you have IDs, classes, and inline styles competing for the same property, last-write-wins produces output that doesn'et match what the browser would render. Test your inliner output against the browser's getComputedStyle() to verify.

5. Build-Time vs Paste-Time Inliners

There are two ways to inline CSS for email. Pick by workflow.

Build-time (juice, MJML, Maizzle, Mailgun's library)

You wire an inliner into your build pipeline. Source HTML lives with <style> blocks; the build emits inlined output. Best when:

You ship many emails on a recurring schedule (transactional, drip campaigns).
You version-control your email source.
You want each campaign's HTML to be reproducible from source.

The downside: setup. You need a Node + build pipeline; you're committing to a specific tool's output style.

Paste-time (browser-based inliners)

You paste HTML into a textarea, get inlined output back, copy it to your ESP. Best when:

You're sending one-off campaigns or last-minute fixes.
The HTML came from a no-code tool that doesn't have its own build step.
You're QA-ing an export from someone else's pipeline.
You want zero install + zero learning curve.

For most email teams that aren't running a fully-automated send pipeline, paste-time is the realistic everyday choice. The build-time approach pays off only when the same template ships repeatedly.

6. Edge Cases and Gotchas

The Gmail 102 KB clip threshold

Gmail clips emails larger than 102 KB of HTML/text content (images don't count) and shows a "View entire message" link to expand. Anything below the clip is invisible by default, which is bad for tracking pixels at the bottom of the email and bad for unsubscribe links that fall below it. Inlining grows file size because the same rule may be repeated as inline styles across many elements. A good inliner reports the final size and warns if you cross 102 KB. If you're over, the fix is usually to remove unused selectors before inlining, or to use a build-time inliner that supports tree-shaking.

CSS shorthand expansion

When the browser parses border: 1px solid black, it expands the shorthand into border-top-color, border-top-style, border-top-width, and the same for the other three sides. Naively-implemented inliners then write 12 inline declarations where 1 would suffice, bloating output 5â€“10x. Better inliners keep the shorthand or compress longhand back to shorthand.

CSS variables (`var(--x)`)

Most email clients don't support custom properties. Outlook desktop and Gmail mobile ignore them entirely. Apple Mail and Outlook web do support them. If your source uses CSS variables, the inliner should resolve them to literal values during inlining; otherwise your inline styles will be color: var(--brand) which falls back to invalid in unsupported clients.

Pseudo-class rules with the same selector

If you have a { color: black } a:hover { color: blue }, only the first rule should be inlined; a:hover stays in the <style> block. A buggy inliner that splits selectors on comma but not on pseudo-class boundaries will erase the hover rule entirely.

External stylesheet `<link>` tags

Most clients strip external stylesheets, they don't load the URL at all. Inliners that try to fetch the linked stylesheet to merge it into the inline output run into CORS issues. The pragmatic answer: don't ship <link rel="stylesheet"> in email at all. Embed every rule in a <style> block in <head>, then inline.

7. Try It Now (Free, In Your Browser)

The MiN8T CSS Inliner does everything described above. It runs entirely in your browser, nothing is uploaded. It uses your browser's native CSS engine for parsing and selector matching, which is more accurate than any custom parser, and it correctly handles specificity, !important, pseudo-classes, @media preservation, and existing inline styles.

What to do after inlining

Inlining is one step in a pre-send pipeline. The full check before you ship:

Inline CSS, the topic of this article.
Verify rendering across clients. Free option: paste into a free preview tool. Paid option: Litmus or Email on Acid for pixel-perfect Outlook rendering.
Score the spam triggers with a content scanner that runs SpamAssassin-style rules with a per-rule breakdown.
Verify auth records separate from the content side. Spam filters care about content + sender reputation + SPF/DKIM/DMARC alignment. The first is in this article; the rest is the deliverability stack.

If you write MJML or use a build pipeline

You probably don't need a paste-time inliner. MJML inlines on compile, and most email frameworks (Maizzle, Foundation for Emails, etc.) include an inliner step. Use any MJML-to-HTML converter for quick MJMLâ†’HTML compilation in the browser, then run the result through a CSS Inliner if you want to verify the inline output independently of MJML's own choices.

Putting it all together

Inlining is a five-second pre-send step that prevents 80% of cross-client rendering issues. Combined with a quick visual verification, a content score, and DNS auth (SPF/DKIM/DMARC, separate work), you cover the entirety of the designâ†’deliverability stack. None of this should require a paid tool. The whole pipeline is free in your browser.

Originally published at min8t.com/articles/inline-css-for-email. I work on MiN8T, an email infrastructure, design, and deliverability platform. Questions or counter-examples in the comments welcome.

Why email verification is 21 checks, not 1 (and why MCP makes it agent-ready)

Min8T — Sat, 02 May 2026 18:14:17 +0000

"Valid email format" isn't enough.

hello@gmail.com and hello@gmial.com both parse as RFC-5322 valid. One reaches a real inbox. The other bounces, hurts your sender reputation, and might land you on a blocklist.

Real email-deliverability work is 20+ checks, not 1. Most "email verifier" services are a black box that returns valid or invalid and you get to trust them. I wanted something I could reason about end-to-end and that an AI agent could orchestrate piece by piece.

This is what's actually inside the pipeline I shipped (@deliveriq/mcp — open source, MIT, on npm), broken down stage by stage. If you've ever wondered why a single email check takes ~3 seconds and why each piece matters, this is the long version.

The 5 stages

The verification flow runs 5 stages with 21 checks total, in priority order. Each stage runs in parallel where possible. A failure at an early stage short-circuits the rest (you don't run SMTP if the syntax is broken).

Stage 1 — Email format validation (2 checks)

1.1 Syntax validation (RFC 5322). Local-part length, character set, proper @ placement, domain format. Catches things like @@domain.com or 80-character local parts before any network calls.

1.2 Typo detection (Sift3 fuzzy match). Compares the domain against a database of 1,200+ known misspellings. gmial.com → gmail.com. outlokk.com → outlook.com. Sift3 is a string-distance algorithm that's faster than Levenshtein for short strings — important when you're running this on every check.

Total cost so far: zero network calls. If syntax is invalid, the pipeline returns immediately.

Stage 2 — Domain & provider checks (5 checks)

2.1 Disposable domain detection. A continuously maintained list of 164,000+ throwaway domains (Mailinator, Guerrilla Mail, 10minutemail, and 164k friends). Disposable addresses self-destruct, so they're flagged high-risk by default.

2.2 Role-based detection. 130+ role prefixes — admin@, info@, support@, noreply@, postmaster@, webmaster@, etc. These typically have lower engagement and higher bounce rates than personal addresses.

2.3 Free-provider check. 200+ consumer email domains worldwide. Useful when the use case requires corporate addresses (B2B prospecting, etc.). Not a hard fail — just a signal.

2.4 Alias normalization. Resolves +tag and dot-aliases to canonical form. user+newsletter@gmail.com → user@gmail.com. u.s.e.r@gmail.com → user@gmail.com. This is how you collapse duplicates that look different.

2.5 Email-pattern analysis. Scores the local part for entropy, keyboard walks (qwerty12@), and bot-style sequences. Distinguishes human-typed from auto-generated addresses.

Stage 3 — Mailbox verification (3 checks)

This is where it gets interesting. The previous 7 checks are local — Stage 3 actually talks to the mail server.

3.1 MX record resolution. DNS MX lookup with A-record fallback. Highest-priority MX is used for SMTP. Capped at the top 2 servers to prevent timeout stacking when a domain has 8 MX records.

3.2 ISP identification. MX-pattern matching against known ISPs (Gmail, Outlook, Yahoo, Apple iCloud, etc.). This matters because some major providers aggressively block SMTP probes — for those, the pipeline skips Stage 3.3 and uses heuristic scoring instead.

3.3 SMTP handshake verification. This is the real one. The pipeline opens a TCP connection on port 25 and runs the conversation:

> EHLO verifier.example.com
> MAIL FROM: <neutral@verifier.example.com>
> RCPT TO: <hello@target.com>     # the email we're checking
< 250 OK                            # accepted = exists
> RCPT TO: <random-1234567@target.com>  # catch-all probe
< 250 OK                            # also accepted = catch-all server
> QUIT

A second RCPT TO with a random address detects catch-all servers (where the server accepts every address regardless). 5-second timeout per connection. No email is ever sent — MAIL FROM and RCPT TO are setup commands; we close before DATA.

This is the slowest part of the pipeline. ~1–2 seconds typical, sometimes more if the receiving server greylists.

Stage 4 — Reputation & intelligence (7 checks)

4.1 Gravatar lookup. Whether the address has a registered Gravatar profile picture. Positive trust signal — someone set up a public identity with this address.

4.2 DNSBL blacklist check. Queries the domain across 50 categorized DNSBL zones: Spamhaus (SBL/XBL/PBL), SpamCop, SURBL, URIBL, SORBS, Barracuda BRBL, UCEProtect, DroneBL, and many more. Includes domain-based lists and IP-based lists. A single listing isn't a death sentence; multiple listings are.

4.3 Domain age via RDAP. Registration date, expiration, registrar, DNSSEC status, nameservers. Domains under 30 days are high-risk; under a year, elevated. Pulled from the registry, not WHOIS — RDAP is the modern replacement and returns structured JSON.

4.4 HIBP breach check. Have I Been Pwned database lookup. Compromised addresses are more likely to be abandoned or used by spammers leveraging credential dumps.

4.5 DKIM record check. Probes 15 common DKIM selectors (google, default, selector1, s1, mail, k1, etc.) in parallel. Returns key type (RSA / Ed25519) and estimated key size. DKIM presence indicates the domain signs outbound email — a strong legitimacy signal.

4.6 Infrastructure analysis. Evaluates 6 email-authentication standards in one composite score:

SPF record presence + syntax
DKIM key availability
DMARC policy strength (none / quarantine / reject)
MTA-STS for transport security
BIMI for verified-sender brand indicators
TLS-RPT for TLS reporting

Domains with the full stack score highest.

4.7 MX server reputation. Reverse-DNS (PTR) and IP-DNSBL on the MX server itself. Servers without PTR records or with blacklisted IPs indicate lower-quality infrastructure.

Stage 5 — Scoring & classification (4 checks)

The last stage rolls everything up.

5.1 Spam-trap heuristic scoring. 12 weighted signals:

Domain age (younger = more suspicious)
Role-based address
No Gravatar
No SMTP deliverability
Disposable domain
DNSBL listing
Catch-all server
Email-pattern entropy
MX server reputation
Local-part entropy
Email-pattern type
MX IP blacklist status

Plus classification of the trap type: Pristine (ISP-created, never used by a real person), Recycled (formerly active, repurposed after abandonment), or Typo (misspelling of a legitimate domain). Each comes with a confidence score.

5.2 Domain trust score. A 0–100 composite: age (25 pts) + infrastructure (25 pts) + reputation (25 pts) + trust signals like DNSSEC and registrar lock (25 pts). Maps to five trust levels: Trusted / Positive / Neutral / Suspicious / Malicious.

5.3 Deliverability score. All preceding signals roll into a single 0–100 score weighing SMTP deliverability, infrastructure quality, spam-trap probability, and address characteristics. The model gets one actionable number instead of a dump of 21 booleans.

5.4 Reachability classification. Score maps to Safe (80–100, high confidence inbox) / Risky (40–79, may bounce or land in spam) / Invalid (1–39, almost certain bounce) / Unknown (0, couldn't be determined due to greylisting / catch-all / timeout).

Why MCP, not "another dashboard"?

Email deliverability is one of those problems where the right answer needs 6–8 API calls in sequence, not one call.

You ask "is this list safe to send to?" and the right answer involves: verify each email, then for each invalid → check if the domain is disposable, for each catch-all → check sender reputation, for each unknown → DNSBL the MX, then compute aggregate spam-trap probability for the whole list, then the recommendation.

A dashboard makes you click through that. The model orchestrates it as tool calls — and explains the verdict in plain English at the end.

That's why I exposed it as MCP rather than just a REST API + dashboard. The API is also there, but the MCP layer is what makes it agent-ready.

The 12 MCP tools map to the pipeline:

deliveriq_verify_email — runs all 5 stages on a single address
deliveriq_batch_verify — same, async, up to 100K addresses per job
deliveriq_blacklist_check — Stage 4.2 only
deliveriq_infrastructure_check — Stage 4.6 only
deliveriq_spam_trap_analysis — Stage 5.1 only
deliveriq_domain_intel — Stages 4 + 5.2 (composite)
deliveriq_find_email — pattern-based discovery
deliveriq_org_intel — cached organization patterns
(+ batch status, batch download, list jobs, check credits)

When Claude is asked "audit this list before we send", it composes calls across these tools rather than stuffing 21 questions into a single prompt.

Install

# Add to ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "deliveriq": {
      "command": "npx",
      "args": ["-y", "@deliveriq/mcp"],
      "env": { "DELIVERIQ_API_KEY": "lc_your_key" }
    }
  }
}

Free tier with no credit card at https://min8t.com/deliveriq.

Closing thoughts

Two things I learned building this:

SMTP catch-all servers are why "valid email" is unprovable. A server that returns 250 OK to every RCPT TO is correct from a protocol standpoint — RFC 5321 doesn't require accuracy. So you can never be 100% certain hello@catch-all-domain.com reaches a real person. The best you can do is detect the catch-all behavior and weight it accordingly. Stage 5's "Risky" category is mostly catch-all results.

MCP is genuinely better than a dashboard for this workflow. Composing 6–8 tools in sequence to debug "why isn't this email getting through?" is the kind of agent-task that's incredibly tedious in a dashboard but feels natural when an LLM is driving it.

What MCP tools are you missing for email or deliverability work? Curious what others would add to a pipeline like this.