Coremail 邮件系统 SPF、DKIM、DMARC 配置（自建与云端）

Coremail 不是一个单一服务。同一套代码会以自建邮件系统（XT6）、专享版租户、公有云邮箱（iCoremail，以及更早的尚易品牌）几种形态交付，不少高校和运营商的邮件平台底层也是它。所以两个 Coremail 用户照着同一篇教程配，最后配出来的记录可能完全不同——所谓"Coremail 的 SPF 记录"并不存在一个通用值。

下面按部署形态分开讲。先确认自己属于哪一种，再动手发记录。

情况一：Coremail 云邮箱 / iCoremail 租户

邮箱由 Coremail 托管，授权就是一条 include，官方支持中心写得很清楚：

@    TXT    v=spf1 include:spf.icoremail.net -all

一条记录。如果这个域名还有 ESP、CRM 在发信，合并而不是新加：

@    TXT    v=spf1 include:spf.icoremail.net include:spf.other-provider.com -all

专享版租户的 MX 和 CNAME 以开通文档为准，典型配置是：

@                MX     10    mx1.icoremail.net.
mail             CNAME        mail1.icoremail.net
pop              CNAME        pop.icoremail.net
smtp             CNAME        smtp.icoremail.net
imap             CNAME        imap.icoremail.net

注意 Coremail 专享版指南里 MX 值末尾那个点。mx1.icoremail.net. 在 DNS 区域文件语法里表示"完整域名"，但有些面板会把它当字面值存下来，结果解析不出来。如果你的面板不接受尾点，去掉就行，面板会自动补区域后缀。

同一份指南里还有个细节：没有 ICP 备案的租户，webmail 的 CNAME 要指向 gzwp.icoremail.net，而不是 mail1.icoremail.net。指错了的表现是登录页能打开，但怎么登都失败。

情况二：自建 Coremail XT6

自建系统没有厂商 include 可以依赖，你要授权的是自己的出口地址。Coremail 官方的 SPF 指引列了四种写法：

v=spf1 a:mail.yourdomain.com -all
v=spf1 mx -all
v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/28 -all
v=spf1 mx ip4:203.0.113.10 include:spf.icoremail.net -all

怎么选，看出口稳不稳定：

• mx：最简单，收信和发信是同一批主机时最合适。每一条 MX 记录会消耗一次 DNS 查询。
• a:：出口走独立的 smarthost、且有固定 A 记录时用。
• ip4:：最精确也最脆弱。新增一条专线、加一条备份链路、换一个 NAT 池，都得手工补。
• 混合写法：允许，但要盯着 10 次 DNS 查询上限。每个 mx 和每个 include 都可能展开成多次查询。

国内企业最常见的一类事故：出口走两条运营商链路，SPF 只写了主链路的 IP，备用链路生效的那些天，一半邮件 SPF 失败。如果出口 IP 没法可靠枚举，正确做法是把 Coremail 挂到固定的 smarthost 后面，用 a: 只授权那一台。

情况三：DKIM

Coremail 各部署形态都支持 DKIM，但密钥归属不同：

• 云端 / 专享：密钥对由 Coremail 支持团队签发，或者在租户控制台生成。你发布公钥，私钥在他们手里，由他们给邮件加签。
• 自建：在系统上生成密钥对，在管理后台开启签名，公钥自己发。选择器由系统分配，从后台读，不要假设是 default。

发布出来的就是一条标准 TXT：

<选择器>._domainkey    TXT    v=DKIM1; k=rsa; p=MIIBIjANBg...

三条能省下几小时排查的规矩：

• 公钥复制不能带任何空白字符。通过聊天工具转发的长密钥，是"记录查得到、签名验不过"的头号原因。
• 主机记录按后台显示的原样发。后台给的是完整域名时，别让面板再补一次后缀。
• 开启签名是独立的一步。自建系统上，DNS 记录和签名开关互不相干，记录有效但开关没开，邮件头里一条 DKIM-Signature 都不会有。

情况四：DMARC

Coremail 官方模板用的是他们自己的报告地址：

_dmarc    TXT    v=DMARC1; p=none; fo=1; ruf=mailto:dmarc@icoremail.cn; rua=mailto:dmarc_report@icoremail.cn

他们的支持团队确实会分析发到这两个地址的报告，对小 IT 团队来说挺实用。但凡有合规要求的，换成自己的邮箱：

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

从 p=none 起步。自建系统尤其容易留着一堆自己都忘了的发信方：扫描仪、备份软件、监控告警、ERP 的通知服务。在这些源确认之前上 p=reject，它们会静默失效，而且很难第一时间联想到是 DMARC 干的。

自建环境怎么验证

dig +short TXT yourdomain.com
dig +short MX yourdomain.com
dig +short TXT <选择器>._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

然后从系统发一封信到 Gmail，读完整的 Authentication-Results 头，不要只看界面上那句"已通过"。

• SPF 过、DKIM 不过：先查选择器，再查公钥。
• 两个都过、DMARC 不过：From 域和签名域没对齐，常见于系统给子域重写了发件人。
• 全都不过：可能出口 IP 根本不在 SPF 里，先确认实际出口。

自建环境还值得查一下出口 IP 的反向解析。SPF 校验的是 IP 不是主机名，但 PTR 和 HELO 不匹配仍然会影响信誉评分，综合视角可以用邮件健康检查。

常见错误

• 写成 include:icoremail.net。授权发信源是 spf.icoremail.net，裸域什么都不授权。
• 把带尾点的 MX 值粘进不接受尾点的面板。记录能保存，永远解析不出来。
• 自建 SPF 只写了双链路中的一条。切换那天一半邮件失败。
• 发了 DKIM 记录但没在后台开签名。
• 合规环境里继续用 Coremail 的 DMARC 报告地址。
• 把根域做成 CNAME。Coremail 自己的文档就警告过，根域 CNAME 会破坏 MX 解析。

常见问题

怎么判断自己是哪种形态？

看私钥在谁手里、入站网关是谁的。来信落在 mx1.icoremail.net，就是云端或专享；来信落在你自己的主机名、IP 也是你的，就是自建——哪怕软件确实是 Coremail。

老版本 Coremail 能用 2048 位 DKIM 吗？

XT6 和现在的云租户都支持。很老的版本可能只能签发 1024 位，这种情况找支持升级，别发一条系统签不出来的密钥。

选择器是按域名还是按租户分配？

多数配置下按域名，但具体值由系统分配。所以一定要从自己的后台读——这也是照抄别家 Coremail 选择器必然失败的原因。

为什么文档里提到把 A 记录指向 127.0.0.1？

那是专享版指南给"根域完全没有 A 记录"的情况准备的。MX 查询要求这个名字在 DNS 里存在，一条指向回环的占位 A 记录能满足这个条件，又不会把网站流量引到别处。根域已经有真实 A 或 AAAA 记录时不要加。