如何配置SPFv1:大众版详解
Kent Ickler 和 Derrick Rauch*
防晒系数?
呃……等等不对。 是发送方策略框架
“1997届的女士们先生们,记得涂防晒霜……现在我要给出我的建议:”
SPF是什么?
当今网络中存在邮件"伪造"现象,感谢@ustayready。发送方策略框架(SPF)最初创建于2005年(RFC 4408),最新版本于2014年更新(RFC 7208),同时还有DKIM和DMARC的更新。它试图通过为收件人邮件服务器提供一种方法,来确定电子邮件发件人是否被授权代表FROM字段中的域名发送邮件,从而阻止伪造邮件。收件人邮件服务器因此有机会判断入站邮件更可能是伪造/钓鱼邮件,还是更可能是合法邮件。
- 如果收件人邮件服务器收到来自SPF授权服务器的FROM地址邮件,它有理由相信这是有效/“好"邮件。
- 如果收件人邮件服务器收到来自SPF未授权服务器的FROM地址邮件,它有理由相信这是无效/坏邮件。
SPF记录还可以"告知"收件人邮件服务器在从未经授权的邮件服务器收到邮件时应采取的措施:可以继续投递邮件、标记为可疑(增加风险评级)或直接拒绝邮件。当然,SPF记录并非金科玉律。收件人邮件服务器在考虑SPF记录的权重时,可以遵循其认为合适的任何方法。
营销人员的困境
营销人员经常为此苦恼。这是SendGrid、MailGun、MailChimp等的困境。他们购买了这种花哨的新营销邮件征集工具,但大家总是将他们的活动邮件标记为垃圾邮件!如果您的营销团队没有花时间确保其FROM域的SPF记录准确,收到的邮件可能更容易被视为垃圾邮件/恶意邮件,并被发送到垃圾邮件箱,永远被遗忘。
前瞻性思考
发送方策略框架并未消亡,但它在反垃圾邮件和反钓鱼部门有了新的兄弟之爱。DKIM和DMARC是更新的框架,扩展了SPF早年开始的验证功能。它们共同试图在域名所有权和收件人邮件服务器之间建立信任网络。请关注未来的博客文章,讨论DMARC和DKIM。
域名服务器记录
“授权"邮件服务器/中继传递邮件的SPF记录是一个DNS TXT记录,必须输入到注册商指定的名称服务器上。因为这暗示了域名所有权,它允许域所有者告知收件人,收到的带有其域名的FROM字段邮件是否由他们预期的邮件服务器投递。
下面讨论的DNS记录必须在域的名称服务器上创建,该名称服务器由域注册商上的NS记录定义。
语法解析
有很多工具可以帮助您构建SPF记录,但您仍然需要了解其原理。SPF记录由SMTP收件人从左到右读取。在第一次匹配时,记录分析停止,并返回配置的结果。
- DNS记录类型 = TXT
- 主机 = @(您的主TLD,或您试图保护的任何域)
- 值 = [语法]!!
值键是记录的核心,让我们来看一下:
"v=spf1 " [机制-动作] [机制-谁] [机制-动作] [机制-谁]…
机制-动作
动作参数告诉收件人邮件服务器该做什么。其语法如下:
+
通过邮件:SPF记录指定主机已授权(邮件被接受)-
拒绝邮件:SPF记录指定主机未授权(邮件被拒绝)~
软失败:SPF记录指定主机未授权,但是,嗯,也许吧(标记/增加风险)?
中立:SPF记录指定它不知道,双重嗯。(邮件被接受)
其他动作/结果
机制-谁
这里有很多选项:
all
所有服务器,无处不在ip4:<邮件服务器IP地址>
ip4:<IP地址>/CIDR样式
ip6:<IP6地址>
ip6:<IP地址>/CIDR样式
a:[域]
包含[x域]的所有A记录a:[域]/CIDR
包含[x域]所有A记录的/CIDR网络a
包含此域的所有A记录a/CIDR
包含此域所有A记录的/CIDR网络mx
包含此域的mx记录mx/CIDR
包含此域所有mx记录的/CIDR网络mx:[域]
包含[x域]的所有mx记录mx:[域]/CIDR
包含[x域]所有mx记录的/CIDR网络ptr
包含此域ptr记录的IPptr:[域]
包含[x域]ptr记录的IPexists:[域]
是/否触发器。如果A记录存在=通过redirect:[域]
用[域]的SPF记录替换整个SPF记录include:[域]
包含[域]的SPF记录。匹配=通过,不匹配=失败。这种类型记录在大多数情况下用于大型邮件提供商,如Google、Office等。也常用于邮件中继,如SendGrid、MailGun等。
include:
是一种信任机制。它允许您将对谁被授权从您的域/组织发送邮件的信任代理到另一个域/组织的SPF记录上,您承认该组织负责发送您的邮件。这些组织通常将其SPF记录覆盖所有可能的邮件服务器。
示例
-
v=spf1 +mx -all
接受来自此域mx记录的邮件,拒绝来自其他任何地方的邮件。 -
v=spf1 +a:AnotherDomain.com ?a:google.com -all
接受来自AnotherDomain.com的A记录的邮件,对Google.com的A记录持中立态度,但拒绝其他所有邮件。 -
v=spf1 exists:AnotherDomain.com -all
如果AnotherDomain.com存在A记录,则接受邮件,否则拒绝。 -
v=spf1 -all
拒绝来自此域的邮件,无论谁发送。 -
v=spf1 include:mailgun.com include:sendgrid.com -all
遵循mailgun.com和sendgrid.com的SPF记录规则,拒绝所有其他邮件。 -
v=spf1 redirect=AnotherDomain.com
仅遵循AnotherDomain.com的SPF记录规则。
再谈营销
回到营销部分,MailChimp、MailGun和SendGrid在做什么?
有趣的是,如果您使用邮件中继或群发邮件服务,这里有些值得一说的地方。邮件可以被视为已授权,您可以突破垃圾邮件箱。但是,我内心的红队成员不得不问……
第三方能否在我信任的第三方那里创建一个账户,并在没有我明确批准的情况下以我的名义发送邮件?
嗯,是……也不是。
如果您配置SPF记录授权他们的邮件服务器,这些服务可以以您的名义发送邮件。他们各自采取一些措施来确保第三方不能使用您的发件地址发送邮件。他们通过在代表该域发送邮件之前强制用户验证其FROM域来实现这一点。每个服务的做法不同。有些在其域上创建DNS记录,应包含为+a:yourdomain.mailrelayservice.com
,这可以给您一些 reassurance。但最终,您需要信任您的邮件服务器,如果您觉得不能这样做,那么……这是一个艰难的世界,瘫痪的偏执将会袭来。
更多信息
有关SPF记录等的更多信息,请查看以下链接。同时请关注我们即将发布的关于DKIM(RFC 7372)和DMARC(RFC 7489)的博客!
SPF记录生成器
有一些平台可以帮助构建适合您特定需求的SPF记录。大多数工作方式相似……有些甚至要钱$$!我不建议付费帮助创建SPF记录,但一如既往,在使用免费服务时要小心。也就是说,MXToolbox多年来一直在我系统管理员和蓝队的工具箱中,从未让我失望。
在线构建SPF:https://mxtoolbox.com/SPFRecordGenerator.aspx
链接
- 开放发送方策略框架:http://www.openspf.org/Project_Overview
- 在线构建SPF:https://mxtoolbox.com/SPFRecordGenerator.aspx
- SPF V1: RFC 7208 (obs 4408, 6652) https://tools.ietf.org/rfc/rfc7208.txt
- SPF V1: RFC 6652 (obs by RFC-7208) https://tools.ietf.org/html/rfc6652
- SPF V1: RFC 4408 (obs by RFC-7208) (2006) https://tools.ietf.org/html/rfc4408
- https://www.ietf.org/rfc/rfc4408.txt
即将发布的博客阅读:DKIM, DMARC!
- 基于域的消息认证、报告和一致性:https://dmarc.org/
- SPF V1: RFC 7960 – DMARC的互操作性 https://tools.ietf.org/rfc/rfc7960.txt
- SPF V1: RFC 7489 – DMARC https://tools.ietf.org/rfc/rfc7489.txt
- SPF V1: RFC 7372 -DKIM (更新7208) https://tools.ietf.org/rfc/rfc7372.txt
“但相信我,要涂防晒霜。”
*Kent和Derrick是我们系统管理员团队的一员——没有他们我们该怎么办?