如何从应用发送邮件（并进入收件箱）

要可靠地从应用发送邮件，请使用邮件发送服务商而不是自己的邮箱，使用您自己域名下的地址发送，并添加服务商提供的 DNS 记录，使 SPF、DKIM 和 DMARC 全部通过验证。将事务性邮件（密码重置、收据、确认邮件）与营销邮件分开，每类邮件只发送给期待收到它的人，并妥善处理退信和退订。首先要把身份验证做对，这是应用邮件进入垃圾邮件箱最常见的原因。

事务性邮件与营销邮件

这两类邮件在代码中看起来相似，但收件箱服务商和法律对它们的处理方式差别很大。

请将两者分开。如果某次营销活动收到垃圾邮件投诉，您不希望同一发送通道中的密码重置邮件因此受到影响。常见做法是使用独立的子域名，例如账户邮件使用 mail.example.com，新闻邮件使用 news.example.com；也有一些服务商在内部将两者分开。例如，截至 2026 年 9 月，Postmark 表示其事务性和广播「消息流」运行在各自独立的发送基础设施上。

选择服务商

您的应用不应从自己的服务器直接发送邮件。邮件发送服务商负责基础设施、IP 信誉、重试和退信处理。知名选择包括 Postmark、Resend、SendGrid、Amazon SES 和 Mailgun；它们都提供 HTTP API 和 SMTP 访问。价格和套餐会变动，请在各自官网上进行比较。

比较时可关注：

• 侧重点。 有些服务商专注于事务性邮件，有些则同时支持事务性和营销性邮件。
• 开发者体验。 API 是否清晰，是否提供适用于您所用语言的官方库，以及是否有有用的日志，显示每封邮件是否已送达、退信或被标记为垃圾邮件。
• Webhook，用于接收退信、投诉和送达通知，以便您的应用作出响应。
• 模板：保存在服务商处，还是保存在您自己的代码中。将模板放在代码中，可以进行版本管理和测试。
• 地区与数据处理，如果您对数据处理地点有要求。
• 您的发送量下的成本，包括超出免费额度后的费用。

如果是向名单发送新闻邮件，专门的新闻邮件或邮件营销工具通常比在应用中自建营销功能更合适。

设置发送域名

请使用您自己的域名发送，例如 hello@example.com，而不是 Gmail 或 Outlook 地址。通过第三方服务使用免费邮箱地址发送的邮件无法通过身份验证检查，很可能会被过滤。

可以考虑专门用于发送的子域名。例如，Resend 建议使用 updates.example.com 之类的子域名发送，以隔离发送信誉（截至 2026 年 9 月）。这样也能使邮件相关的 DNS 记录与您主站的记录分开。

服务商随后会提供需要添加的 DNS 记录，您需要在管理域名 DNS 的地方添加。如果您对 DNS 还不熟悉，请先阅读域名与 DNS 的工作原理，了解记录的基本概念。

SPF

SPF（发件人策略框架）是一条 TXT 记录，列出可以代表您的域名发送邮件的服务器。收件方会检查发送邮件的服务器是否在该列表中。

• 一个域名只应有一条 SPF 记录。如果添加了服务商，请将其合并到现有记录中，而不是再添加第二条。
• 评估 SPF 时最多允许 10 次 DNS 查询；过长的 include: 链可能超出此限制并导致验证失败。
• 许多服务商会要求您为其创建一个回退路径（return-path）子域名并在其上设置 SPF，因此您可能根本无需修改主 SPF 记录。

DKIM

DKIM（域名密钥识别邮件）会为每封邮件添加加密签名。服务商使用私钥签名，您则将对应的公钥发布为 DNS 记录（根据服务商不同，可能是 TXT 或 CNAME）。收件方通过检查签名，确认邮件来自经授权的发送方，并且在传输过程中未被篡改。

服务商的「验证域名」步骤主要就是针对 DKIM。请不要跳过。

DMARC

DMARC 将另外两者联系在一起。它是位于 _dmarc.yourdomain.com 的 TXT 记录，告诉收件方：

• 对齐： 邮件中可见的发件人域名必须与通过 SPF 或 DKIM 验证的域名一致。
• 策略： 对验证失败的邮件应如何处理 —— p=none（仅报告）、p=quarantine（视为可疑，通常进入垃圾邮件箱）或 p=reject（拒收）。
• 报告： 汇总报告发送到哪里（rua=），以便您了解以您域名发送邮件的都是谁。

一个稳妥的做法是：先使用 p=none 并设置报告地址，确认您的正常邮件能够通过验证，然后再改为 quarantine，最终改为 reject。严格的策略也能让他人更难冒充您的域名。

Gmail 的要求

截至 2026 年 9 月，Google 的发件人指南规定：

• 所有发件人向个人 Gmail 账户发送邮件时，都需要 SPF 或 DKIM、发送服务器有效的正向和反向 DNS 解析、TLS，以及在 Postmaster Tools 中的垃圾邮件率低于 0.3%。
• 批量发件人（每天向 Gmail 发送超过 5,000 封邮件）需要同时具备 SPF 和 DKIM、DMARC 记录（允许使用 p=none 策略）、发件域名对齐，以及一键退订功能，并在营销邮件和订阅邮件中显示可见的退订链接。

服务商会处理服务器端的部分。DNS 记录和退订处理则需要您自己负责。即使您每天的发送量远低于 5,000 封，满足批量发件人的规则也是最简单的保险做法。

将发送功能构建到应用中

域名验证通过后：

1. 将 API 密钥保存为服务器端机密，切勿放在前端代码中。请参阅什么是环境变量和机密。
2. 在服务器端发送，即在触发邮件的操作成功之后。
3. 不要让用户等待邮件发送。 对于稍复杂的应用，应将发送任务放入队列，并在遇到临时性故障时重试，这样邮件服务商响应变慢时也不会拖慢注册流程。
4. 记录发送结果，包括服务商的邮件 ID 和状态，但不要记录密钥或包含个人数据的完整邮件正文。
5. 处理退信和投诉的 Webhook：停止向硬退信地址或将您标记为垃圾邮件的地址发送邮件。

以下提示词涵盖了基本要求：

使用服务器机密 [ENV_NAME] 通过 [PROVIDER] 发送事务性邮件，发件人为「Acme hello@mail.acme.com」。注册后发送欢迎邮件，保存预订后发送预订确认邮件。模板保存在代码中，并同时提供 HTML 和纯文本版本。发送任务放入队列，临时性故障最多重试三次。失败时记录服务商返回的错误，但绝不记录 API 密钥。添加一个 Webhook 端点，在硬退信和投诉时将地址标记为无法送达，并在之后的发送中跳过这些地址。

账户类邮件（验证链接、魔术链接和密码重置）属于登录流程的一部分。如何为应用添加登录功能介绍了这些流程如何衔接；请务必让这些链接只能使用一次并设置较短的有效期。

送达率的良好习惯

身份验证让您的邮件获得考虑，而用户的行为则让邮件留在收件箱中。

• 只发送用户期待的内容。 已确认的注册、营销邮件须明确同意加入，不使用购买的名单。
• 让退订变得简单，适用于所有非纯事务性的邮件，并立即执行退订请求。
• 预热新域名。 全新域名在第一天就发送数千封邮件会显得可疑。应从事务性邮件开始，逐步增加发送量。
• 保持名单干净。 立即删除硬退信地址，并考虑移除长期没有打开任何邮件的人。
• 像真人一样写作。 清晰的主题、可识别的发件人名称、纯文本版本、较少的图片，以及指向您自己域名的链接。避免使用链接缩短服务。
• 持续监控。 在 Google Postmaster Tools 中注册您的域名，并不时查看 DMARC 报告。
• 使用真实有人阅读的回复地址。 回复是良好的信号，也能带来有用的反馈。

在不打扰任何人的情况下测试

• 如果服务商提供测试模式或沙盒，请使用它；或者发送到您自己拥有的地址。
• 在开发环境中，发送到接收所有邮件的测试收件箱，而不是真实用户；一个装满了看似真实地址的数据库，很容易意外地给陌生人发邮件。
• 在几种客户端中检查每个模板，例如网页版 Gmail、手机邮件应用和 Outlook，同时也检查深色模式。
• 查看测试邮件的邮件头：它们会显示 SPF、DKIM 和 DMARC 是否通过验证。

法律基础

各国规则不同。总体而言，许多地方的营销邮件需要获得同意，必须标明发件人，并且必须提供有效的退订方式；事务性邮件的处理方式有所不同，但也不应被用来夹带营销内容。如果您通过候补名单页面收集邮箱地址，请说明您会发送和存储哪些内容，以及每个人是何时、以何种方式注册的。如有疑问，请查阅您用户所在地的规定。

邮件检查清单

• 已选择发送服务商；API 密钥已保存为服务器机密
• 使用您自己的域名或子域名发送，而非免费邮箱
• 已添加 SPF、DKIM 和 DMARC 记录，且验证通过
• 事务性邮件与营销邮件已分开
• 发送任务已排队并支持重试；结果已记录
• 已处理退信和投诉的 Webhook
• 非事务性邮件提供退订方式，并立即生效
• 模板已在多种客户端中测试；测试邮件绝不会发送给真实用户

从 Mythex 应用发送邮件

Mythex 不为您构建的应用提供内置的邮件发送服务，因此您需要自行接入 Resend、SendGrid 或 Postmark 等服务商。将其 API 密钥保存为项目机密：智能体可以通过聊天中的机密卡片请您提供。然后用通俗的语言说明您需要哪些邮件。文档中的入门提示词见从应用发送邮件。如果您在 Pro 版中通过 Mythex 购买了域名，可以在域名的 DNS 设置中添加服务商的 TXT 和 CNAME 记录；请参阅自定义域名。

常见问题