SendCloud（赛邮）邮件认证：SPF、DKIM、DMARC 配置

SendCloud（赛邮）是国内开发者要做事务邮件时最常选的发信 API：找回密码、订单确认、账单通知。它是发信服务，不是邮箱托管。这个定位决定了它的 DNS 配法和企业邮箱完全相反——主域的 MX 一个字都不要动。

如果你是从别的营销平台迁过来，习惯是"面板给什么就加什么"，请先看 MX 那一节。把生产域名的 MX 指到发信服务上，全公司的收信会立刻挂掉。

用子域，别用根域

干净的做法是从 mail.yourdomain.com 或 notify.yourdomain.com 发信，而不是 yourdomain.com：

• 出事时影响面可控。一次糟糕的群发、一个泄露的 API Key，损害止步于子域。
• 发信服务的 SPF、DKIM 记录不会和邮箱服务商的记录打架。
• 可以把子域交给市场团队用，而不用把公司主域的管理权限给出去。

线上大多数 SendCloud 域名都是子域，原因就在这里。控制台两种都支持添加。

第一步：发信子域的 SPF

经典版 SendCloud 的 include 是：

mail.yourdomain.com    TXT    v=spf1 include:spf.sendcloud.org -all

国际版 Aurora SendCloud 的文档写的是 include:sendcloud.org：

mail.yourdomain.com    TXT    v=spf1 include:sendcloud.org ~all

这两个不能互换。用哪个，以你账号里域名配置页显示的为准——你属于哪条产品线，只有控制台知道。把 spf.sendcloud.org 抄进 Aurora 账号，结果是 SPF 永远不通过。

如果这个域名已经有一条 SPF（比如 CRM 也在用），改那条，把 include 插到 all 机制前面，不要在同名主机下再造一条 v=spf1。

第二步：DKIM

SendCloud 按域名签发密钥，主机记录通常是：

sendcloud._domainkey    TXT    k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

部分账号的选择器不一样，记录值有的带 v=DKIM1; k=rsa; p= 前缀，有的只有 k=rsa; p= 部分。两种写法收件方都认。控制台显示什么就发什么，不要自己"规范化"。

两个高发的失败场景：

• 公钥被截断。控制台的密钥很长，用鼠标在浏览器里框选复制，经常漏掉最后几个字符。之后每封信签名验证都失败，报错还看不出原因。
• 主机记录写错层级。子域场景下控制台给的是 sendcloud._domainkey.mail，你发到根域的 sendcloud._domainkey，公钥就放在了一个没人查的地方。

发完回到控制台点验证。域名没显示已验证之前，SendCloud 不会给你加签。

第三步：MX 记录——改之前先读完这段

SendCloud 可以代收某个域名的邮件，退信处理和回复都靠它。文档给的目标是：

@    MX   10    mx.sendcloud.org

这条记录属于发信子域，不属于公司主域——除非你明确决定让 SendCloud 接管主域的回复邮件。已经在阿里邮箱、腾讯企业邮或 Microsoft 365 上跑员工信箱的公司，把主域 MX 指到 SendCloud，TTL 一过全公司收不到信。

如果确实需要接收退信，常见的折中是只给子域设 Return-Path 或 reply-to，主域不动。

第四步：DMARC

_dmarc    TXT    v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

子域的记录发在 _dmarc.mail。子域没有单独记录时会继承组织域策略，但显式写一条，可以让批量发信用更严格的策略，而公司主域按自己的节奏推进：

_dmarc.mail    TXT    v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

这正是把发信拆到子域的最大好处：批量邮件可以先上严格策略，主域在过渡期继续 p=none。

不发测试邮件也能验证

直接查记录：

dig +short TXT mail.yourdomain.com
dig +short TXT sendcloud._domainkey.mail.yourdomain.com
dig +short TXT _dmarc.mail.yourdomain.com

再用控制台的验证按钮或 API。SendCloud 的接口会把"它期望的记录"和"你实际配的"一起返回，方便逐字比对：

GET https://api.sendcloud.net/apiv2/domain/get
    ?apiUser=YOUR_API_USER&apiKey=YOUR_API_KEY&name=mail.yourdomain.com

返回里的 spf.domain、spf.value、dkim.domain、dkim.value、mx.domain、mx.value 就是对照标准。比对本机的 zone 记录，不要比对这篇文章。

最后实发一封，在收件端读邮件头。SPF、DKIM、DMARC 三项全 pass，且 DKIM 的 d= 是发信子域，才算真的通了。

常见错误

• 把主域 MX 指向 SendCloud。全公司收信立刻中断。
• 经典版账号用了 Aurora 的 include，或者反过来。
• 新加一条 SPF 而不是改现有的那条。
• 发了 DKIM 但没做域名验证，邮件根本没签名。
• 为了"好看"用主域发信，后来发现想给批量邮件上 DMARC 严格策略，又会牵连其他系统的事务邮件。

常见问题

只发信不收信，还需要 MX 吗？

不需要。不需要把退信收进自己信箱的话，直接跳过 MX，用控制台的退信 webhook 或 Return-Path。发一条用不上的 MX，只是给自己多开一条丢信的路径。

同一个子域能同时给 SendCloud 和邮箱服务商用吗？

收信不行。发信可以——前提是所有发信服务都合并进同一条 SPF，且各自有独立的 DKIM 选择器。更干净的做法还是把发信和收信分到不同主机名。

为什么 SPF 过了 DMARC 还是不过？

对齐问题。SPF 校验的是信封发件人（MailFrom），DMARC 要求这个域和用户看到的 From 头一致。发信服务用自己的退信域做信封，SPF 会过，但对齐失败。用你的域名做 DKIM 签名才能修好这一项。

p=none 要待多久？

有历史流量的域名两到四周；从来没收集过报告的，时间要更长。等报告里所有合法来源都显示 pass 且对齐，再上 quarantine。