用自有域名搭企业邮箱之后,遇到的最烦人的一件事就是:给部分收件人发信明明”发送成功”,对方却在垃圾邮件箱里才找到你的邮件。我这次的场景是从企业微信邮箱发往139 邮箱(中国移动),配好域名解析的第一周,测试邮件几乎全军覆没进垃圾箱。下面把完整的排查过程记录下来。
先说结论
- SPF、DKIM、DMARC 三项认证里缺了 DKIM 和 DMARC,是进垃圾箱的直接原因。补全后当天恢复正常投递。
- 配置修好只是及格线。新域名、
.site这类廉价后缀、以及mail.子域地址,都会让域名信誉长期吃亏,需要时间养。
第一步:别猜内容,先查发信认证三件套
邮件被判垃圾时,第一反应通常是”标题里是不是有营销词””是不是带链接了”。但内容维度非常玄学,而发信认证是确定性的——收件方服务器一定会查 DNS,查不到就打问号。所以先查这三项:
| 认证 | 作用 | 查询的 DNS 名称 |
|---|---|---|
| SPF | 声明哪些服务器有权用你的域名发信 | <域名> 的 TXT 记录 |
| DKIM | 给邮件加不可伪造的数字签名 | <selector>._domainkey.<域名> 的 TXT 记录 |
| DMARC | 告诉收件方,认证失败时怎么处理,并接收报告 | _dmarc.<域名> 的 TXT 记录 |
Windows 上查 DNS,建议用 PowerShell 的 Resolve-DnsName 而不是 nslookup——后者有时只返回 SOA 段,看不到实际的记录条目:
# MX:定位收信服务器
Resolve-DnsName mail.example.com -Type MX -Server 119.29.29.29
# SPF
Resolve-DnsName mail.example.com -Type TXT -Server 119.29.29.29
# DMARC
Resolve-DnsName _dmarc.mail.example.com -Type TXT -Server 119.29.29.29
# DKIM(selector 由邮件服务商生成,形如 xxxx._domainkey,以面板显示为准)
Resolve-DnsName xxxx._domainkey.mail.example.com -Type TXT -Server 119.29.29.29建议多找几家 DNS 交叉验证:119.29.29.29(DNSPod)、223.5.5.5(阿里)、114.114.114.114,以及域名自己的权威 NS——直接问权威服务器可以完全排除缓存干扰,这是我这次能快速定位问题的关键手段。
我当时的查询结果是:MX、SPF 都在,DKIM 和 DMARC 完全缺失。三项里缺两项,进垃圾箱是必然的。
第二步:补 DKIM 和 DMARC(含企业微信的具体路径)
要注意的是,企业微信版的企业邮箱,管理入口和独立版腾讯企业邮(exmail.qq.com)完全不一样。DKIM 不在「邮箱域名」页,而是在这里:
企业微信管理后台 → 协作 → 邮件 → 安全管理 → DKIM 验证 → 配置点「配置」后系统会生成一条记录,复制它的主机记录(形如 xxxx._domainkey)和记录值(形如 v=DKIM1; k=rsa; p=MIGf...),到 DNS 服务商处添加 TXT 记录,再回后台点「已完成配置,立即验证」。
DMARC 则是一条固定写法的 TXT 记录。rua 参数指定聚合报告的接收地址,腾讯官方建议填它自己的报告邮箱,这样报告汇总给腾讯做投递质量监测,自己不会被一堆 XML 附件刷屏:
| 主机记录 | 类型 | 记录值 |
|---|---|---|
@ |
MX | mxbiz1.qq.com(优先级 5)、mxbiz2.qq.com(优先级 10) |
@ |
TXT | v=spf1 include:spf.mail.qq.com -all |
_dmarc |
TXT | v=DMARC1; p=none; rua=mailto:mailauth-reports@qq.com |
| 服务商生成的 selector | TXT | v=DKIM1; k=rsa; p=...(在后台生成后复制) |
DMARC 的 p 参数建议先用 p=none(只监测、不拦截),观察一两周投递稳定后,再逐步收紧到 quarantine(标记垃圾)或 reject(直接拒收)。
三条录入注意点:
- 主机记录里的
.和_必须是英文半角。全角符号在界面里和半角几乎看不出差别(浏览器里．和.长得太像了),但发布出去的域名就是错的。 - 记录值不能有多余空格,字母大小写不要改。建议先在记事本里中转一遍再粘贴,避免网页复制带进格式字符。
- DKIM 的 selector 由服务商随机生成,以面板里当前显示的为准。核对 DNS 记录时,要用这条记录的主机记录原文去查,而不是凭记忆或早先的截图。
第三步:如果配置全对还是进垃圾箱,那是信誉问题
补全 DKIM + DMARC 后,我的邮件当天就正常进收件箱了。但如果你三项认证全 pass 仍被归类垃圾,那就不是配置问题,而是域名信誉问题,它靠配置解决不了,只能靠时间:
- 域名越新越吃亏。零发信历史的新域名突然开始发信,任何反垃圾系统都会先观望。
- 廉价后缀默认信誉低。
.site、.xyz、.top这类后缀被垃圾邮件滥用得厉害,初始信任度天然低于.com、.cn。 - 子域发信地址是明显的减分项。形如
xxx@mail.yourdomain.com的地址会降低信任度。如果域名解析是在子域上建的(比如 DNS 服务商里添加的”域名”本身就是mail.example.com),而邮箱也绑定在这个子域上,长期最优解是把邮箱改绑到主域,去掉mail.前缀。 - 养号节奏很重要。配置修好后 2 到 4 周内,只做一对一的真人通信:发给真实联系人,对方打开、回复,并顺手点一次”不是垃圾邮件”。这段时间绝对不要群发任何通知或营销邮件,否则信誉会被重新打回原点。
排查速查表
| 现象 | 结论与动作 |
|---|---|
| 邮件能发出但进垃圾箱 | 先查 SPF / DKIM / DMARC 三项 DNS 记录,缺哪项补哪项 |
| DKIM 记录查不到 | 用 DNS 面板里那条记录的主机记录原文再查,确认 selector 名称、记录值是否被截断或含空格 |
nslookup 只返回 SOA、看不到记录 |
Windows nslookup 的行为问题,改用 Resolve-DnsName 或直连权威 NS |
| 三项全 pass,仍进垃圾箱 | 域名信誉问题(新域名、廉价后缀、子域地址),需 2~4 周低频真人通信养号 |
| 只有部分收件人收到垃圾箱 | 对方账号曾举报过该域名,或对方反垃圾等级设置更严;可请对方加入白名单 |
SPF 结尾该用 ~all 还是 -all |
都能通过校验,-all 更严格;没有第三方代发需求时优先 -all |
写在最后
这次排查最大的感受是:邮件投递问题看起来玄学,其实完全可以按确定性证据一步步排除。DNS 记录查得到查不到、邮件原文里的认证结果是什么,这些都是非黑即白的事实;把这几项事实摆清楚,剩下的才轮到”内容是不是太像营销邮件””域名信誉够不够”这类软性因素。
顺带一个实用技巧:收件方邮箱里查看邮件源码(139 邮箱在”更多 → 查看邮件源码”)里的 Authentication-Results 行,会直接给出 spf= / dkim= / dmarc= 三项的实际校验结果。这是判断问题卡在哪一项最快的方法,比反复猜 DNS 高效得多。