外发邮件服务器：提升邮件送达率的指南

您发送了一封重要的营销邮件。它可能是一次产品更新、招聘跟进、捐赠者公告或销售序列。您点击发送，看着进度条走完，随后不确定感便随之而来。

邮件送达了吗？它们是进入了收件箱，还是被推入了垃圾邮件文件夹，亦或是被延迟或在送达前就被拒收了？

这种焦虑通常会被归咎于文案、主题行或列表质量。这些固然重要。但幕后还有一个许多企业用户在出问题之前从未考虑过的环节：外发邮件服务器。

如果您使用 Gmail、Outlook、Apple Mail、CRM、网站表单或邮件合并工具，您的邮件仍然需要一个系统来接收、验证、路由并将其移交给收件人的邮件服务提供商。如果该设置有误，即使是写得再完美的邮件也可能消失不见。

在您研究该领域的工具之前，请注意一点。Mail Merge for Gmail 是一个描述性很强的产品名称，因此很容易将其与其他 Gmail 邮件合并工具混淆。如果您在网上查看信息，请仔细确认该页面是指该特定产品，而不是名称相似的竞争对手。

为什么您的邮件会丢失

一位营销经理在周一早上发送了一份客户公告。到了午餐时间，回复率低于预期。到了下午，一些客户表示他们从未收到邮件。有人检查了垃圾邮件。另一个人转发了退信通知的截图。突然间，原本看起来像是参与度的问题变成了送达问题。

这通常就是外发邮件服务器介入故事的地方。

您的外发服务器是负责接收您编写的邮件并尝试将其传递给收件人邮件提供商的系统。如果服务器配置错误、不受信任、被屏蔽或缺少关键的身份验证信号，接收方就会产生怀疑。这种怀疑通常表现为被归入垃圾邮件、消息被拒收或静默过滤。

令人困惑的部分

大多数用户认为“我从 Gmail 发送”或“我从邮件应用发送”就是全部事实。事实并非如此。您的应用只是前端。实际的移交是通过服务器基础设施完成的。

一个简单的理解方式如下：

• 您的收件箱应用是写字台。
• 外发服务器是邮局柜台。
• 接收方提供商决定是否接受、检查或拒绝邮件。

如果邮局柜台无法证明您的身份、使用了错误的路线或看起来很可疑，您的邮件就无法顺利送达。

实用规则： 如果邮件在没有明确错误的情况下消失，不要从重写邮件开始。请从检查发送路径开始。

这就是为什么送达率工作通常从技术信任开始，而不是从创意修改开始。您的域名声誉、身份验证记录和服务器设置都会影响提供商是将您的邮件视为合法的商业通信还是潜在的欺骗行为。如果您想了解有关该信任层的入门知识，这篇关于 email sender reputation 的指南非常值得一读。

这在现实生活中意味着什么

当人们谈论“邮件送达率”时，他们通常指的是一系列决策：

1. 接收服务器能否连接到您的发送服务器？
2. 您的服务器看起来合法吗？
3. 您的域名是否与其身份验证记录匹配？
4. 内容看起来是否足够安全以至于可以接受？

外发邮件服务器位于该链条的起点附近。如果设置得好，后续的一切都会变得更容易。如果设置得很糟糕，您的营销活动从一开始就处于劣势。

什么是外发邮件服务器

将外发邮件服务器视为您邮件的数字邮局。您在 Gmail、Outlook、Apple Mail 或其他应用中编写邮件，但该应用仍然需要一个受信任的发送系统将邮件发送到更广阔的互联网中。

该发送系统遵循 SMTP，即 简单邮件传输协议 (Simple Mail Transfer Protocol) 的缩写。根据 Mailtrap’s explanation of email servers，外发邮件服务器依赖 SMTP，其中邮件服务器之间的通信主要通过 TCP 25 端口进行，而经过身份验证的客户端提交则使用 587 端口或 465 端口，通过 TLS 加密确保安全传输。

一张图表会有所帮助：

五步旅程

点击发送后会发生以下情况：

1. 您创建邮件
   您的邮件应用打包了主题行、正文、收件人和附件。

2. 您的应用连接到外发服务器
   这是第一次移交。您的设备或软件将邮件提交给发送服务器。

3. 服务器检查基础信息
   系统验证邮件格式是否正确并准备好进行传输。

4. 服务器找到收件人的提供商
   它会查找该域名的邮件应发送到何处，并将邮件向外路由。

5. 接收方评估邮件
   收件人的提供商决定是否接受、过滤、隔离或拒绝它。

如果您更喜欢视频，这里有一个简短的演示：

幕后发生的两个工作

发送路径通常涉及两个听起来很技术化但很容易理解的角色。

MSA 处理提交

邮件提交代理 (Mail Submission Agent)，即 MSA，是第一个检查点。它接受来自用户或应用程序的邮件。在此阶段进行初步验证。在邮件被传递之前，系统会检查格式和附件的完整性。

您可以将 MSA 想象成邮局柜台的职员。它在包裹进入邮件流之前确保其标签正确。

MTA 处理传递

邮件传输代理 (Mail Transfer Agent)，即 MTA，是将邮件路由到收件人邮件系统的部分。它与其他邮件服务器通信并尝试完成移交。

这更像是柜台后面的配送网络。卡车、路线、移交和目的地分类都在这里进行。

如果发送域名的 SPF、DKIM 或 DMARC 设置不匹配，接收系统可能会在任何人看到邮件之前就拒绝它。

为什么端口很重要

许多非技术用户经常发现自己陷入困境。他们听到“SMTP 使用 25 端口”，并认为这是他们应该始终使用的设置。实际上，客户端发送通常不是这样工作的。

• 25 端口 主要用于服务器到服务器的中继
• 587 端口 通常用于经过身份验证的客户端提交
• 465 端口 也用于许多设置中的安全提交

如果您要在邮件应用、插件或商业软件中输入外发邮件设置，您通常是在处理流程的客户端提交部分，而不是服务器中继层。

外发邮件服务器的类型

并非所有的外发邮件服务器都是为同一项工作而构建的。小型企业通常会遇到三种选择。使用邮件提供商的默认服务器、设置自己的服务器，或通过专用的 SMTP 中继服务发送。

正确的选择取决于您发送的内容、您需要的控制程度，以及您的团队是否能够管理送达率风险。

提供商服务器

这是最熟悉的选项。如果您的公司使用 Gmail 或 Microsoft 365，您已经在通过提供商管理的发送环境进行发送。这意味着基础设施、安全性和服务器维护都由他们为您处理。

对于大多数商业用户来说，这是最简单的路径，因为：

• 设置更轻松。您使用提供商的标准 SMTP 设置。
• 信任度更强。大型提供商运营着成熟的发送基础设施。
• 维护成本更低。您的团队无需管理邮件服务器。

这通常最适合日常商业通信、个性化外联以及从工作账户进行的适度营销活动发送。

自托管服务器

运行您自己的 SMTP 服务器听起来很有吸引力，因为它感觉像是完全控制。实际上，它通常会带来送达率方面的麻烦。

经过验证的数据表明，来自住宅 IP 或未配置 VPS 的自托管 SMTP 中继会被迅速列入黑名单，80% 的此类服务器无法通过基本的 PTR 记录检查，而使用具有正确对齐方式的经过身份验证的第三方 SMTP 服务可获得 95% 以上的送达率。

这种差距很重要，因为收件箱提供商并不关心您是否“拥有”服务器，而更关心他们是否信任它。

为什么自托管对许多团队来说会失败

自托管设置可能会在多个方面崩溃：

• 声誉历史较差。全新的或低信任度的 IP 不会自动看起来可信。
• 缺少反向 DNS 和对齐。接收服务器期望技术身份检查能够匹配。
• 运营负担。必须有人监控身份验证、中继规则和滥用预防。

自托管的 SMTP 服务器仍然可以用于有限的应用程序邮件或内部使用。只是它很少是人们所期望的简单路径，尤其是对于营销活动而言。

拥有邮件服务器并不能保证对送达率的控制。接收方提供商仍然会做出最终的信任决定。

专用 SMTP 中继服务

第三类是专门为您可靠发送邮件的专业服务。这些工具专注于身份验证、声誉管理、送达可见性和政策合规性。

当您的团队需要的发送灵活性超过标准邮箱所能支持的范围，但又不想从头开始运营邮件基础设施时，这个选项是有意义的。

以下是简单的权衡：

选项	最适合	主要优势	主要风险
提供商服务器	日常商业邮件	简单且可信	提供商发送限制
自托管服务器	有特定用例的技术团队	完整的架构控制	声誉和拒收风险
专用 SMTP 中继	更高容量或运营发送	托管的送达率工具	增加平台复杂性

大多数小型企业应该怎么做

如果您是小型企业、初创公司、招聘团队或活动组织者，最安全的默认设置通常是使用邮件提供商附带的受信任服务器，除非您的发送量或工作流程明确需要专用中继。

这避免了常见的陷阱，即构建一个在技术上可行但在实际场景中表现不佳的发送设置。

常用配置设置和示例

当应用要求“外发邮件服务器设置”时，它要求的是连接到提供商 SMTP 服务所需的详细信息。这些字段看起来可能令人望而生畏，但每一个都有其明确的目的。

根据 Heimdal’s Gmail SMTP configuration guide，企业级云 SMTP 服务（如 Gmail）使用 smtp.gmail.com，端口为 465 (SSL) 或 587 (TLS)，正确的 SSL/TLS 配置通过加密传输提高了送达率。

每个字段的含义

服务器名称

这是外发邮件服务器的地址。它告诉您的应用将邮件发送到哪里进行提交。

对于 Gmail，它是 smtp.gmail.com。

端口

端口是您的应用用于连接的特定门户。在这里，许多设置都会出错。

对于 Gmail，常见的选择是：

• 465（用于 SSL）
• 587（用于 TLS）

身份验证

这意味着您的应用在发送之前必须使用有效的电子邮件账户登录。这可以防止您的设备或网站表现得像一个开放中继。

SSL 或 TLS

这些安全层在提交邮件时对连接进行加密。通俗地说，它们有助于防止拦截并减少发送过程中的信任问题。

常用外发邮件服务器设置

提供商	SMTP 服务器	端口	需要 SSL/TLS	需要身份验证
Gmail / Google Workspace	smtp.gmail.com	465 或 587	是	是
Microsoft 365 / Outlook.com	使用提供商发布的 SMTP 服务器	通常为提供商文档中的安全提交设置	是	是
Apple iCloud Mail	使用提供商发布的 SMTP 服务器	通常为提供商文档中的安全提交设置	是	是

由于提供商特定的详细信息可能会发生变化，请务必在您正在配置的邮箱账户文档中确认确切的服务器名称和接受的提交方法。

一个通俗易懂的示例

假设您正在将网站表单或桌面邮件客户端连接到 Gmail 账户。

您通常会输入：

• SMTP 服务器： smtp.gmail.com
• 用户名： 您的完整 Gmail 地址
• 密码： 您的账户密码或特定于应用的登录方法（取决于账户安全性）
• 端口： 587 或 465
• 加密： TLS 或 SSL

如果应用同时为您提供 SSL 和 TLS 选项，请将端口与提供商支持的安全方法匹配。

最常见的错误不是服务器名称，而是选择了错误的端口和安全组合。

快速设置检查

在责怪您的内容之前，请确认以下基础知识：

• 服务器与提供商匹配。不要将 Gmail 凭据与另一个提供商的 SMTP 主机混合使用。
• 端口与加密类型匹配。不匹配通常会导致连接失败。
• 身份验证已开启。大多数提供商不会中继来自未经身份验证的客户端的邮件。
• 用户名完整。许多服务要求完整的电子邮件地址，而不仅仅是 @ 符号之前的部分。

这四项检查解决了许多“无法发送”的问题。

确保您的发送以获得更好的送达率

如果 SMTP 是运货卡车，身份验证就是装货码头的身份检查。没有它，接收提供商就必须猜测您的邮件是否合法。他们不喜欢猜测。

这就是为什么 SPF、DKIM 和 DMARC 如此重要。它们共同构成了您邮件的数字护照系统。

将其视为护照系统

接收邮件提供商希望回答三个问题：

1. 该服务器是否被允许为该域名发送邮件？
2. 邮件在传输过程中是否被篡改？
3. 如果检查失败，我们该怎么办？

这些记录有助于回答这些问题。

SPF 是回信地址检查

SPF 告诉接收方哪些服务器被授权代表您的域名发送邮件。

如果您的域名声明只有某些发件人是有效的，而您的邮件来自其他地方，这种不匹配就会引起怀疑。SPF 就像检查信封上的回信地址是否属于经批准的运输地点。

DKIM 是防篡改密封

DKIM 添加了一个签名，有助于证明邮件在传输过程中没有被更改，并且它确实来自经过批准的发件人。

它类似于文档上的火漆印。如果密封验证通过，收件人可以更自信地信任邮件的完整性。

DMARC 是海关政策

DMARC 告诉接收提供商在 SPF 或 DKIM 检查失败时该怎么做。根据现行政策，这可能意味着监控、隔离或拒绝可疑邮件。

这是将系统联系在一起的规则手册。

要深入了解这些检查在实践中是如何工作的，请阅读这篇关于 email authentication 的指南。

为什么这会影响收件箱的位置

身份验证不仅仅是一个安全复选框。它直接塑造了信任。

当您的域名和发送系统正确对齐时：

• 接收提供商看到一致的身份
• 欺骗行为更难实现
• 垃圾邮件过滤器怀疑邮件的理由更少

当它们不对齐时，即使是合法的营销活动也可能被标记。

人们忘记的其他两个部分

提交过程中的加密

TLS 很重要，因为它保护了您的应用与外发服务器之间的连接。这并不能神奇地保证进入收件箱，但它支持更可信的发送路径。

发送节奏和提供商限制

即使是经过良好身份验证的账户，如果发送过于激进，也会遇到麻烦。提供商期望看到正常的模式。如果您的发送行为突然看起来有风险，信任度就会下降。

原生的 Gmail 邮件合并功能也有其自身的吞吐量限制。根据 GMass’s analysis of Gmail’s built-in mail merge，原生 Gmail 邮件合并将外发容量限制在 账户每日发送总限额的 75% 左右。

安全记录证明身份。发送行为证明判断。两者缺一不可。

邮件合并工具如何使用外发服务器

许多人认为邮件合并工具是通过某个单独的神秘服务器发送的。在许多基于 Gmail 的工作流程中，情况并非如此。

相反，该工具使用您现有的 Google 账户发送路径。这意味着幕后的外发服务器与您已经使用的 Gmail 或 Google Workspace 账户绑定，而不是您必须自己管理的陌生独立服务器。

这很重要，因为邮件保留了您既定发件人身份的背景。对于商业用户来说，这通常比尝试从头开始为日常外联构建自定义 SMTP 设置要好得多。

实际的好处

假设一位人力资源经理从 Google Workspace 账户发送面试跟进邮件。或者一位社区经理通过 Gmail 发送活动提醒。邮件合并工具可以帮助个性化和组织这些邮件，但信任层仍然来自底层的账户和域名设置。

这简化了事情：

• 无需配置单独的服务器
• 无需从零开始建立额外的中继声誉
• 无需维护邮件基础设施

权衡之处在于发送量仍然受 Google 规则的约束。经过验证的数据表明，基于 Gmail 的邮件合并工具的外发邮件服务器受 Google 每日限额的约束，即 标准个人账户每天 1,500 名收件人，高级 Google Workspace 账户每天 2,000 名收件人，正如这篇 community discussion of Gmail mail merge limits 中所讨论的那样。

关键要点

邮件合并工具可以使发送更高效、更个性化且更易于跟踪。但它们并没有消除基本原理。您的结果仍然取决于您的账户声誉、身份验证设置的质量，以及您的发送量是否保持在提供商预期的范围内。

发送问题故障排除清单

当发送中断时，常见的做法是直接跳到重写邮件。这通常是错误的初步举措。从症状开始，然后将其与可能的服务器级原因相匹配。

如果您收到连接被拒绝

首先要检查的是端口。

经过验证的数据表明，端口 25 与 587 的混淆导致了 60% 的非技术用户外发 SMTP 失败，因为 25 端口通常被 ISP 屏蔽，而现代 ESP 要求使用带有 STARTTLS 的 587 端口进行经过身份验证的提交。

尝试这个快速清单：

• 检查端口设置。如果您的应用正在使用 25 端口进行客户端提交，请在提供商支持的情况下切换到 587。
• 将安全性与端口匹配。使用提供商在该端口上期望的加密方法。
• 确认您正在配置提交，而不是中继。大多数商业应用需要经过身份验证的提交设置。

如果您看到身份验证失败

这通常意味着应用无法证明它有权通过该账户发送邮件。

查看以下项目：

• 验证用户名。如果提供商要求，请使用完整的电子邮件地址。
• 重新检查密码方法。某些提供商需要特定的应用登录流程。
• 确保身份验证已启用。如果应用有 SMTP 身份验证的复选框，通常应该开启。

如果邮件被拒绝为垃圾邮件

被拒收的邮件通常指向信任信号，而不仅仅是措辞。

按此顺序操作：

1. 检查 SPF、DKIM 和 DMARC 对齐情况
2. 确认发件人域名与您的发送设置匹配
3. 回顾您最近的发送行为

如果垃圾邮件归类已成为一个反复出现的问题，这篇关于 how to prevent email from going to spam 的指南是实用的下一步。

如果您达到发送限制

这不是服务器错误。这通常是提供商的政策限制。

此时，您的选择是运营层面的，而不是技术层面的：

• 减少每日发送量
• 在经批准的商业工作流程中拆分发送
• 选择适合您用例的工具和平台

如果您的团队正在决定专用平台是否更适合大型营销活动，这篇帮助您 compare top email marketing platforms 的综述可以帮助您权衡利弊。

从发送路径开始，而不是从邮件文案开始。大多数送达失败都会在配置中留下线索。

---

如果您想通过现有的 Google 账户发送个性化营销活动，而无需自己管理 SMTP 基础设施，Mail Merge for Gmail 就是为该工作流程而构建的。它允许团队使用 Google Sheets 数据从 Gmail 发送自定义外联邮件、跟踪打开和点击、管理退订，并让报告在您的团队已经使用的电子表格中保持可见。