入站邮件 API 接收发送到你拥有的地址或域名的邮件，对其进行解析，并以结构化的 HTTP POST 形式投递到你的应用。你无需运行邮件服务器并通过 IMAP 轮询邮箱，只需将域名的 MX 记录指向提供商，每封收到的邮件就会以请求头、正文和附件已解析为 JSON 的形式到达你的端点。
入站邮件如何工作？
路由从 DNS 开始。你将域名或子域名（例如 reply.yourapp.com）的 MX 记录指向入站提供商的邮件服务器。当有人向该域名的任意地址发送邮件时，邮件会落在提供商的基础设施上而非你的。提供商接受邮件、解析邮件，并向你注册的 URL 发送 POST 请求，携带解析后的内容。
解析后的载荷通常包括发件人和收件人、主题、纯文本和 HTML 正文、完整的请求头集合以及附件（通常为 base64 编码或通过 URL 引用）。你的应用读取该 JSON 并进行处理，无需维护 SMTP 或 IMAP 代码。投递机制是 webhook，因此同样的规则适用：先以 2xx 快速响应，然后异步处理消息。
有哪些用途？
入站邮件将收到的消息转化为应用事件。常见模式包括：
- 回复处理。 从
notifications@yourapp.com发送通知，当用户回复时，回复以 POST 形式到达，你可以将其归入对话线程。 - 工单创建。 发送到
support@yourapp.com的邮件成为一张新工单，发件人和正文直接映射到你的帮助台。 - 解析入库。 转发的收据或结构化邮件被解析并写入数据库表，无需手动录入。
- 邮件触发操作。 发送到特定地址的邮件触发工作流：创建记录、启动任务、发布到频道。
与发送邮件有什么区别？
出站和入站是两项独立的工作。出站是你的应用通过 SMTP 或 HTTP 发送 API 将邮件投递给收件人。入站则相反：外部发件人将邮件投递到你的应用。完整的邮件集成通常两者兼具，既发送通知也接收回复，但它们独立配置，入站部分依赖于你的 MX 记录。
为什么不通过 IMAP 轮询邮箱？
你可以对真实邮箱运行 IMAP 轮询器，但它会带来持续成本。你需要管理凭据，决定轮询频率（这会增加延迟和空闲连接），自行解析原始 MIME，并跟踪已处理过的邮件。入站 API 消除了大部分工作：提供商解析 MIME，将每封邮件以干净的 JSON 推送一次，你可以近实时地做出响应。有关底层协议的比较，请参阅 SMTP 与 IMAP 的对比。
常见问题
需要哪些 DNS 更改？
将你要接收邮件的域名或子域名的 MX 记录指向入站提供商。传播完成后，发送到该域名任意地址的邮件会流向提供商，提供商解析邮件并将其 POST 到你的端点。使用专用子域名可以将入站路由与主域名的邮件分开。
附件如何处理？
解析后的载荷包含附件，通常以 base64 编码内联或作为 URL 供你单独获取。你的处理程序对其进行解码或下载，并存储到你保存文件的位置。较大的附件通常以 URL 引用，以保持载荷较小。
入站邮件与 webhook 是一回事吗？
投递使用 webhook：提供商为每封邮件向你的应用发送一个 HTTP POST。区别在于载荷是完整解析的邮件，而非通用事件。像对待其他 webhook 一样处理它：验证请求、快速响应、异步处理。
要了解 Bird 如何处理邮件的收发两个方向，请从邮件产品概览和邮件事件指南开始，后者介绍了入站处理程序所依赖的事件投递模型。