Email Rendering Basics：一次搞懂 HTML Email 的限制與相容性

一、Email Rendering 是什麼？為什麼它跟瀏覽器差這麼多？

一般網頁的渲染邏輯很單純：瀏覽器解析 HTML、套用 CSS、執行 JavaScript（如需要），最後把畫面呈現出來。瀏覽器對標準的支援相對一致，更新速度也快，開發者可以依賴大量現代化特性。

但 Email 客戶端的目標不同。它必須在「安全」「可讀」「可預測」的前提下顯示內容，並避免信件成為惡意程式、釣魚或追蹤的載體。於是大多數 Email 客戶端採取非常嚴格的策略：

• 預設禁止或移除 JavaScript，避免互動程式碼或惡意注入。
• 限制 CSS 支援，尤其是外部 CSS、進階選擇器、動畫與定位。
• 對圖片、字體與外部資源採取保守策略，常見做法是先擋外部圖片，需用戶手動顯示。
• 各家使用不同渲染引擎：有些像瀏覽器，有些（特別是 Windows 的部分 Outlook）使用與 Word 類似的引擎，導致 CSS 行為更不一致。

所以做 HTML Email 的核心心法就是：用最穩、最傳統的方式完成「可讀、可點、可辨識」，而不是追求網頁級的華麗效果。

二、HTML Email 的基本限制：你該先接受哪些「不能做」？

1) 幾乎不能靠 JavaScript

在 Email 裡，JavaScript 基本上不會被允許執行。也就是說你不能期待：

• 點按後展開/收合的互動元件
• 動態載入內容或即時驗證
• 用 JS 改版面或切換深色模式
• 依裝置條件改寫 DOM

如果你需要互動，就把互動移到「點擊後開啟的落地頁」上。Email 本身最重要的工作，是把訊息說清楚並把使用者引導出去。

2) CSS 支援不一致，外部 CSS 更常被剝掉

在網頁開發，你可能習慣把 CSS 放在外部檔案或 <style> 裡，並用 class 做一致性的樣式管理。但 Email 世界常常不吃這套，尤其是：

• 外部 CSS（link）通常會被移除或無法載入。
• <style> 區塊在部分情境可能被削弱或被清理。
• 選擇器越複雜，越容易被忽略或產生不一致。
• 某些客戶端會改寫你的 CSS（尤其是深色模式或安全機制）。

因此最穩定的做法往往是：重要樣式用 inline style，也就是寫在每個元素的 style="" 上。這聽起來很原始，但在 Email 是非常常見且務實的策略。

3) 版型不要依賴現代排版（Flex/Grid/Position）

在 Email 裡，Flexbox、CSS Grid、固定定位、複雜的絕對定位都很可能在某些客戶端表現不穩。尤其當你遇到 Outlook 的某些版本，很多你以為理所當然的排版方式會失效。

所以你會看到大量 HTML Email 範本仍使用「表格（table）」來做版面分欄與對齊。這不是倒退，而是因為 table 在 Email 世界裡是最一致、最可預測的布局方式之一。

4) 安全性清理：某些標籤與屬性會被移除

Email 客戶端通常會做 HTML 清理（sanitization），移除被視為風險的元素或屬性。常見情況包括：

• 移除 script、iframe、object 等風險元素
• 對可疑的 URL、data URI、追蹤參數做限制
• 移除不被允許的 CSS 屬性或表現
• 改寫連結行為（例如自動加上安全跳轉或預覽）

你必須假設：信件內容會被「再加工」一次，而不是原封不動地呈現。

三、最常見的渲染地雷：為什麼你的信寄出去會走樣？

地雷 A：用 div 當主要布局、想用 Flex 做兩欄

在網頁上很自然，但在 Email 可能導致：兩欄變一欄、元素錯位、或間距被拉壞。建議改成 table-based 布局，或者用非常保守的方式做單欄設計，再用手機版的閱讀節奏去安排內容。

地雷 B：字體與行高在不同客戶端差很多

你指定的字體可能不存在，收件端會用替代字體。更麻煩的是行高、字距在不同引擎的計算方式不同，導致換行位置、段落間距看起來「怪怪的」。

實務上可以做的是：

• 使用安全字體（system fonts）與合理的 fallback（例如：font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Arial, "Noto Sans", sans-serif;）
• 避免靠精準的像素排版去對齊文字
• 用較保守的 line-height（例如 1.4～1.7）確保可讀性

地雷 C：按鈕用純 CSS 做成圓角、陰影、hover

Email 裡 hover 基本無效，陰影與圓角支援也不一致。最常見的問題是按鈕變成「一段有底色的文字」，或者圓角失效後變成突兀的方塊。

穩定做法是用 table + a 來做按鈕，並用 inline style 控制 padding、背景色、圓角（圓角盡量保守）。必要時在特定客戶端會有退化顯示，但至少仍然清楚可點。

地雷 D：圖片尺寸未固定或只用 CSS 控制

很多 Email 客戶端對圖片的縮放策略很不一樣。如果你只在 CSS 設定寬度，而沒有在 HTML 屬性設 width/height，可能導致圖片撐破版面或比例怪異。

建議：

• 在 <img> 上同時設定 width（必要時也加 height 或保持比例）
• 用 inline style 加上 display:block; 避免圖片底下莫名出現空隙
• 重要圖片提供清楚的 alt 文案，因為不少收件端預設擋圖

地雷 E：深色模式（Dark Mode）把你的顏色「改掉」

深色模式是近年最常造成「我明明設計好了，怎麼變得很醜」的來源。很多客戶端會自動反轉背景與文字顏色，導致：

• 白底卡片變灰、邊界線消失
• 品牌色被改寫，按鈕對比不足
• 圖片上的文字可讀性下降

對策是：盡量使用清楚的對比、避免把關鍵資訊做在圖片上、關鍵區塊用明確背景色與 padding 保護內容；同時在測試階段務必用深色模式檢查。

四、HTML Email 的版型策略：為什麼「表格」仍然是主流？

很多人看到 table 會覺得像回到十幾年前。但在 Email 世界，table 的價值是：一致性高、渲染可預測、對齊更穩。尤其你需要：

• 兩欄或三欄的穩定分割
• 精準控制 padding 與對齊
• 避免某些客戶端忽略你的 layout CSS

常見做法是「外層一個主 table 控制整體寬度（例如 600px）」，內層用 table row/column 做內容區塊。這樣在桌機顯示穩，在手機可以再用保守的方式堆疊內容。

同時也建議採取「單欄優先」的內容節奏：先把資訊寫清楚，再把 CTA 放在明顯位置。因為就算某些排版退化，單欄仍然可讀。

五、RWD 在 Email 裡怎麼做才不踩坑？

你在網頁上常用的 media query 在 Email 也能用，但支援程度不一。部分客戶端對 media query 支援很好，部分則非常有限。這意味著：你不能把「能不能讀」完全押注在 media query 上。

更穩的策略是：

• 主版型先做到「不靠 media query 也能讀」：字級適中、行距足夠、段落不要太長。
• 圖片寬度用最大寬度限制，避免手機撐破。
• 必要的兩欄內容，確保堆疊後順序合理（例如先文字再圖片，或先重點再細節）。
• CTA 按鈕在手機可點：高度、間距要夠，避免太靠近。

你可以把 RWD 當成「加分」，但不能當成「必須」。Email 的世界是以退化顯示為常態，設計要能優雅地退化。

六、圖片與資源載入：為什麼你的信看起來像「空的」？

許多客戶端會預設阻擋外部圖片，理由很直接：圖片可被用來追蹤開信、可載入不安全內容、也會浪費流量。這會導致：

• 你做的視覺主圖不顯示
• 用圖片做標題，結果標題整個消失
• 用圖片做按鈕，結果按鈕不見

所以在設計上要先假設「圖片可能不出現」。實務建議：

• 重要資訊用文字呈現，不要只放在圖片裡
• 圖片加上清楚的 alt 文案，至少讓人知道原本要看什麼
• 按鈕用 HTML/CSS 做，而不是整張按鈕圖片
• 圖片檔案大小控制合理，避免載入慢

如果你的品牌需要大量視覺，也可以讓第一屏就有「文字版重點 + 一個主視覺」，把資訊分散，避免擋圖時整封信變成一片空白。

七、字體、Emoji 與國際化：台灣使用者常遇到的細節

繁體中文信件常見的問題是字體 fallback。不同平台對中文字體的預設不同，導致同一封信在 macOS、Windows、iOS、Android 的字感不一致。你可以透過合理的字體堆疊，把「最可能存在」的字體放在前面，並確保最後至少落到通用 sans-serif。

另外，很多品牌會用 Emoji 增加親和感，但也要注意：

• 不同平台 Emoji 樣式不同，可能帶來語氣落差
• 不要用 Emoji 當作唯一的「狀態符號」，最好搭配文字
• 主旨與預覽文字（preheader）使用 Emoji 要節制，避免看起來像垃圾信

在台灣的商務信件或產品通知中，通常「簡潔、清楚、有重點」比過度可愛更能提升信任感。你可以在小地方加溫度，但不要讓可讀性下降。

八、連結、追蹤與安全：為什麼有些信會被丟垃圾桶？

即使你的排版做得再漂亮，如果信件被判定可疑，收件匣根本看不到。與渲染相關的安全因素包括：

• 連結看起來像釣魚（文字顯示與實際 URL 不一致）
• 短網址過多或跳轉過多
• 圖片全部來自外部且沒有文字內容
• 使用大量追蹤參數或可疑網域
• HTML 結構混亂、含有奇怪的內嵌元素

建議你把 Email 當成「信任產品」來設計：清楚的寄件人、明確的品牌識別、可辨識的落地頁網域、以及簡潔的內容結構。對收件端而言，內容越透明、越像正常溝通，越不容易被當作垃圾信。

如果你需要追蹤，請用合理的方式做：保持連結清楚、不要把所有內容都包進追蹤系統裡、也避免讓信件只剩圖片與追蹤像素。你追蹤的是成效，但你更需要的是到達率與信任。

九、實作對策：用「保守但穩」的方式做出高相容信件

如果你希望少踩坑，可以把 HTML Email 的設計哲學整理成幾個原則：

1. 單欄優先：先確保退化顯示仍可讀，再考慮兩欄與花樣。
2. 表格當布局骨架：用 table 控寬、控對齊、控 padding，讓各家渲染更一致。
3. 關鍵樣式用 inline：字級、顏色、行高、背景、padding，盡量寫在元素上。
4. 圖片可有可無：重要資訊不要只放在圖片上，alt 文字要寫好。
5. CTA 要像 CTA：按鈕清楚、對比足、可點範圍夠大，連結文字也要直觀。
6. 深色模式要測：不要假設顏色永遠不變，確保在深色模式仍可讀。
7. 內容結構乾淨：標題、段落、列表、分隔，讓閱讀節奏清楚。

很多成功的商業信件其實都不花俏：它們贏在資訊密度合理、閱讀成本低、行動指引清楚，並且在各種裝置上都「至少不會壞」。

十、測試方法：不要只在自己電腦上看一眼就上線

HTML Email 最容易出事的地方，是你只在一個環境預覽。你真正要面對的是多客戶端、多裝置、多模式（深色/淺色）、以及不同網路狀況。建議的測試流程可以是：

• 桌機：至少測 Gmail（網頁）、Outlook（如果目標族群偏企業）、以及任一主流瀏覽器收信介面。
• 手機：iOS Mail 與 Gmail App、Android Gmail 盡量都看一次。
• 深色模式：同一封信切換深色/淺色觀察對比與背景。
• 擋圖情境：想像圖片不顯示時，文字是否仍能讓人理解並行動。
• 連結檢查：每個 CTA、每個文字連結都點一次，避免跳錯頁或參數壞掉。

你不一定要做到「所有客戶端 100% 一樣」，那幾乎不可能。但你應該做到「核心資訊一致、可讀性一致、CTA 可用」。只要掌握這三點，你的 Email 就能穩定交付價值。

十一、常見問題：為什麼我照著網頁做，Email 還是怪？

結語：HTML Email 的成功，不在花俏，而在「穩定可讀」

當你理解 Email Rendering 的限制，你會發現：做出一封穩定的 HTML Email，其實更像工程品質管理，而不是純前端美術。你要面對的是多環境、強限制、強安全策略，以及不可控的改寫與退化顯示。

但好消息是：只要你用保守的布局、把重點資訊寫清楚、讓 CTA 明顯可點、並且做好跨裝置測試，你就能做出「在多數收件端都可靠」的信件。這種可靠感，才是讓使用者願意點擊、願意信任、願意下一次還打開你信件的關鍵。