自建域名邮箱转发频频撞墙？Outlay 的“脾气”你不懂

最近在捣鼓自动化消息通知，想用 Cloudflare Worker 给自己搭一个轻量级的邮件摘要服务，顺便把消息转发到我的常用邮箱里。

Cloudflare Worker 转发邮件至 Outlook 遭到拒收的界面截图

本来以为这就是个简单的“API 调用 + 转发”操作，结果现实狠狠打脸——转发给 Telegram（TG）的消息稳稳当当，但只要一转发到 Outlook，直接就“已送达”变“被拒收”。

如果你也遇到了这种“看似配置没错，但就是发不进去”的尴尬情况，别急，这大概率不是你代码写错了，而是 Outlook 的“洁癖”犯了。

为什么 Outlook 总是拒收？

Outlook 的反垃圾邮件机制是出了名的严格。

SPF、DKIM 和 DMARC DNS 记录配置原理图

当你使用 Worker 或者自建服务器转发邮件时，Outlook 的接收方服务器会进行一系列严格的“安检”：

1. IP 信誉度： Cloudflare 的 Worker 出口 IP 虽然稳定，但在某些运营商或黑名单数据库里的 reputation（信誉分）可能并不高。Outlook 看到来自未知 IP 段的批量转发请求，第一反应往往是“可疑”。
2. 域名 DNS 配置： 如果你没有配置完善的 SPF、DKIM 甚至是 DMARC 记录，Outlook 会认为这封邮件是“伪造身份”，直接拒之门外。
3. 转发链路过长： 原始邮件 -> Your Worker -> Outlook。这种“中转”行为容易被判定为“Relay（中继）滥用”，尤其是当你的 Worker 发送频率较高时。

简单来说，Outlook 不认识你的 Worker，所以它不敢收。

摸索解决方案：从 DNS 到服务端

既然知道了原因，我们就可以对症下药。想提高 Outlook 的接收率，可以尝试以下几个步骤：

1. 完善 DNS 记录（必须做）

这是最基础的门槛。确保你的域名 DNS 配置里不仅只有 A 记录，还要有：

• SPF (Sender Policy Framework)： 允许 Cloudflare 的服务器代表你的域名发送邮件。
• DKIM (DomainKeys Identified Mail)： 给邮件加上数字签名，证明是你发出的，未被篡改。
• DMARC： 告诉接收方（如 Outlook）如果 SPF 和 DKIM 检验失败该怎么处理（虽然刚开始可以设为 p=none，但配置了总比没有好）。

2. 使用 SMTP 中继替代纯 API 发送

如果你是直接在 Worker 里调用 Sendmail API 或者简单的 HTTP 接口转发，建议改为通过正规的 SMTP 中继服务。比如使用 SendGrid、Mailgun 或者 Resend 的 API。

这些服务商拥有高信誉度的 IP 地址和微软的“白名单”关系，通过它们进行中继，成功率会高得多。

3. 调整邮件内容与频率

避免在正文中包含大量敏感词，同时控制转发频率。不要一次性由 Worker 触发大量并发请求，那样必被封禁。

Gmail 会是救星吗？实测分享

既然 Outlook 这么“难搞”，很多人第一个念头就是：“那我换 Gmail 总行了吧？”

答案是：大概率会比 Outlook 稳，但也不是 100% 免死金牌。

Gmail 的反垃圾机制虽然也严格，但它对于个人开发者和小流量的转发稍微“宽容”一点点。它更看重邮件内容的相关性和用户的互动行为。如果你的测试邮件只是简单的纯文本摘要，Gmail 进入收件箱的概率确实比 Outlook 高。

但是！ 长期来看，如果域名没有通过预热，或者缺乏反向解析，Gmail 同样会把你的邮件扔进垃圾箱，甚至直接拦截。只是相比 Outlook 的“一刀切”，Gmail 多了一个“垃圾箱”的缓冲步骤。

总结与建议

如果你只是想搞个玩具级的通知，不想折腾复杂的 DNS 验证和 SMTP 配置，

• 方案 A（稳）： 放弃邮件转发，专注于 Telegram Bot、Pushover 或者 Server酱 等即时消息通道。这些专用的消息通道对来源 IP 的宽容度远高于邮箱。
• 方案 B（折腾）： 硬刚邮箱。老老实实配置好 SPF/DKIM，申请 Resend 或 SendGrid 的免费额度 API，用专业的信使去敲 Outlook 的大门。

别再纠结为什么 Outlook 拒收你的 Worker 邮件了，这就是技术生态中的“黑箱”博弈。省点时间，换个思路，心情也许会好很多！