2026 年的邮件设计是一门奇特的学科。你面对的是一个在数十种邮件客户端中渲染效果各异的媒介——屏幕尺寸从智能手表到超宽显示器不等，还要兼顾亮色和暗色模式，以及种种让 Web 开发者头疼不已的技术限制。然而，表现最佳的邮件往往是最简单的那些。
本章涵盖让你的邮件正确显示、快速加载并稳定转化的技术基础。
移动优先设计
目前超过 60% 的邮件在移动设备上打开。这一数字多年来持续攀升，且不会回头。更关键的是，64% 的移动用户会删除在手机上显示不佳的邮件。这里说的不是"不够完美"，而是"根本无法使用"。
移动优先意味着先针对最小屏幕进行设计，再向上扩展。
单列布局是最安全、最有效的方案。 在桌面上看起来出色的多列设计在移动端往往会以不可预期的方式折叠，经常出现顺序错乱或横向滚动的问题。一个具有适当尺寸文字、图片和按钮的单列布局可以在任何地方正常运行。
将邮件宽度保持在 600 到 640 像素之间。 这是在最广泛邮件客户端范围内均能正常工作的标准。超过 640px 的宽度会在较小屏幕和带有侧边栏面板的邮件客户端中引发横向滚动风险。
触控友好的按钮至少应为 44x44 像素。 这是 Apple 人机界面指南中对最小点击目标的规定，我实际上建议稍微大一点，达到 46x46 像素，以应对精度较低的点击。没有什么比一个太小而难以准确点击的按钮更能快速扼杀移动端邮件参与度。
iPhone 上的字体大小应至少为 13px。 iOS 上任何小于 13px 的内容都会触发自动缩放，破坏你的布局。正文使用 14-16px，标题使用 20-22px。在移动端，更大通常总是更好。
主题行应保持在 30 个字符以内，以保证移动端可见性。 大多数移动邮件客户端会在 30 到 40 个字符之间截断主题行，具体取决于设备以及是否显示预览文字。将重要词汇前置。
使用媒体查询进行移动端优化图片处理。 向移动设备提供较小的图片文件，既可提升加载速度，也可减少流量消耗。一张在 WiFi 下 1 秒加载完毕的图片，在移动网络较差时可能需要 5 秒，而你的读者不会等待。
图片文件大小比大多数营销人员意识到的更重要。 单张图片保持在 200KB 以下，邮件总体积在 800KB 以下。上传前压缩所有图片。使用 TinyPNG 或 Squoosh 进行无损压缩。许多 ESP 会在发送时即时调整图片大小，但它们不一定会进行足够积极的压缩。
将 Web 安全字体作为主要字体栈。 邮件中的自定义字体支持不一致。Arial、Helvetica、Georgia 和 Verdana 在任何地方都能可靠渲染。你可以将自定义 Web 字体设为首选，并在不支持的客户端中回退到 Web 安全字体，但请注意，大多数读者看到的是回退字体。设计时应以回退字体为基准，而非自定义字体。
在实际设备上预览邮件，而不仅仅是在浏览器中。 桌面浏览器预览具有误导性。在 Chrome 预览中看起来完美的邮件，可能在 iPhone SE 上出现文字重叠，或在 Android 版 Gmail 应用中出现图片裁切。使用 Litmus、Email on Acid，或者至少发送测试邮件给自己，在发送前在手机上检查一遍。
视网膜和高 DPI 显示屏需要 2x 图片。 如果你的邮件列宽为 600px，而你使用的是 600px 宽的图片，在视网膜屏（即大多数现代手机和笔记本电脑）上会显得模糊。以显示尺寸的 2 倍导出图片（600px 列对应 1200px 图片），并在 HTML 中将宽度设置为显示尺寸。文件会更大，因此压缩变得更加重要。
邮件客户端兼容性
以下是关于邮件开发令人不舒服的真相：2026 年，你仍在用表格构建布局。当 Web 世界已转向 CSS Grid 和 Flexbox，邮件仍然依赖 HTML 表格进行布局。
为什么？因为 Microsoft Outlook 使用 Word 的渲染引擎（是的，就是那个文字处理软件）来显示 HTML 邮件。而 Outlook 的市场份额——尤其是在 B2B 领域——大到无法忽视。表格在 Word 引擎中渲染一致，现代 CSS 则不然。
使用内联 CSS。 大多数邮件客户端会去掉外部样式表，许多还会去掉 <head> 中的样式。确保样式生效的唯一可靠方式是将其内联到每个元素上。所有正规的邮件构建工具在导出时都会自动处理这一点。
使用媒体查询的响应式设计 在大多数现代邮件客户端中有效：Apple Mail、iOS Mail、Gmail 应用、Outlook 移动版、Yahoo。Gmail 的桌面 Web 客户端在技术上确实支持媒体查询，但由于邮件显示在较小的预览窗口而非完整视口中，查询往往不会触发。大多数 Webmail 客户端也是如此，不过少数使用 iframe 显示邮件的客户端会触发媒体查询。移动优先在这里有帮助，因为这些媒体查询会被激活。为了更广泛的兼容性，混合设计是你的安全网。
混合设计（也称海绵设计）是你的备选方案。 它使用流式布局、基于百分比的宽度和条件注释来创建不依赖媒体查询即可适应屏幕尺寸的邮件。可以使用或不使用表格来实现。Mark Robbins 通常建议使用带有幽灵表格的 div，这样可以避免表格带来的许多连锁问题。由于底层结构默认具有弹性，邮件在任何宽度下都能良好显示。
Mark Robbins（现任 Customer.io 邮件体验开发者倡导者）开创了仅使用 CSS 的邮件技术，在不使用 JavaScript（所有邮件客户端均屏蔽 JavaScript）的情况下拓展了可能性的边界。他在仅使用 CSS 的交互组件、无障碍访问改进和渐进增强方面的工作大大推进了该领域的发展。如果你在技术层面构建邮件，请研究他的作品。
需要测试的常见邮件客户端渲染差异：
Outlook 桌面版（2019/2021/365）使用 Word 的渲染引擎，这意味着不支持 CSS 背景图片、内边距控制有限以及表格间距不可预测。VML（矢量标记语言）传统上被推荐用于 Outlook 中的背景图片，但 Mark Robbins 指出 VML 会造成严重的无障碍问题，建议避免使用。考虑为 Outlook 使用纯色回退背景颜色。
Gmail 网页版会去掉 <head> 中超过一定大小阈值（约 16KB，从之前约 8,192 字符的限制提升）的所有样式。如果你的 CSS 较为复杂，某些样式会被悄然删除。虽然 Gmail 在技术上支持媒体查询，但预览窗口大小意味着它们在 Web 客户端中很少被激活，这正是混合设计重要性所在。
Apple Mail 是合规性最好的邮件客户端，几乎支持所有功能，包括媒体查询、CSS 动画和 @supports。这是最理想的开发客户端，但不要因此误以为其他客户端也会有同样的表现。
Yahoo Mail 和 AOL 近年来有了显著改善，但在媒体查询支持和外边距处理方面仍有一些特殊之处。务必进行测试。
邮件设计工具
邮件设计的工具生态系统已相当成熟。以下是我在 2026 年的推荐，按使用场景细分。
| 工具 | 类型 | 最适合 | 核心特性 |
|---|---|---|---|
| Beefree (BEE) | 无代码构建器 | 营销团队 | 拖放操作、保存模块 |
| Stripo | 无代码 + 代码 | 需要 AMP 的团队 | AMP for Email、1400+ 模板 |
| Chamaileon | 协作式 | 企业团队 | 品牌管控、审批工作流 |
| Litmus | 测试 + 构建 | 注重 QA 的团队 | 90+ 邮件客户端预览 |
| Email on Acid | 测试 | 预算有限的团队 | 客户端渲染 + 垃圾邮件测试 |
| MJML | 代码框架 | 开发者 | 响应式邮件标记语言 |
| Maizzle | 代码框架 | Tailwind CSS 开发者 | 邮件专用 Tailwind、构建管道 |
| React Email | 代码框架 | React 开发者 | 基于组件、npm 生态系统 |
| Parcel | 代码 IDE | 邮件开发者 | 实时预览、CSS 支持提示 |
| Figma to Email | 工作流 | 设计团队 | 在 Figma 中设计，导出为 HTML |
让我结合更多背景信息逐一介绍。
面向营销团队的无代码构建器：
Beefree（前身为 BEE）是我对无需编码即可快速构建邮件的团队的首要推荐。拖放界面确实好用，保存模块功能让你可以构建可复用组件库。Stripo 是需要 AMP for Email 支持或希望访问大量模板库（1400+ 模板）的最佳选择。Chamaileon 专为需要在邮件创建流程中内置品牌管控和审批工作流的企业团队打造。
测试平台：
Litmus 仍是黄金标准，提供超过 90 种邮件客户端和设备组合的预览。价格不菲，但如果你向多样化受众发送邮件（你很可能是这样），了解邮件在 Windows 上的 Outlook 2019、macOS 上的 Apple Mail 与 Android 上的 Gmail 中各自的渲染效果至关重要。Email on Acid 以更低的价格提供类似的渲染预览以及垃圾邮件测试。对于预算有限的团队来说，这是一个强力替代方案。
面向开发者的代码框架：
MJML 是一种可编译为响应式 HTML 邮件的标记语言。你编写简洁的语义化标记，MJML 处理繁琐的基于表格的输出。这是最受欢迎的邮件开发者框架。Maizzle 将 Tailwind CSS 引入邮件开发，提供处理内联、清除未使用 CSS 并生成生产就绪 HTML 的构建管道。React Email 让你使用 npm 生态系统中的 React 组件构建邮件模板。如果你的团队已经以组件化方式思考，这是一个自然的选择。Parcel（非 Web 打包工具，而是邮件 IDE）在编码时提供实时预览和 CSS 支持提示。
设计到代码的工作流：
Figma to Email 工作流越来越普遍。设计团队使用组件库在 Figma 中创建邮件模板，然后通过插件导出为 HTML，或将设计交给在 MJML 或 Maizzle 中实现的开发者。
AI 驱动的邮件设计
设计工具领域在 2026 年初发生了重大变化，AI 驱动的设计不再只是理论。以下是目前实际可用的功能。
Figma MCP + Claude Code（"代码到画布"） 是最重要的进展。2026 年 2 月宣布，Figma 的 MCP 集成在设计文件和 AI 编码工具之间建立了双向连接。Claude 从语义层面审查 Figma 设计——理解设计系统、组件层次结构、间距标记和意图，而不仅仅是像素。对于邮件，描述你想要的内容（"创建一个与我们品牌套件匹配的邮件主视觉区域，包含全宽图片、标题、副标题和 CTA 按钮"），即可获得遵循现有 Figma 设计系统的设计。结合 MJML 或 React Email，该工作流可以在几分钟而非几小时内从设计简报生成可用于生产的邮件模板。
Paper.design 是一个原生支持 HTML 和 CSS、配备 24 种工具、支持 MCP 的设计画布。与输出需要转换的矢量的 Figma 不同，Paper 直接使用邮件实际采用的媒介。与 Claude Code 和 Cursor 双向互通——AI 智能体可以检查画板、修改布局、编写 HTML 并更新样式。设计标记从 Figma 同步，真实 API 数据填充 UI，输出可转换为 React 或 Tailwind。免费套餐（每周 100 次 MCP 调用）和专业版（每月 $20，每周 100 万次调用）。对于希望在不离开 HTML 原生环境的情况下进行 AI 辅助设计的邮件设计师，Paper 省去了工作流中的整个转换步骤。
用于邮件开发的 Cursor 值得一提，因为它已成为事实上的 AI 编码环境，而邮件模板就是代码。使用 MJML 或 React Email 的设计师在 Cursor 中的迭代速度比在传统编辑器中快 10 倍。用自然语言描述你想要的修改，Cursor 编写代码，你预览结果。对于已将邮件开发纳入代码管理的团队（如上文框架部分所述，这是发展方向），Cursor 大大缩短了"我想要这个"和"已经实现"之间的反馈循环。
Nitrosend 的 Claude 设计工作流 让你完全通过自然语言设计邮件模板，可通过 Claude 中的 MCP 服务器或 Nitrosend 内置的 AI 聊天功能实现。"创建一个双列产品展示，页眉有我们的 Logo，三张带图片和价格的产品卡，以及一个绿色 CTA 按钮"可生成一个可通过对话迭代的渲染模板。对于没有设计资源的独立创业者和小团队，这完全消除了设计瓶颈。目前处于内测阶段。
其他值得关注的 AI 设计工具：
Mailmodo 提供端到端的 AI 邮件创作——描述你想要的邮件，它就会生成一封支持 AMP 的完整交互式邮件。EmailCanvasAI 根据文字提示生成邮件模板。Mailjet 的 AI 模板生成器根据简短描述创建起点设计。这些都是较早期的工具，但它们预示着一个方向：邮件设计正在从"可视化构建"转向"对话式描述"。
实用建议： 如果你的团队已经使用 Figma，探索 Figma MCP + Claude Code 工作流用于设计系统。如果你以开发者为主，使用 MJML 或 React Email 的 Cursor 是 AI 辅助邮件开发的最快路径。如果你是没有专职设计或开发资源的小团队，Nitrosend 或 Mailmodo 的 AI 设计方式可以完全消除瓶颈。如果你想在 AI 辅助下对 HTML 原生设计拥有最大控制权，Paper.design 值得评估。
无代码与编码模板
这不是非此即彼的选择，而是要将方法与使用场景相匹配。
无代码工具对于一次性活动的速度快 3 到 5 倍。 当你需要构建一封单次促销邮件时，拖放构建器可以在 30 分钟内完成，而不是 3 小时。使用 Beefree、Stripo 或你的 ESP 内置构建器。
编码模板更适合重复使用的自动化流程、版本控制和设计系统。 当你构建一个将向数千名订阅者发送数月或数年的欢迎序列时，投资一个经过精心编码的模板是值得的。编码模板可以存储在版本控制系统（Git）中，在拉取请求中审查，并在整个流程中系统性地更新。
大多数成熟的邮件计划两者都会使用。 自动化流程（欢迎邮件、购物车遗弃、购后邮件）使用编码模板，一次性活动（产品发布、季节性促销、公告）使用无代码工具。这种混合方式在关键处保证了一致性，在需要时提供了速度。
邮件模板设计系统
如果你发送的邮件类型超过几种，你就需要一个设计系统，而不仅仅是一个模板。
品牌标记 定义了常量：主色和辅色、字体栈、标准间距单位（8px、16px、24px、32px）、按钮的圆角半径以及任何其他视觉常量。将这些记录一次并在各处引用。
组件库 包含构建块：页眉（Logo、导航）、主视觉区域（图片、标题、CTA）、文本块（标题、正文、链接）、产品卡（图片、标题、价格、按钮）、CTA 按钮（主要、次要、文字链接）和页脚（社交链接、法律文本、退订）。每个组件都定义了响应式行为、暗色模式处理和无障碍要求。
布局模板 将组件组合为标准邮件类型：促销邮件、新闻通讯、事务性通知、欢迎邮件、购物车遗弃邮件。这些是你的起点，而非约束。
使用指南 告诉你的团队何时使用什么、需要包含多少文案、哪些组件是必需的（页脚、退订）还是可选的，以及关于图片、语气或 CTA 位置的任何品牌规则。
构建设计系统需要前期投入时间。对于典型的电子商务品牌，预计初始开发工作需要 40 到 60 小时。但这项投资很快就能得到回报。一旦系统就位，构建一封新邮件的时间将从 3 到 4 小时缩短到 30 到 60 分钟。而且每封发出的邮件都自动符合品牌规范并具备无障碍访问能力。
如果你是资源有限的小团队，无法构建完整的设计系统，可以从一个精心构建的主模板开始，涵盖你最常见的邮件类型（通常是促销邮件）。将其一次性构建好，包含暗色模式支持、无障碍功能和移动端优化。然后针对每次发送进行改编。这不是设计系统，但能解决 80% 的问题。
无障碍访问
多年来，Paul Airy 一直是邮件无障碍访问领域的主要倡导者，他的核心信息值得重申：无障碍邮件不仅是正确之举，它对所有人的表现都更好。
估计有 15% 到 20% 的人存在某种形式的残障，包括视觉障碍、运动障碍、认知差异以及情景性残障（如单手抱着孩子阅读邮件）。为无障碍访问设计意味着为所有这些人设计，而在此过程中，你也让其余 80% 的人获得了更好的体验。
邮件的 WCAG 2.1 要求：
普通文本的色彩对比度必须达到 4.5:1，大文本必须达到 3:1。使用对比度检查工具。在你的高端显示器上看起来没问题的内容，在阳光直射下的廉价屏幕上可能根本无法阅读。
所有图片必须有描述性的替代文字。不是"image1.jpg"或"banner"，而是描述图片显示的内容以及读者需要知道的内容。如果图片纯粹是装饰性的，使用空的 alt 属性（alt=""），让屏幕阅读器跳过它。
保持逻辑阅读顺序。屏幕阅读器遵循 HTML 源代码顺序，而非视觉布局。确保内容从上到下线性阅读时有意义。
在 HTML 元素上包含语言属性（lang="en"）和方向属性（dir="ltr"），以便屏幕阅读器使用正确的发音模型和文字方向。
链接仅凭文字应具有明确的目的。"点击这里"在脱离上下文时毫无意义。"下载 2026 年邮件基准报告"准确告诉读者链接的去向。
不要仅依靠颜色传递信息。如果价格以红色显示来表示促销，还需包含"促销价格"字样或对原价使用删除线。
使用可缩放文字。切勿设置用户偏好无法覆盖的像素字体大小。
确保键盘可导航。所有交互元素应可通过键盘访问和操作。
在布局表格上添加 role="presentation"，告知屏幕阅读器该表格用于布局而非数据。若无此属性，屏幕阅读器会尝试将布局解析为数据表格，造成混乱的体验。
44x44px 的最小触控目标 不仅是移动端最佳实践，也是无障碍要求。有运动障碍的用户需要足够大的目标尺寸。
无障碍访问不是一次完成的清单， 而是在每封邮件中持续维护的实践。在邮件质量保证流程中加入无障碍审查。每次发送前检查：每张图片都有替代文字吗？阅读顺序合理吗？所有按钮和链接都有足够的尺寸和对比度吗？如果你眯起眼睛只能看标题和链接文字，还能理解邮件的内容吗？如果其中任何一项的答案是否定的，在发送前修正它。
屏幕阅读器测试是黄金标准。 如果你真的想了解邮件的无障碍程度，用实际的屏幕阅读器进行测试。Mac 和 iOS 上的 VoiceOver、Windows 上的 NVDA 以及 Android 上的 TalkBack 都是免费的。听屏幕阅读器朗读你的邮件，会发现视觉检查永远无法发现的问题。目标是每季度至少在你最常用的模板上进行一次测试。
暗色模式
至少有 33% 的邮件收件人在暗色模式下查看邮件，而这一比例还在增长。暗色模式可能会对未针对此情况构建的邮件设计造成严重破坏。
各邮件客户端处理暗色模式的方式不同。有些会反转颜色，有些会交换背景，有些两者都做。结果可能是黑色文字在黑色背景上（不可见）、深蓝色链接在深灰色背景上（几乎不可见），或带有白色背景的 Logo 现在周围有一个刺眼的白色矩形。
在 Apple Mail、Gmail 和 Outlook 中测试暗色模式下的邮件。 这三者对暗色模式的处理方式各不相同，合在一起覆盖了大多数暗色模式用户。
为 Logo 使用透明 PNG。 白色背景上的 Logo 在白色邮件中看起来没问题。同样的 Logo 在暗色模式下会出现白色矩形边框。透明背景解决了这个问题。
避免纯白色背景。 邮件正文背景使用近白色（#F5F5F5 或类似颜色）。在暗色模式下，纯白（#FFFFFF）可能会造成刺目的闪光。近白色在两种模式下都更自然过渡，视觉上也更舒适。
在支持的地方使用 CSS 媒体查询 @media (prefers-color-scheme: dark)，提供明确的暗色模式样式。这让你可以控制邮件在暗色模式下的显示效果，而不是让邮件客户端自行猜测。Apple Mail 和 Outlook 支持良好。Gmail 忽略此属性并应用自己的暗色模式转换。
暗色模式设计实用技巧：
在具有白色或浅色背景的图片周围使用边框或细微阴影，防止它们在暗色模式下"悬浮"。在 Logo 周围添加品牌色细线 1px 边框作为安全措施。
对于文字颜色，在亮色模式下避免使用纯黑色（#000000）。改用深灰色（#333333 或 #222222）。在暗色模式下，邮件客户端经常将纯黑色反转为纯白色，看起来可能很刺眼。略微偏黑的文字反转后变为略微偏白，更易阅读。
在两种模式下测试你的 CTA 按钮。在白色背景上高度可见的按钮在深色背景上可能消失。考虑为按钮添加边框，使其无论背景颜色如何都保持可见。
如果你在内容区块中使用背景颜色（如高亮提示框或彩色横幅），这些颜色在暗色模式下可能会被更改或删除。始终确保即使背景颜色恢复为邮件客户端默认深色背景，你的内容也是可读的。
交互式邮件
邮件中的交互元素可以显著提升参与度。包含交互元素后，点击打开率平均提升 31.7%。
但邮件中的交互性有一个关键注意事项：各邮件客户端的支持差异极大。始终以渐进增强为设计原则，Jason Rodriguez 对此大力倡导。交互元素是支持客户端的额外奖励，不支持的客户端的回退方案仍应是一封功能完整、外观良好的邮件。
CSS 悬停效果支持广泛，能带来 5% 到 10% 的参与度提升。 简单的按钮悬停颜色变化、图片叠加层或下划线动画等。这些是低风险、高回报的添加项。
CSS 驱动的折叠面板支持度适中，可带来 10% 到 15% 的参与度提升。 它们非常适合内容丰富的邮件，如新闻通讯或产品比较，让读者只展开自己感兴趣的部分。在 Gmail 网页版和 Outlook 中不起作用，因此回退方案应显示所有内容展开的状态。
动态 GIF 获得普遍支持，能带来 5% 到 8% 的参与度提升。 每个邮件客户端都支持 GIF（Outlook 桌面部分版本除外，仅显示第一帧）。这是你可以使用的最安全的交互元素。产品演示、细微动画和视觉趣味都非常适合。
AMP for Email 提供最强大的交互性，参与度提升 20% 到 30%，支持轮播图、表单、折叠菜单甚至邮件内实时内容。但支持仅限于 Gmail 和 Yahoo，需要 Google 发件人注册，且采用率仍然较低。如果你的受众主要使用 Gmail 并且拥有开发资源，AMP 可以非常强大。对于大多数发件人来说，目前还不值得投入。
倒计时器 是促销邮件和限时优惠的常见交互元素。它们以服务器端生成的动态 GIF 形式提供实时倒计时显示。Sendtric 和 Mailmodo 等服务提供免费和付费的倒计时生成器。它们几乎在每个邮件客户端中都有效。重要注意事项：只在真实截止日期使用真实倒计时器。一个计时结束后悄悄延期的促销倒计时，会让订阅者开始忽略你的紧迫感提示。
嵌入式调查和投票 可以显著提升参与度，因为它们将邮件从广播变成了对话。Typeform 和 SurveyMonkey 等工具生成可嵌入的单题投票，在大多数邮件客户端中有效。对于不支持嵌入版本的客户端，回退是指向调查的链接。即使是新闻通讯中的单题投票，也能将点击率提升 15% 到 20%。
交互式邮件的黄金法则：始终先构建回退方案。 将邮件设计为没有任何交互元素都能正常工作。然后为支持的客户端叠加交互性。这样，每位订阅者都能收到功能完整的邮件，而拥有现代邮件客户端的用户则能获得额外体验。