网站上线之后总会需要发邮件：注册验证、密码重置、订单通知、巡检告警。你照着模板把发信代码接好，测试邮件秒到收件箱，一切看起来都正常。直到某天用户来问收不到验证码，你去自己的邮箱翻了一遍，发现这类邮件全都躺在垃圾箱里，和一堆推广邮件混在一起。那一刻你大概会开始怀疑，是不是正文里哪句话写得像营销。于是你把标题改了又改，把正文里的链接删了又加，反复测试几次，结果时好时坏，你也不知道到底是哪一步起了作用。
这时候多数人的第一反应是改正文——去掉标题里的感叹号、把链接换成更“干净”的形式、删掉看起来像广告词的表述。这些动作偶尔能救回来，但常常是白折腾，因为邮件被判成垃圾，很多时候跟内容无关，问题出在收件方对你这个域名的身份判断上。它想知道的是：这封信，到底是不是你有权发出来的。这个判断发生在你看到邮件之前，也发生在你改正文之前。所以与其在内容上反复试探，不如先把身份这层说清楚，它才是决定性的那一关。
邮件是不是你发的，收件方先查DNS
收件服务器拿到一封信，会先去DNS里查你这个域名挂着的几条记录，用来判断发信资格。这套判断靠三个协议完成，分别是SPF、DKIM、DMARC。它们各管一段，缺一段就漏一段，而且它们互相依赖，单独配一条往往看不出效果。更麻烦的是，这三条记录里少一条，收件方拿到的信息就是残缺的，它可能不会直接拒收，而是把你的邮件降级处理，让你完全不知道问题出在哪里。
SPF解决的是“谁可以用我的域名发信”。你在DNS里列一份IP清单，收件方看到邮件，就把发信服务器的地址拿去和这份清单比对，对不上就不认。它有个天然的局限：检查的是信封上的发件地址，不是你收件人看到的那个显示名。这个区别在转发场景里会出事——邮件被转一手，中间换了发信服务器，SPF当场失效，于是你会看到一种奇怪现象：自己收到的通知正常，用户转给同事之后就进了垃圾箱。
DKIM解决的是“这封信有没有被人动过”。发信时用一把私钥给邮件打上签名，公钥放在DNS里公开，收件方拿公钥验签，验得过就说明内容没被篡改、而且确实来自持有这把钥匙的一方。它的好处是签名跟着内容走，转一手照样成立。但它只回答“内容完整吗”，不回答“验不过该拿这封信怎么办”。还有一点容易被忽略：签名用的密钥需要定期轮换，而公钥发布在DNS里，换的时候得确保新旧两把都能被查到，否则轮换当天就会有一批邮件验签失败，收件方看到的是一次莫名其妙的信誉波动。
DMARC补的正是最后这一环。它要求SPF或者DKIM校验通过的那个域名，和你用户看到的发件域名对得上，这个动作叫对齐。同时它明确规定：对不上的邮件，收件方该放行、该丢进垃圾箱，还是该直接拒收。你写在记录里的策略就是这三档，分别记作none、quarantine、reject。没有DMARC，前两条就算配了，收件方也不知道该按什么标准处置。三档策略的收紧过程不能跳步，尤其是从none直接跳到reject，等于把判断权一次性交出去，稍有遗漏就会把正常邮件一起挡掉。
三条记录里最容易写错的是SPF。它是一条TXT记录，末尾要带一个限定词，常见写法有-all、~all、?all三种。用-all表示不在清单里的服务器一律不通过，是官方推荐的写法；用~all属于软失败，还能勉强放行；真正危险的是+all，那等于公开声明“谁都可以用我的域名发信”，看着像配了记录，实际上门户大开，是最容易被伪冒的配置。
DMARC还有个容易被忽略的用途，它除了定策略，还会定期给你发报告。你在记录里填一个收报告的地址，各家收件方会把“最近有哪些服务器用你的域名发过信、通过没通过”汇总给你。很多站长就是靠这份报告才发现，自己几个月前停用的某个系统、或者某个第三方服务，至今还在用这个域名发通知，而它正是让邮件整体信誉被拖下来的那一环。把这类残留的发信源清理掉，往往比调正文的收益更直接，因为你解决的是一个持续扣分的项，而不是一次性的措辞问题。
邮件认证在一些平台上已经是硬门槛，而不只是优化项。按Google官方的发件人指南，所有发件人都应配SPF或DKIM，而每天发信超过5000封的群发方必须三条配齐；没通过认证的邮件，可能直接被拒收。这套要求从2024年开始执行，微软也从2025年跟进。自己搭站发通知的量通常没这么大，但“注册邮件被拒收”这种事一旦落在关键流程上，损失比群发被拦更直接。
所以排查顺序应该是从DNS开始，而不是从正文开始。先确认三条记录都在、SPF尾部的限定词没写漏、DMARC的策略不是空着；第一次配DMARC，建议从none起步，先收两三周报告，把还在用这个域名发信的系统都找出来，再逐步收紧到quarantine和reject。一上来就用最严策略，很容易把你自己都忘了的那条通知链路一起掐掉。真正让邮件落进收件箱的，往往不是正文写得多干净，而是DNS里那几条记录有没有交代清楚。
A5创业网 版权所有