The Spark Team
智能、聚焦、邮件。
超高效兼跨平台：专为静忧收件设计，专心聚焦重要事项。
定义
💡MTA-STS：一项确保您的邮件始终以安全方式传输的设置，通过一扇上锁且经过验证的连接，而不是偶尔溜过一扇大多数人从不会想到去检查的未上锁的门。
MTA-STS 为何存在
邮件其实并不一定要加密传输。它通常是加密的。但"通常"会留下一扇敞开的门。
邮件服务器会通过一种叫做 STARTTLS 的机制约定加密连接，基本上就是在开始通信前礼貌地请求锁上门。大多数情况下，双方都会同意。但这种约定并非强制。如果有人处于中间的网络位置（罕见，但并非不可能），就能说服两台服务器都不上锁，邮件便会以未加密的形式溜过去。
MTA-STS 堵住了这个漏洞。基本上，您的域名会立起一块牌子，写着：只能通过上锁的门把邮件投递给我们，绝无例外。无法验证这把锁？那么这封邮件根本无法送达。
这里有一点对您真正重要：您永远不会在 Gmail 或 Outlook 中点击这个设置。它是一项完全在幕后运行的设置，通常由管理公司邮件域名的人来处理（IT 部门、托管服务提供商或邮件管理员）。您并没有错过设置里的某个按钮。
它究竟做什么
您无需了解 DNS 就能明白这里的要点。幕后有两件事在发生，而且都与您无关。
首先，域名会发布一条说明（技术上是一个小文件），写着"始终要求上锁的连接"。其次，每台试图向那里投递邮件的服务器都必须先检查这条说明。无法确认这把锁是真的？那么这封邮件就会被扣留或标记。
这种严格程度有个名字：模式。测试模式只会观察并报告哪些邮件本会失败，但暂时不会拦截任何邮件。强制模式才是动真格的。如果在这里检查失败，那么邮件就不会送达。大多数域名都从测试模式开始，这是有充分理由的。如果直接跳到强制模式，您就有可能拦截来自尚未跟上的服务器的真实邮件。
到底谁需要为此操心
说实话？日常来说，几乎没有人。
如果您通过 Gmail、Outlook 或 Spark 在普通地址上收发邮件，已经有人替您处理好了这件事。您什么都不用做。
只有当您运营自己的邮件域名时，这才会成为您的问题——比如您是小企业主，或者您负责管理公司的 IT。这种情况下，MTA-STS 就是那种默默无闻、不起眼但值得花五分钟与托管服务提供商聊聊的设置。如果您的企业运行在 Google Workspace 或 Microsoft 365 上，这两个平台都提供了内置工具来检查并启用它。
简单来说，如何设置
如果您确实要管理一个域名，这里是要点，无需专业术语：
- 您的域名需要一个公开发布的小型设置文件，列出您的邮件服务器以及要求的严格程度
- 您在域名的 DNS 设置中添加一个指向该文件的简短指针
- 从测试模式开始，这样您就能在任何邮件被拦截之前看到哪些会出问题
- 一旦一切看起来正常，就切换到强制模式以获得真正的保护
- 每当您更换邮件服务提供商时都要更新它，否则您有可能拦截自己的邮件
把这件事交给已经在管理您域名的人（托管服务提供商、IT 人员或开发者）通常是明智之举。这不是一个周末就能搞定的项目，而且一旦出错，可能会退回真实邮件却不告诉您原因。
为什么值得拥有它
它堵住了一个真实的漏洞。罕见不代表不可能，而对于任何涉及客户数据或财务细节的事情，堵住这个漏洞都是值得的。
不过，它并不是您唯一的防线。 MTA-STS 保护的是邮件如何传输，而不是真正发送它的人是谁。您仍然需要 DKIM 和 DMARC 来确认发件人确实是他们所声称的身份。
始终要谨慎起步。测试模式的存在是有原因的，跳过它是一个善意的设置意外拦截真实客户邮件的最常见方式。
去问，别猜。如果您运营着一个企业域名，又不确定是否已设置好这项功能，那只需向托管您邮件的人问一个简单的问题，而不是让您自己去做一个研究项目。
能让服务提供商处理时就让他们处理。如果 Gmail 和 Outlook 已经在他们那端处理好了这件事，那这里确实没有什么需要您动手的。