前言
只要你经常购买和持有域名, 那么就一定会有域名被闲置. 有人会将它们托管于邮件服务器用于接收可能的入站邮件, 也会将域名停靠在一个单页上待售. 但是即使这些域名你不会用于发件因此没有设置 SPF, 那么也是会被恶意利用进行伪装发件, 进而影响你的域名声誉, 为今后的业务或交易留下隐形的风险.
参考本站百科中的垃圾邮件分析案例之一: 案例 #2 - 伪装发件(学信网) - 邮件人
这是个典型的受害人因为近似域名而被无意间利用于伪装发件, 因为没有正确地在 SPF 和 DMARC 中声明, 最终导致该邮件没有被直接拒信而是仅仅被邮件服务器隔离. 想象一下如果长期以往, 即使是被隔离, 也会有邮件服务器管理员不堪其扰而选择将这类特征邮件加入入站黑名单甚至报告给远程黑名单(RBL)供应商, 那么受害域名就是最有可能被标记为邮件特征的, 虽然受害域名从来没有真正发送过一封邮件.
本文将介绍如何在域名中正确声明 "本域名不会用于发送邮件, 如果有入站邮件被归属于本域名之下, 那么请直接拒绝入站并向域名管理员报告" 这样的邮件传递策略.
SPF 策略
SPF 是电子邮件发送中最基础的策略框架, 它提供了灵活的指令使得管理员可以声明发送 IP 归属或委托于何处. 如果你的域名不会用于发送电子邮件, 那么也必须设置 SPF 记录, 否则接收方邮件服务器很可能会在 SPF 策略为空的情况下依旧以 SPF 无效为由而接受入站.
完全不发件
设置以下的 SPF 记录用于保护完全不会用于发送邮件的域名 example.com:1
example.com. 3600 IN TXT "v=spf1 -all"
不发件但使用邮件路由间接接收邮件
如果你的域名托管于类似 Cloudflare Email Routing 的地方, 实际是通过转发入站邮件的方式接收邮件. 通常情况下 Cloudflare 会在首次启用 Email Routing 时提示你设置如下的 SPF 记录:1
example.com. 3600 IN TXT "v=spf1 include:_spf.mx.cloudflare.net ~all"
注意其中的 ~all 指令中的 ~ 表示了 softfail, 即 "软失败" 策略, 声明策略要求收件方在 SPF 策略验证失败的时候也不要拒绝邮件, 这种策略通常用于早期部署时方便用于测试服务, 当完成测试部署后切换到生产部署时, 则应该将 ~all 调整为 -all 策略, 即声明策略要求收件方在 SPF 策略验证失败后直接拒绝邮件.
如果你遵照意见设置为 -all 指令, 则务必阅读测试小节以确保该策略适应你的转发目标邮件系统, 否则应该忽略本文的意见使用默认的 ~all 指令.
DMARC 策略
DKIM 签名应当与 DMARC 策略同时设置.
DMARC 是现代的邮件策略框架, 用于结合 SPF 和 DKIM 增强电子邮件安全, 使得收发双方的可以进行主动报告问题.
完全不发件
设置以下的 DMARC 记录用于保护完全不会用于发送邮件的域名 example.com:1
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; ruf=mailto:report@example.com;"
将其中的 dmarc@example.com 和 report@example.com 邮箱更换为你用于处理 DMARC 报告的邮箱地址, 两者实际可以用相同的邮箱, 最好使用当前域名下的邮箱.
如果你不想接收报告, 那么设为以下记录:1
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject;"
不发件但使用邮件路由间接接收邮件
设置以下的 DMARC 记录用于保护不发件但使用邮件路由间接接收邮件的域名 example.com:1
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:report@example.com; ri=604800; aspf=s; adkim=s; fo=0:1:d:s"
将其中的 dmarc@example.com 和 report@example.com 邮箱更换为你用于处理 DMARC 报告的邮箱地址, 两者实际可以用相同的邮箱, 最好使用当前域名下的邮箱.
如果你不想接收报告, 那么设为以下记录:1
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; aspf=s; adkim=s;"
释义
| 标签与值 | 释义 |
|---|---|
v=DMARC1 | DMARC 版本. |
p=reject | 对验证失败的邮件执行拒绝(reject)策略. |
sp=reject | 对该域名下方的子域名发送的的邮件也执行拒绝(reject)策略. |
pct=100 | 策略应用于百分之一百(100)即所有发送的邮件. |
rua=mailto:dmarc@example.com | DMARC 汇总报告接收方式为发送到邮箱 dmarc@example.com. |
ruf=mailto:report@example.com | DMARC 取证报告接收方式为发送到邮箱 report@example.com. |
ri=604800 | 报告发送间隔为 7 天. |
aspf=s | SPF 对齐策略为严格(s). |
adkim=s | DKIM 对齐策略为严格(s). |
fo=0:1:d:s | 对同时对齐失败(0), 任意其一对齐失败(1), DKIM 失败(d), SPF 失败(s)的情况发送取证报告. |
测试
实际上对于 -all 是有异议的. 因为当前业界中对于活跃的会用于发送邮件的域名的 SPF 策略共识是不应该被设置为 -all, 这是由于邮件协议, 邮件系统和传递策略互相作用后给出的实践建议, 有关这部分内容本站会在今后的百科中讲述.
但是, 本文的邮件路由建议中针对的域名并非是完全的用于向任何域名发送邮件的情况, 并且它并不 "活跃". Cloudflare Email Routing 和其他类似的邮件路由转发服务只允许将入站邮件转发给经过了接收方确认验证的电子邮件地址, 这些地址往往都是私密的正式生产部署的现代邮件系统. 并且在本文中作为例子出现的 Cloudflare Email Routing 使用的是现代的 SRS 策略转发邮件, 这是解决传统邮件转发可能会导致 SPF 不匹配然后被发件人策略指令拒绝的办法, 是私密性质的内向电子邮件发送, 即使失败也不应该向未经确认的外部邮箱发送邮件, 所以笔者在 SPF 小节建议切换为 -all.
因此如果看到这里, 读者应该在设置完成 SPF, DKIM 签名和 DMARC 策略通过测试确认, 然后切换为 -all 策略和之后再次进行测试以确认你的转发目标邮件地址的邮件服务器是否能够正常通过邮件. 通常情况下这是无碍的, 但也无法排除部分转发目标邮件系统会在 DMARC 策略之前执行 SPF 策略验证, 然后直接忽视 DMARC 策略直接拒绝邮件入站, 导致邮件传递失败. 如果确认转发地址的邮件系统即使有 SRS, DMARC 和 DKIM 的情况下也无法处理这种情况, 那么应该切换为 ~all 指令.
如果读者你不同的看法, 欢迎在评论区指出.
总结
如果你完全不想看上方的说明和解释, 这里也直接提供了「万能」的建议.
对于真正完全不发件的域名, 使用以下策略:
SPF 策略:
"v=spf1 -all", 解析名称为@.DMARC 策略:
"v=DMARC1; p=reject; sp=reject;", 解析名称为_dmarc.
对于使用 Cloudflare Email Routing 类似服务进行邮件接收的域名, 使用以下策略:
- SPF 策略:
"v=spf1 include:_spf.mx.cloudflare.net ~all", 解析名称为@, SPF 的 include 或其他 IP 范围指令设置为实际的值. - DMARC 策略:
"v=DMARC1; p=reject; sp=reject; pct=100; aspf=s; adkim=s;", 解析名称为_dmarc, 并同时设置 DKIM 签名.
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
