邮件安全实践:SPF、DKIM、DMARC(上)
这几天在域名邮箱的配置过程中学习了一些「新知识」,我理解的电子邮件安全,核心点就是信任,如何建立信任?又如何去验证?验证失败的话如何处理?这正好就是SPF、DKIM、DMARC 的作用,它们并不孤立、要配合使用才能实现安全目的。
虽然是一些陈旧信息,也不知道未来有什么用,但还是做一些记录,锻炼自己用简单的方式表述,并证明自己并没有浪费时间。分成上、中、下三篇。
SPF:「经过授权」的邮局地址白名单
SPF 是电子邮件发送域名的DNS配置中的一条txt记录,里面记录了可信ip地址(段)——即,谁可以替我来发信,据此,收件方通过来信ip的对比就可以判断邮件是否来自可信的”授权邮局“,并作出相应的行动:进入收件箱 or 进入垃圾邮件箱 or 丢弃。正规的邮件服务商gmail.com、outlook.com、qq.com等都会配置SPF,以 QQ 邮箱为例,我们自己动手来查询来看,通过dig
:
dig qq.com txt
;; ANSWER SECTION:
qq.com. 2473 IN TXT "v=spf1 include:spf.mail.qq.com -all"
咦?说好的 ip 地址呢? 别急,这里要解释下,SPF 记录 可以是一个递归结构,我们继续dig :
dig spf.mail.qq.com txt
;; ANSWER SECTION: spf.mail.qq.com. 197 IN TXT "v=spf1 include:qq-a.mail.qq.com include:qq-b.mail.qq.com include:qq-c.mail.qq.com include:biz-a.mail.qq.com include:biz-b.mail.qq.com include:biz-c.mail.qq.com include:biz-d.mail.qq.com -all"
还有?且更多了?那找一个继续挖:
dig qq-a.mail.qq.com txt
;; ANSWER SECTION:
qq-a.mail.qq.com. 600 IN TXT "v=spf1 ip4:101.226.139.0/25 ip4:101.91.43.0/25 ip4:101.91.44.128/25 ip4:112.64.237.128/25 ip4:116.128.173.0/25 ip4:121.51.40.128/25 ip4:121.51.6.0/25 ip4:162.62.52.214 ip4:162.62.55.67 ip4:162.62.57.0/24 ip4:162.62.58.211 ip4:162.62.58.216 -all"
最终收件方(收件人的邮件服务器),会通过这样的方式找到全部的 IP 地址段 白名单,然后看看发信人的IP在不在里面。这就是 SPF 的核心验证流程。
我们也可以通过 Free SPF Record Checker 或 Lookup - SPF-Record这样的工具来验证和体验上述过程,更为直观。
SPF 对齐
如果信件来自「可信地址」就算 SPF 验证通过?不完全是。随着现在 DMARC 验证机制的逐步普及,除了要求发信 IP 来源可信,还会做一个 SPF Alignment 的检查,这项检查的核心是判断邮件头部分的两个邮件发送来源的域名是否相同,或者至少父子域名关系:
- The From: domain
- The RFC5321.MailFrom / Return Path domain
简单来讲就是:你邮件中宣传的「来信地址」得和你信封上邮戳的「来信地址」必须来自同一个域名或者至少是父子域名关系。
举下面三个例子:在 DMARC 的默认设置 (aspf=r)下,前两个通过对齐检查,而第三个未通过。如果 DMARC 设置为严格检查 SPF 对齐(aspf=strict),那么将仅有第一个通过。
# Pass 域名对齐
MAIL FROM: <[email protected]>
From: [email protected]
Date: Fri, Feb 15 2002 16:54:30 -0800
To: [email protected]
Subject: here's a sample
# Pass 父域名对齐
MAIL FROM: <[email protected]> *This is the RFC5321.MailFrom domain.
From: [email protected] *This is the RFC5322.From domain.
Date: Fri, Feb 15 2002 16:54:30 -0800
To: [email protected]
Subject: here's a sample
# Fail 域名未对齐
MAIL FROM: <[email protected]> *This is the RFC5321.MailFrom domain.
From: [email protected] *This is the RFC5322.From domain.
Date: Fri, Feb 15 2002 16:54:30 -0800
To: [email protected]
Subject: here's a sample
再以我自己这几天配置 Oracle Mail Delivery 为例,如果没有配置”自定义返回路径“,就未对齐:
- The From: 是 topnec.org
- The MailFrom / Return Path domain 是 xxxx.rp.oracleemaildelivery.com
其中这个 xxxx.rp.oracleemaildelivery.com 会显示在收到的邮件上被看到,收件人收到的邮件看到的是这样的:
不仅奇怪,而且因为和 From 里的域名不同,也会因此降低信件的「信用」。
如何配置做到对齐呢?通常情况下,返回路径域名在大家使用的知名的商业邮件服务比如Gmail、Outlook、QQ邮箱都是自动配置好的,无需用户自己折腾。但如果像我这种自己使用第三方发件服务的,那么就需要按照其提供的方法设置好 Return Path domain ,有的如 Resend 是通过 MX 记录来配置、有的如 Oracle Mail Delivery 则需要 CNAME 来完配置 ,使得返回路径使用自己的域名、子域名,这样才能通过对齐验证。
SPF 验证不通过会怎么样
不仅仅是 SPF,后面还会介绍 DKIM ,如果它们全部或者部分没有通过验证会怎么样?首先看发送方有没有配置 DMARC 策略,如果没有配置,那么结果这将完全取决于接收方邮件服务商的策略,可能的结果是:
- 信件正常进入收件箱
- 信件虽然进入收件箱、但被标记并提醒为「可疑」
- 信件被标记为垃圾邮件、进入垃圾邮件箱
- 信件直接被拒收退回
如果发送方设置了 DMARC,收信方将会根据发送方的「要求」来处置为通过验证的邮件,结果可能是:放行、隔离、拒收,这个我们在后面的文章中再介绍。
小结
看到这里,我们应该知道正确设置发信服务的 SPF 可以帮助邮件能更安全、可靠的送达目标邮箱。因为通过 SPF 你为自己的发信服务建立了一项可以被验证的信用。