SPF、DKIM和DMARC认证如何提升邮件送达率(测试)
TL;DR 想要快速解决方案? 几乎所有营销平台都提供了关于使用SPF和DKIM授权外发邮件的详细教程。
Salesforce: https://help.salesforce.com/articleView?id=000315520&language=en_US
SendGrid: https://sendgrid.com/docs/glossary/spf/
MailChimp: https://mailchimp.com/help/set-up-custom-domain-authentication-dkim-and-spf/
MailGun: https://mxtoolbox.com/c/outboundemailsources?public=Mailgun
Amazon SES: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-authentication-spf.html
Constant Contact: https://knowledgebase.constantcontact.com/articles/KnowledgeBase/34717-SPF-Self-Publishing-for-Email-Authentication?lang=en_US
如果你是组织的营销部门或是大规模营销公司,并且已经了解发件人策略框架(SPF)、域名密钥识别邮件(DKIM)和基于域的消息认证、报告和一致性(DMARC)的绝对优势:现在可以停止了。这不是为你准备的。你已经知道我要说什么。
底线: 这取决于个别服务器配置,但一般来说,你越能向收件人邮件服务器证明邮件的有效性、授权性和意图性,邮件就越可能进入收件箱。
如果你不明白我刚才说的,准备好开始旅程: 你的大规模营销邮件进入我的收件箱,并不是因为你绕过了我们的垃圾邮件识别系统,而是因为我们客户的邮件服务器有时配置错误,我们不想错过客户的重要邮件。在BHIS,一些本应进入垃圾邮件的邮件会被发送到我们的收件箱并“标记”,以提醒我们的员工需要进行额外审查,因为有些问题,我们对邮件的来源表示怀疑。
免责声明: 本博客使用“认证”、“授权”和“审查”这些词有些宽松,以表示与SPF、DKIM和DMARC验证相关的流程和结果。在这种情况下,这些定义是类似的,并不与信息安全通常定义的方式一致。假设未认证、未授权、未审查、不可信是不受欢迎的。
让我们谈谈邮件授权
在过去,邮件被所有人信任。还记得从[email protected]发送邮件很有趣吗?好吧……算了。
黑客会钓鱼吗?
是的,黑客会钓鱼。
如今,邮件有一个问题:大量垃圾邮件、钓鱼、恶意行为、恶作剧等。不良意图的不可信后果是,今天的邮件服务已经迁移到一种新的默认期望,即邮件应在投递前进行审查。这也是一个良好的趋势,但这意味着邮件现在需要提供更多关于如何发送的信息,以证明其意图和授权。
新规范: 不可信的邮件不值得信任。 或者 未授权的邮件不被授权。 或者…… 请提供凭证……
我们并不是说未认证、未审查的邮件会消失。然而,我们说的是,邮件可以自带的授权和来源将增加其成功投递的可能性。
邮件提供商提供保护最终用户免受各种不良意图威胁的服务变得重要。并非所有邮件都是威胁,但有些是。即使对人类来说,区分它们也可能很困难。存在一些协议,允许邮件服务器在投递过程中验证邮件的真实性和授权性。邮件平台已经开始依赖这些协议进行垃圾邮件识别,这是一件好事。
在过去,大规模营销不太需要担心意图、授权或验证。所有邮件都能很好地投递。今天:并非如此。在威胁情报源、拒绝列表和大规模垃圾邮件操作之间,营销人员需要一种方法来确保他们可以通知投递服务器他们的邮件不是垃圾邮件,即使邮件包含触发词如“存款”、“账号”或“阿尔及利亚国王的初级财务秘书”。
这就是SPF、DKIM和DMARC发挥作用的地方。SPF和DKIM平台提供了一种机制,让域名的注册人(域管理员)授权(信任/授权)哪些邮件服务器被允许在邮件头(如发件人邮件地址)中指示其域名。此外,DMARC提供了强制执行SPF和DKIM的方法,以及报告合规指标和记录授权邮件活动的机制。
发件人策略框架(SPF)
发件人策略框架(SPF)包括一个DNS记录,管理员可以将其添加到其域的区域文件中,以及一个协议,指示收件人邮件服务器验证发件邮件服务器使用指定域名的授权。
我们之前讨论过这个:
如何为大众配置SPFv1 [https://www.blackhillsinfosec.com/how-to-configure-spfv1-explained-for-the-masses/]
使用SPF自动化反钓鱼侦察:https://www.blackhillsinfosec.com/offensive-spf-how-to-automate-anti-phishing-reconnaissance-using-sender-policy-framework/
深入探讨:
RFC 4408 [https://tools.ietf.org/html/rfc4408](已过时)
RFC 6652 [https://tools.ietf.org/html/rfc6652]
RFC 7208 [https://tools.ietf.org/html/rfc7208]
域名密钥识别邮件(DKIM)
DKIM是一种公钥基础设施,包括两个密钥。第一个密钥输入到域名的区域文件中供公共访问。然后,邮件服务器在外发邮件中通过名称引用此密钥。第二个密钥(私钥)存储在邮件服务器上,用于对邮件各个组件的计算哈希进行加密签名。
符合DKIM的邮件包括一个邮件头(元数据),提供DKIM私钥的匹配公钥名称、邮件的计算哈希、加密签名的哈希以及处理验证签名哈希的指令。邮件哈希的比较和加密签名哈希的验证决定了邮件的DKIM验证。
深入探讨
RFC 6376 – DKIM: https://www.ietf.org/rfc/rfc6376.txt
基于域的消息认证、报告和一致性(DMARC)
DMARC是一种协议,指示收件人邮件服务器在SPF和DKIM缺失或无效时该怎么做。DMARC还提供了一种方法,让收件人邮件服务器向指定的域所有者报告当前的邮件趋势,包括潜在的恶意活动。这可以有效地关闭对手在域所有者不知情的情况下发送未授权邮件的漏洞。
深入探讨:
Dmarc技术规范:https://dmarc.org/resources/specification/
RFC 7489 DMARC: https://tools.ietf.org/html/rfc7489
RFC 8553 支持DNS更改:https://tools.ietf.org/html/rfc8553
RFC 7960 DMARC的互操作性:https://tools.ietf.org/html/rfc7960
RFC 6591 失败报告格式:https://tools.ietf.org/html/rfc6591
RFC 8601 认证的邮件头字段:https://tools.ietf.org/html/rfc7601
好吧,那到底是怎么回事?
如果你使用大规模邮件平台,并且没有努力通过SPF和DKIM授权该邮件平台,并在DMARC中创建规则集,那么整个收件箱送达率将不取决于你的营销努力,而是取决于收件人邮件服务器处理“未授权”邮件的配置。未审查的邮件实际上是未审查的……如果你花了钱制作有效的邮件活动,请确保你花了时间确保它能进入收件箱。
营销热门提示: 设置SPF、DKIM和DMARC。 这将花费你不到半小时的时间,你的收件箱送达率将会提高。
什么!?你想要演示? 好吧。
邮件授权验证的病理学
在这里,我从我的BlackHillsInfoSec.com邮件地址发送了一封邮件到我的DefensiveOrigins.com邮件账户。在我的Defensive Origins账户中,我打开了邮件的完整源,包括由各种起源、传输和目的地邮件服务器附加的特定邮件头。
发送时:
接收时:
接收邮件中包含的邮件头是我们开始调查邮件验证过程如何展开的地方。让我们从SPF开始。
发件人策略框架解剖
SPF在DKIM之前就存在了。收件人邮件服务器首先检查SPF记录并不是绝对的,但可以合理假设大多数收件人邮件服务器会根据SPF标准验证邮件服务器的授权。让我们看看我发送给自己的邮件。
记住,这封邮件来自blackhillsinfosec.com。
我们可以使用MXToolbox或自己查询DNS来检查BlackHillsInfoSec.com的SPF记录。我们稍后将运行DNS查询,但让我们看看MXToolbox快速将SPF语法解码为通用语言的能力。MXToolbox是快速读取SPF记录的好工具。
这里重要的是Black Hills的SPF记录中的SPF include:_spf.google.com方法。include方法指示收件人邮件服务器查询_spf.google.com的SPF记录,并将其包含在blackhillsinfosec.com的SPF记录中。正如我们稍后将看到的,_spf.google.com记录还包含了更多SPF记录。在SPF记录中添加include方法时一定要非常小心,你可能会授权比你想象的更多。列表可以很快增长。
BlackHillsInfoSec.com的域管理员期望(SPF通过DNS记录授权)指示blackhillsinfosec.com的邮件来自相关的Google邮件服务器。我提到过BlackHillsInfosec.com使用GSuite(Google Suite)吗?
在我的DefensiveOrigins账户接收的邮件中,收件人邮件服务器包含了关于发件邮件服务器的信息。下面的头指示邮件由引用为mail-ed1-f53.google.com的邮件服务器发出。
通过一些DNS查询,我们可以追踪这是否根据BlackHillsInfoSec.com的SPF记录进行了SPF验证。
使用include SPF方法来验证发件Google邮件服务器。我们使用“nslookup”手动验证了邮件是通过SPF授权的服务器发送的。Defensive Origins邮件服务器得出了相同的结论,并在接收邮件的附加邮件头中记录了授权结果,该头名为Received-SPF。此头在RFC 7208 [https://tools.ietf.org/html/rfc7208]中定义。
收件人邮件服务器还在名为“Authentication-Results”的邮件头中包含了各种验证检查的摘要。这是认证过程的摘要。此头在RFC 7601[https://tools.ietf.org/html/rfc7601]中定义(被RFC 8601[https://tools.ietf.org/html/rfc8601]取代)。
恭喜: SPF验证成就徽章
接下来:公钥基础设施和邮件授权。
DKIM签名验证
Black Hills还有DKIM验证,通过使用邮件内容(部分)的加密签名来授权邮件服务器。这允许收件人邮件服务器验证特定邮件头和邮件正文内容未被篡改,并验证邮件由BlackHillsInfosec.com的域管理员授权。
DKIM使用公钥基础设施(PKI)。 邮件管理员创建符合DKIM的密钥对。一个密钥(私钥)存储在邮件服务器上,用于对特定邮件组件的计算哈希进行加密签名。公钥发布在公共DNS中,位于指定域名的特殊子域中。不建议为多个服务器重复使用密钥对。DKIM允许多个密钥对的使用。
当发送带有DKIM签名的邮件时,发件邮件服务器将包括一个邮件头,指示使用哪个DNS DKIM公钥来验证邮件的加密签名哈希。DKIM公钥的选择称为“选择器”。选择器指示收件人邮件服务器查询哪个DNS记录以获取DKIM公钥。DKIM公钥通过DNS TXT查询[selector]._domainkey.domain.tld获取。在DNS TXT记录上找到的公钥用于验证DKIM授权邮件头中包含的加密签名。计算邮件哈希的比较和加密签名的验证决定了邮件是否被DKIM授权。
在我从BlackHillsInfosec.com发送的邮件中,发件邮件服务器包含了DKIM-Signature邮件头。此头在RFC 6376 [https://tools.ietf.org/html/rfc6376]中定义,包括加密签名的哈希以及收件人邮件服务器创建哈希和验证签名的指令。
上面的邮件头指示我们使用:
v=1 DKIM协议版本一
a= 哈希算法
c= 哈希输入方法(考虑传输中的头修改)
s= 公钥选择器
h= 已在b=中签名的头
bh = 正文部分哈希(根据“c=”)[base64]
b= 正文/头的加密签名哈希
发件邮件服务器使用其DKIM私钥对正文(bh=[哈希])的哈希值进行加密签名,并存储签名哈希(b=哈希/签名)。此过程在RFC-6376第3.7节中详细说明,但最终输出是一个可以用DKIM公钥验证的签名。
收件邮件服务器分析DKIM邮件头后,开始了其DKIM验证过程。它使用参数“a=”、“c”和“h=”的信息来计算邮件组件的哈希。然后将哈希与参数“bh”中提供的值进行比较。如果哈希匹配,验证过程继续。如果哈希不匹配,DKIM验证失败。
然后,收件邮件服务器查询DNS,使用DKIM头中指定的域和选择器检索DKIM公钥。
d=blackhillsinfosec.com
s=google
[代码]
dig google._domainkey.blackhillsinfosec.com txt
; «» DiG 9.11.3 «» google._domainkey.blackhillsinfosec.com txt
;; ANSWER SECTION:
google._domainkey.blackhillsinfosec.com. 1800 IN TXT “v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBi
QKBgQCVxOyLCpVSrOzHZxkQciLBVhOkDYeMoM0A9A/NVUERAgXA7HDnP8c63tCrq8aKOv
KwcTAXF1EV+BSNQcneCmG/QX9oWPuTBvkX2J
wG0oRt/oP155KcJBbdczO9mmOwnFxTgiIiuF6oYT92cvcNT6zUh4QtvFmypMkIGrEZeGF9oQI
DAQAB”
[/代码]
然后服务器使用DKIM公钥验证签名哈希(=b)。使用公钥验证加密签名,邮件被视为DKIM授权。如果签名哈希无法验证或公钥无法检索,邮件将失败DKIM授权。
DKIM验证过程后,收件邮件服务器在Authentication-Results头中包含了DKIM验证结果。
恭喜! DKIM验证成就。
在验证的这一点上,我们已经确认邮件是通过SPF授权的邮件系统发送的,并且邮件使用DKIM签名来验证投递和特定未修改内容在发件邮件服务器、传输服务器和投递服务器之间。但是,如果不是这种情况呢?这就是DMARC发挥作用的地方!
提问时间!
如果邮件包含DKIM签名但DKIM验证失败会发生什么?
如果SPF验证了邮件服务器,但DKIM签名缺失会发生什么?
如果DKIM签名验证成功,但SPF指示邮件服务器未授权会发生什么?
管理员能否在有人发送授权邮件时收到通知?
管理员能否在有人发送未授权邮件时收到通知?
所有这些问题和相关问题都通过使用DMARC解决。与SPF和DKIM类似,DMARC是指定邮件域的域区域文件中分配的DNS TXT记录。DMARC记录指示收件人邮件服务器如何根据SPF和DKIM协议的结果处理接收的邮件,并提供创建反馈循环的额外指令,通知管理员指定域的邮件使用情况。
我们的示例邮件是从BlackHillsInfosec.com发送的。收件人邮件服务器查询了BlackHillsInfoSec.com域的DMARC DNS记录。DNS记录指示收件人邮件服务器如何根据其SPF和DKIM结果处理邮件。
DMARC DNS记录分配给名为_dmarc的特殊子域。在我们的案例中,收件人邮件服务器查询了_dmarc.blackhillsinfosec.com的TXT记录。
[代码] C:>nslookup -type=txt _dmarc.blackhillsinfosec.com Non-authoritative answer: _dmarc.blackhillsinfosec.com text =
"v=DMARC1; p=none; rua=mailto:[email protected];
ruf=mailto:[email protected]; fo=1" [/代码]
上面的BHIS Dmarc记录指示邮件服务器该txt记录是有效的DMARC txt记录。BHIS记录指示收件人邮件服务器根据此DMARC配置处理邮件:
v=DMARC1 DMVARC v1 有效TXT记录
p= none 如果邮件验证失败,不执行额外操作
Rua = 发送聚合邮件数据到[email protected]
Ruf = 发送失败取证报告到[email protected]
fo=1 在SPF或DKIM未通过时发送取证
邮件成功通过SPF和DKIM验证后,根据DMARC规则集处理,并投递给预期收件人。然而,这并非没有成为根据DMARC记录发送的聚合报告的一部分。
恭喜! DMARC验证徽章!
关于那些DMARC报告
你可能会问一个问题: 到底有多少邮件发送到我们在DMARC记录中指定的通知地址?嗯,关于符合DMARC的邮件服务器,我们得到:
每个收件邮件服务器每个指定域每天1封聚合邮件
每封未授权邮件投递1封取证报告。
这里的数学实际上是BHIS每天发送邮件的域数量 + BHIS未发送邮件但收到指示BHIS为起源域的邮件的域 + 授权邮件的取证报告。值得注意的是,并非所有收件邮件服务器都发送未授权邮件的取证报告,但通常会在其聚合报告邮件中包含失败结果。
你可能会想……这不是很多关于邮件的邮件吗?你们真的读那些吗? 是的,有点。这是我们从未阅读的大量邮件。全是自动化的。 下次当我们问“嘿,那波无效邮件发送的峰值是什么?”时,会有更多内容。
总之,这是一个关于一行邮件的长故事。 现在,让那些邮件进入我的收件箱(不被标记)并开始赚钱 🙂
博客后闲聊:为什么这个博客存在
每天我都会收到来自各个行业公司的邮件,试图销售他们的产品。在BHIS,我们已经习惯了非传统营销,专注于客户和社区关系,而不是大规模邮件。但我们并不贬低——我们的业务方式与他人不同——我们的非典型策略并不适合所有人,而且它们也有自己的痛苦故事和问题。
传统营销仍然重要,当我们看到我们的竞争对手(实际上是朋友)可能犯下代价高昂的错误时,我们想提供帮助。
在BHIS,我们有一个座右铭:“为资本主义感到自豪地糟糕。”
有时做正确的事根本无利可图。 这个博客可能就是这样的情况。写这个博客肯定不止五分钟,编辑被分配