AWS國際帳號認證 AWS SES (Simple Email Service) 發送郵件被退回或進垃圾箱：SPF/DKIM 配置診斷

先分清：被退回和进垃圾箱不是同一件事

很多人一遇到 AWS SES 发信异常，就会笼统地说“邮件发不出去”或“邮件都进垃圾箱了”。其实这两类问题的原因完全不同。被退回，通常意味着收件方服务器直接拒收，常见于域名校验失败、DNS 记录错误、发送身份不受信任，或者收件方明确阻断。进垃圾箱则代表邮件送达成功，只是没有进收件箱，往往和 SPF、DKIM、DMARC、内容质量、发信频率、历史信誉有关。

诊断时最怕一上来就改模板、换标题、调发送时间，结果方向全错。正确做法是先判断是硬性拒收，还是被判定为低信誉。前者先看退信内容和 SES 事件；后者先看域名认证、邮件头和发信行为。只要把这条线分清，后面的排查会快很多。

AWS國際帳號認證 先看退信信息里到底写了什么

如果邮件被退回，退信说明通常会给出原因。常见提示包括 SPF fail、DKIM fail、Message rejected、Domain not verified、Mailbox unavailable 等。看到这类信息，不要凭感觉猜，应该直接对照返回码和说明逐项排查。尤其是 SES 场景，发送身份、区域、DNS 记录三者很容易被配置错位，一旦错了，退信会非常稳定，不会“偶尔好偶尔坏”。

如果邮件是进了垃圾箱，就不能只盯着退信，因为压根没有退信。此时要看邮件头里的 SPF、DKIM、DMARC 结果，以及收件方对这封邮件的评分。很多时候邮件内容没有大问题，问题出在域名认证不完整，导致收件方把它视为“可疑但未拦截”的邮件。

SPF：最容易写对一半、错一半的记录

SPF 的作用，是告诉收件方：哪些服务器有权代表你的域名发信。对于使用 AWS SES 的域名，SPF 记录通常需要包含 Amazon 的授权项。问题在于，很多人只记得“加一条 TXT 记录”，却忽略了记录格式、记录数量、发送域名和 MAIL FROM 域名之间的关系。

最常见的三种 SPF 错误

AWS國際帳號認證 第一种是域名里存在多条 SPF 记录。SPF 机制要求同一个域名通常只能有一条有效记录，多个 TXT 记录里都写了 v=spf1，收件方可能直接判定为 PermError。第二种是语法写错，比如少了 include、少了冒号、末尾机制顺序混乱，导致记录虽然能被解析，但规则根本没有生效。第三种是用错了域名：你以为在给主域名配置，实际上 SES 发信使用的是另一个子域名，收件方检查的是 MAIL FROM 域名，而不是你眼前看的 From 显示名。

在 AWS SES 中，尤其要注意“From 地址”“MAIL FROM 域名”“验证域名”这三者不是一回事。很多邮件看起来是从 example.com 发出，但底层回信路径可能是 bounce.example.com 或 ses.example.com。如果 SPF 只配在主域名，而 MAIL FROM 指向了另一个没有授权的子域，结果就会出现 SPF fail。

SPF 诊断顺序

排查 SPF，建议先确认收件方看到的实际发信域名，再检查该域名的 TXT 记录是否只有一条 SPF。然后确认记录里是否包含 AWS SES 对应区域和发送方式所需的授权。最后再检查 DNS 是否已经完整生效。不要只在控制台里改了配置就立刻测试，DNS 传播有延迟，尤其是改动刚完成时，部分地区会继续读到旧记录。

如果你同时使用了多个发信平台，例如一部分邮件走 SES，另一部分走其他服务商，SPF 记录里必须把这些来源都纳入同一条规则中，不能各自建一条。SPF 的本质是“合并授权”，不是“多写几条就更保险”。

DKIM：决定邮件能不能被“证明没被篡改”

如果说 SPF 证明的是“谁有权发”，那 DKIM 证明的就是“这封邮件在传输过程中没有被改过，而且确实来自这个域名”。对于 AWS SES 来说，DKIM 几乎是必须项。很多收件方对没有 DKIM 的邮件会天然降低信任，哪怕 SPF 通过，邮件还是可能进垃圾箱。

DKIM 不是“打开功能”就完事

AWS SES 开启 DKIM 后，会要求你在 DNS 中添加若干 CNAME 记录。常见错误有四种：一是记录没有全部添加，只配了其中一条；二是主机名和目标值抄错，少了前缀或多了后缀；三是使用了错误区域生成的 DKIM 记录；四是 DNS 服务商对长记录或自动补全处理不一致，导致解析结果与预期不同。

DKIM 之所以常出问题，是因为它依赖“域名完全匹配”。哪怕只是多了一个点、少了一个子域前缀，签名就会失效。更麻烦的是，很多人只看 SES 控制台显示“已验证”，就以为邮件一定会通过。实际上，SES 只能告诉你记录状态，不代表收件方最终看到的邮件头也一致。真正有用的做法，是把一封测试邮件发到自己的邮箱，查看邮件头中的 DKIM-Signature 和 dkim=pass 结果。

为什么 DKIM 通过了，邮件还是进垃圾箱

DKIM 通过只是基础门槛，不代表邮件就一定进收件箱。收件方还会结合发件域名信誉、IP 信誉、内容结构、附件风险、链接质量、收件人互动等因素综合判断。换句话说，DKIM 是“身份认证”，不是“免死金牌”。如果你的域名刚启用，长期没有发信历史，或者一次性向大量不活跃用户发送，哪怕 SPF 和 DKIM 都正常，邮件也可能被放进垃圾箱。

排查 AWS SES 时，建议按这个顺序走

很多问题之所以拖很久，不是因为技术难，而是因为排查没有顺序。建议按照“身份认证、DNS、发送链路、收件方判断”四步来走，效率最高。

第一步：确认 SES 使用的是哪个区域和哪个身份

AWS SES 是区域化服务。你在某个区域里完成的域名验证、DKIM 配置、发送身份设置，不一定适用于另一个区域。如果应用程序调用的区域和你配置 DNS 的区域不一致，就会出现“控制台看着正常，实际发信却失败”的情况。先确认代码或 SMTP 配置连接的是哪个区域，再去看该区域下的域名验证状态。

AWS國際帳號認證 第二步：核对 From、MAIL FROM、Return-Path

收件方判断 SPF 时，很多情况下会看 Return-Path 所属域。AWS SES 若启用了自定义 MAIL FROM 域名，就要确保该域名已经正确配置 MX 和 SPF。否则，虽然发件人显示是你的品牌域名，但验证时会被视为另一个未授权域，SPF 就会失败。对于退信和反弹处理，这一步尤其重要，因为 Return-Path 还影响退信回传路径。

第三步：核对 DNS 是否真的生效

不要只在 DNS 控制台里看“已添加”。要从外部解析结果去确认。重点看三件事：TXT 记录是否完整、CNAME 是否指向正确、有没有旧记录残留。很多失败案例不是“没加记录”，而是“加了旧记录和新记录并存”，或者“删了旧记录但缓存还没过期”。DNS 生效时间因服务商而异，短则几分钟，长则数小时甚至更久。

第四步：看邮件头里的认证结果

如果邮件已经送到收件箱或垃圾箱，最直接的证据就是邮件头。你要找的是 SPF、DKIM、DMARC 对应的 pass、fail、neutral、softfail 等结果。只看一行摘要不够，要结合原始头信息判断是哪一层失败。有时候 SPF 是 pass，但 DKIM 因为签名域不一致而 fail；也有时候两者都 pass，但 DMARC 因为对齐失败而不通过。

别忽略 DMARC，它常常是最后一脚

很多人以为只要 SPF 和 DKIM 配好就结束了，其实收件方越来越看重 DMARC。DMARC 的核心不是“再验证一次”，而是检查发件域名是否对齐。也就是说，SPF 或 DKIM 即便通过，如果它们对应的域名与 From 头里的域名不一致，DMARC 仍可能失败。失败后，轻则进垃圾箱，重则被直接拒收。

对于刚开始使用 SES 的团队，建议不要一开始就把 DMARC 策略设得太激进。可以先从监控模式开始，收集报表，确认 SPF 和 DKIM 都稳定通过，再逐步提高策略强度。否则，前端发信链路刚上线，就因为策略过严把正常邮件拦住，反而得不偿失。

为什么“技术都对”，邮件还是不好送达

这是最常见也最容易误判的地方。认证通过，只代表你有资格发信，不代表别人一定愿意收。收件方还会看你的发信行为是否像正常用户。比如短时间内爆发式群发、名单里有大量无效地址、退信率太高、投诉率太高、邮件内容像广告模板、链接过多、图片过大、主题过于诱导，这些都会让垃圾箱概率上升。

SES 用户特别要注意账号信誉和发送节奏。新域名、新账户、突然大批量发送，是最容易踩坑的组合。即使 SPF 和 DKIM 完全正确，收件方也会把“刚注册没多久、一次发很多、互动很低”的域名看得非常谨慎。换句话说，送达率是认证、内容、信誉三者共同作用的结果，不是某一项单独决定。

内容层面也要过关

邮件正文里如果满是营销话术、夸张标题、短链、可疑附件，系统很难给高分。尤其是测试环境里常见的“请点击确认、立即领取、限时优惠”等词汇，如果在业务邮件里大量出现，很容易影响判定。业务通知邮件应该尽量保持清晰、简短、目的明确，减少无关图片和外链，让收件方更容易识别为正常通知。

一份实用的排查清单

当 AWS SES 邮件被退回或进垃圾箱时，可以按下面的顺序快速检查：

一，确认是退信还是送达后进垃圾箱。二，看退信返回码或邮件头中的认证结果。三，确认 SES 区域与发送身份是否一致。四，检查 SPF 是否只有一条有效记录，且包含正确授权。五，检查 DKIM 的 CNAME 记录是否完整、是否与当前区域匹配。六，确认 MAIL FROM、Return-Path 和 From 的关系没有冲突。七，查看 DMARC 对齐是否成立。八，观察发信量、退信率、投诉率和内容质量。

如果每一步都正常，但问题仍然存在，就要考虑收件方策略、域名历史信誉、IP 信誉和名单质量。此时最有效的办法不是继续盲改 DNS，而是用一小批真实可达、长期活跃的地址做分层测试，观察不同邮箱服务商的表现，再逐步调整。

把问题一次性修好，靠的是系统思路

AWS SES 本身并不难用，真正难的是它把“发信技术、域名配置、DNS 传播、邮件信誉、收件方规则”这些环节都串在了一起。只盯着控制台，往往看不到完整链路；只看 SPF，不看 DKIM 和 DMARC，也很容易漏掉关键问题。最稳妥的做法，是先把身份认证做扎实，再保证发送链路一致，最后通过内容和发信节奏维护信誉。

如果你的邮件现在被退回，先找退信原因；如果你的邮件进了垃圾箱，先看认证和邮件头。不要急着改标题，也不要把问题全部推给 AWS。大多数送达问题都能通过认真核对 SPF、DKIM、DMARC 和 DNS 配置找出来。把这几个关键点理顺，SES 的邮件送达率会明显稳定下来，后续维护也会轻松很多。