263 企业邮箱域名解析:MX、SPF、DKIM、DMARC 配置
263 企业邮箱自有域名配置:mxw.263.net 优先级 5、mx.263.net 优先级 10、spf.263.net 的 SPF、后台开启的 DKIM,以及 DMARC 报告记录。
阿里云邮箱与邮件推送:DKIM、SPF 与 DMARC 配置
按阿里云官方流程配置邮件推送发信域名:六条 DNS 记录、当前 SPF include 值、按地域生成的 DKIM selector,以及 DMARC 的发布与收紧。
阿里企业邮箱(阿里邮箱)SPF、DKIM、DMARC 配置指南
在自有域名上配置阿里企业邮箱:mx1–mx3.qiye.aliyun.com 三条 MX、spf.qiye.aliyun.com 的 SPF、default._domainkey 的 DKIM,以及与钉钉企业邮箱、邮件推送的区别。
Mailjet 的 SPF、DKIM 与 DMARC 配置(事务邮件与营销)
Mailjet(现属 Sinch)既做事务邮件中继也做营销投放,而同一个发信域往往两边共用。所以认证不是可选项:一条没认证的流会把另一条的信誉一起拖下来,何况 Mailjet 的共享 IP 是和所有客户共用的,DKIM 对齐几乎是"投递信誉只跟你有关"的唯一保证。
要配的只有两条记录。麻烦在细节:DKIM 的记录类型随账号批次不同,值又长到复制粘贴几乎必然出错。
开始之前
- Mailjet 账号,发信域已在 Account Settings > Domains and Senders 添加。
- DNS 写权限。用 Cloudflare 的先看Cloudflare DNS 指南——开代理是那边最常见的翻车方式。
- 如果已经在用 Google Workspace、Microsoft 365 或别的 ESP 发信,先找到现有 SPF,后面要合并而不是新增。
第一步:在 Mailjet 里添加域名
进 Account Settings > Domains and Senders > Setup SPF/DKIM authentication,点域名旁边的齿轮,选 Setup SPF/DKIM Authentication。后台展示的是你这个账号的真实值,以它为准,不是本文的示例。
顺手决定一件事:认证主域还是子域。把事务邮件和营销邮件分到 mail.yourdomain.com、news.yourdomain.com 两个子域,多花十分钟,换来的是投诉潮只损伤子域信誉,而不是你开发票用的那个域名。
第二步:SPF
v=spf1 include:spf.mailjet.com ~all
已有记录就合并:
v=spf1 include:_spf.google.com include:spf.mailjet.com ~all
这里坏得最多的两件事:
- 又发了一条
v=spf1。Mailjet 后台会显示 SPF 失败但不解释原因,收件方则直接按永久未认证处理。一个主机名只能有一条 SPF。 - 查询次数超标。每个
include算一次 DNS 查询,硬上限 10 次。Mailjet + Google Workspace + CRM + 工单系统已经 4–6 次,再加几个就会 permerror,而每条记录单看都没问题。用 SPF 检测看实际次数。
第三步:DKIM
主机记录固定是:
mailjet._domainkey.yourdomain.com
值以 k=rsa; p= 开头,后面是公钥。记录类型是 TXT 还是 CNAME,取决于你账号里显示的是哪套流程:老账号给的是含密钥本身的 TXT,新版界面给的是指向 Mailjet 托管区的 CNAME。按后台写的类型来,不要自己换算。
如果是 TXT:
- 整段值必须粘成一行。折成两行的密钥会解析成乱码,后台会一直显示未验证。
- 面板会自动加引号的,就不要再手动加。Cloudflare、GoDaddy、Namecheap 上多打的引号会变成字面字符,整条记录不再以
k=rsa开头。 - 2048 位密钥约 400 字符。仍限制单串 255 字符的面板需要在同一条记录里拆成几个引号片段;新面板一般自己处理。
如果是 CNAME,目标指向 Mailjet 的签名设施,轮换由它负责。Cloudflare 上必须设为仅 DNS——代理后的 CNAME 会解析到边缘 IP,DKIM 验证失败且毫无提示。
发完回 Mailjet 刷新域名状态,SPF 和 DKIM 都应变绿。官方说最长 48 小时,实际几分钟到两小时,除非你 TTL 设了一天。
第四步:DMARC
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1
监控两周,再 quarantine、最后 reject。报告用 DMARC 报告分析器读。
Mailjet 有个特别之处:SPF 对齐看的是信封发件人(Return-Path)域,而那个域由 Mailjet 控制。多数情况能对齐,但不总是,取决于账号配置和是否用了自定义退信域。可靠的那一半是 DKIM 对齐——这也正是 DKIM 缺失在这里格外致命的原因:DKIM 一坏,只要信封域再稍有偏差,DMARC 就整体失败。
第五步:真实发信验证
通过 API 或 SMTP(in-v3.mailjet.com,587 或 465)发一封到 Gmail,看原始邮件:
spf=pass (spf.mailjet.com designates <IP> as permitted)
dkim=pass header.d=yourdomain.com
dmarc=pass (p=NONE) header.from=yourdomain.com
如果 DKIM 是 pass 但 d=mailjet.com,说明 Mailjet 用了自己的域名签名——你的记录没发,或者发错了主机。这个 pass 对 DMARC 不算数。
发布侧用 DKIM 检测(selector 填 mailjet)和 SPF 检测核对。
常见错误
- 和现有邮箱服务商并存时发了两条 SPF。
- 从 Mailjet 面板复制 DKIM 时带进换行或尾部空格。
- 在会自动加引号的面板里手动打引号。
- Cloudflare 上把 CNAME 开了代理。
- 只认证营销域,事务邮件(重置密码、收据)仍用 Mailjet 自己的域签名。
常见问题
Mailjet 需要单独的发信域吗?
不强制,但建议。子域能把 Mailjet 的信誉和邮箱服务商隔开,也能对营销流单独施加更严的 DMARC 策略而不牵连业务邮件。
后台说 DKIM 未验证,但记录看着没问题
直接查:dig TXT mailjet._domainkey.yourdomain.com +short。值被截断说明面板分段错了;查不到说明你改的不是权威 zone;值里带引号就去掉。
Mailjet 支持 4096 位 DKIM 吗?
密钥对由 Mailjet 生成,长度取决于账号生成的那一对。不要试图换成自己的——私钥在对方侧。
