如何配置SPFv1:大众版详解
Kent Ickler和Derrick Rauch //*
防晒系数?
等等…搞错了。 是发送者策略框架
“1997届的女士们先生们,记得擦防晒霜…现在我要给出我的建议:”
当今网络中存在邮件"伪造"现象(感谢@ustayready)。发送者策略框架(SPF)最早可追溯至2005年(RFC 4408),最新版本于2014年更新(RFC 7208),并与DKIM和DMARC共同更新。它试图通过为收件邮件服务器提供一种方法,来判断电子邮件是否来自FROM字段中域名的授权发送者,从而阻止伪造邮件。收件邮件服务器因此能够判断入站邮件更可能是伪造/钓鱼邮件还是合法邮件。
- 如果收件服务器收到的邮件FROM地址来自SPF授权服务器,则有理由认为是有效/“好"邮件
- 如果来自未授权服务器,则有理由认为是无效/恶意邮件
SPF记录还能"告知"收件服务器如何处理未授权邮件:继续投递、标记为可疑(提高风险评级)或直接拒绝。当然,SPF记录并非金科玉律,收件服务器可自行决定如何权衡SPF记录。
营销人员的困境
营销人员常为此头疼。这是SendGrid、MailGun、MailChimp等工具带来的难题。他们购买了 fancy 的新营销邮件工具,但人们总把他们的营销邮件标记为垃圾邮件!如果营销团队没有确保FROM域名的SPF记录准确,接收方可能更容易将邮件视为垃圾/恶意邮件,永远消失在垃圾箱中。
前瞻思考
发送者策略框架并未过时,但在反垃圾邮件和反钓鱼领域有了新伙伴。DKIM和DMARC是扩展SPF验证功能的新框架,共同构建域名所有者与收件服务器间的信任网络。请关注我们未来关于DMARC和DKIM的博客文章。
域名服务器记录
授权邮件服务器/中继发送邮件的SPF记录是DNS TXT记录,必须添加在注册商指定的名称服务器上。由于这涉及域名所有权,它允许域名所有者告知收件方:收到带有其域名的邮件是否来自预期的邮件服务器。
下文讨论的DNS记录必须在域名注册商的NS记录定义的名称服务器上创建。
语法详解
虽然有许多工具可帮助构建SPF记录,但您仍需了解其原理。SMTP收件方从左到右读取SPF记录,首次匹配后即停止分析并返回配置结果。
DNS记录类型 = TXT
主机 = @(您的主TLD或要保护的域名)
值 = [语法]!!
值字段是记录的核心部分,让我们仔细看看:
"v=spf1" [机制-动作] [机制-对象] [机制-动作] [机制-对象]...
机制-动作
动作参数告知收件服务器如何处理:
+
通过:SPF记录指定主机已授权(接受邮件)
-
拒绝:SPF记录指定主机未授权(拒绝邮件)
~
软失败:SPF记录指定主机未授权但…也许吧(标记/提高风险)
?
中立:SPF记录表示不清楚(接受邮件)
机制-对象
选项众多:
all
所有服务器,任何地方
ip4:<邮件服务器IP地址>
ip4:<IP地址>/CIDR格式
ip6:<IPv6地址>
ip6:<IP地址>/CIDR格式
a:[域名]
包含[某域名]的所有A记录
a:[域名]/CIDR
包含[某域名]所有A记录的/CIDR网络
a
包含本域所有A记录
a/CIDR
包含本域所有A记录的/CIDR网络
mx
包含本域所有MX记录
mx/CIDR
包含本域所有MX记录的/CIDR网络
mx:[域名]
包含[某域名]所有MX记录
mx:[域名]/CIDR
包含[某域名]所有MX记录的/CIDR网络
ptr
包含本域PTR记录的IP
ptr:[域名]
包含[某域名]PTR记录的IP
exists:[域名]
YES/NO触发器。如果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
)以提供保证。但最终,您需要信任您的邮件服务器,如果无法信任…这个世界很残酷,偏执可能会让您寸步难行。
SPF记录生成工具
有些平台可帮助构建符合特定需求的SPF记录。大多数工具工作方式相似…有些甚至收费!我不建议为创建SPF记录付费,但使用免费服务时务必小心。多年来,MXToolbox一直是我的系统管理员和蓝队工具箱中的利器,从未让我失望。
在线构建SPF:https://mxtoolbox.com/SPFRecordGenerator.aspx
相关链接
Open Sender Policy Framework:http://www.openspf.org/Project_Overview
SPF V1: RFC 7208 (替代4408, 6652) https://tools.ietf.org/rfc/rfc7208.txt
SPF V1: RFC 6652 (被RFC-7208替代) https://tools.ietf.org/html/rfc6652
SPF V1: RFC 4408 (被RFC-7208替代) (2006) https://tools.ietf.org/html/rfc4408
即将发布的博客: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是我们的系统管理员团队成员——没有他们我们该怎么办?