发件人策略框架 (SPF)：电子邮件基础架构中的一层保护
已发表: 2020-03-04您是否曾经有人（开玩笑或恶意）拿走您的手机并假装是您给某人发短信？ 感觉不是很好，是吗？ 即使你和收件人讲清了真相，他们以后也很可能对你所有的短信保持警惕。 你可能会更加小心你让谁借你的手机。 信任已被打破。
在电子邮件世界中也可能出现类似的情况，潜在的网络钓鱼者不需要您的用户名和密码来冒充您的企业。 可怕，对吧？
幸运的是，我们知道一个简单的、不那么秘密的技巧来保护您的品牌声誉。 它称为发件人策略框架 (SPF)，是电子邮件信誉的救星。
当电子邮件从一台服务器发送到另一台服务器时，使用简单邮件传输协议 (SMTP) 将消息从发件人发送到收件人。 作为 SMTP 服务，Twilio SendGrid 促进了这一过程。
电子邮件基础设施中的一个安全漏洞是任何发件人或主机都能够将自己和他们的电子邮件标识为他们想要的任何域（有点像人们如何创建大量唐纳德特朗普 Twitter 帐户）。 这使得接收者很难相信一条消息实际上来自它所说的来自谁。 这也让发件人感到不安，因为他们知道那里的任何人都可以从他们的域发送邮件并可能损害他们的品牌声誉。
收件人对电子邮件的真实性失去信任，发件人是偏执的冒名顶替者，冒充他们的品牌——对任何人都不利！ 解决方案的一部分是存储在 DNS 中的 txt 记录中的 SPF 记录。 在本文中，我们将探索 SPF 的所有内容——从它是什么到发现自己的错误，我们将涵盖所有内容。
什么是 SPF 记录？
SPF 代表发件人策略框架。 这是一种电子邮件身份验证方法，可帮助识别允许从特定域发送电子邮件的邮件服务器。 使用此验证协议，ISP 可以确定欺骗者和网络钓鱼者何时试图从您的域中伪造电子邮件以向您的用户发送恶意电子邮件。
使用 SPF，收件人可以确信他们收到的电子邮件来自他们所期望的人。 发件人可以高枕无忧，因为他们知道网络钓鱼者不会通过电子邮件欺骗或从他们的品牌中对受众进行网络钓鱼。
从技术上讲，SPF 记录是域管理员添加到其 txt 记录中的短行文本。 txt 记录与它们的 A、PTR 和 MX 记录一起存储在 DNS（域名系统）中。 SPF 记录如下所示：
“v=spf1 ip4:12.34.56.78 包括：example.com -all”
SPF 的工作原理
上面的文本行用于告诉接收 SMTP 服务器允许哪些主机从给定域发送邮件。
SPF 记录通常在 SMTP 会话的早期检查，远在邮件正文传输之前。 当尝试发送消息时，发送方和接收服务器之间会打开一个 TCP 连接。
建立连接后，会发出 HELO 命令，该命令实质上会告诉接收服务器哪个域正在尝试向其发送邮件。 随后是一个 MAIL FROM 命令，该命令告诉接收服务器邮件来自哪个电子邮件地址。 在 MAIL FROM（也称为信封发件人和返回路径）命令中找到的域是用于 SPF 记录检查的域。
所以假设收到了一条消息，MAIL FROM 地址是[email protected]。 接收服务器将检查 example.com 的公共 DNS 记录并查找以 v=spf1 开头的 TXT 记录。 如果没有以 v=spf1 开头的 TXT 记录，则认证通过。 如果存在多个 v=spf1 的 TXT 记录，则可能会发生错误。
假设找到一个，它看起来像我们之前的示例：
“v=spf1 ip4:12.34.56.78 包括：example.com -all”
接收服务器现在将检查尝试发送邮件的 SMTP 客户端的 IP 地址是否包含在 SPF 记录中。 如果列出了 IP 地址，则消息将通过 SPF 身份验证。
细节：分解 SPF 记录的每一部分
SPF 记录由各种机制组成，包括：
包括
后面总是跟一个域名。 当接收服务器遇到包含机制时，会检查该域的 SPF 记录。 如果发件人的 IP 出现在该记录中，则邮件通过身份验证并且 SPF 检查结束。 如果未找到，则 SPF 检查将继续进行下一个机制。
一种
后面还有一个域名。 但是在这种情况下，SPF 只是检查与该域关联的 IP 地址。 如果它与发件人的 IP 匹配，则它通过，并且 SPF 检查停止。 如果不是，它会转到下一个机制。
MX
类似于“A”。 它后面总是跟一个域名。 如果列出的域解析为发送客户端的 IP 地址，则身份验证通过，并且 SPF 检查完成。 如果不是，它会转到下一个机制。
IP4 和 IP6
后面总是跟一个特定的 IP 地址或 CIDR 范围。 如果发送客户端的 IP 列在任何 IP4 或 IP6 机制之后，则身份验证将通过并完成 SPF 检查。 如果不是，它会转到下一个机制。
PTR
绝不应包含在 SPF 记录中。 由于某些技术原因，它们容易出错，并且要花费大量的内存和带宽来接收服务器来解决。 基于 PTR 机制的存在，某些服务器将无法通过 SPF 身份验证。
重定向
虽然从技术上讲是一种修饰符，而不是一种机制，但它允许域管理员将域指向另一个域的 SPF 记录。 如果使用 REDIRECT 功能，则 SPF 记录中不能包含其他机制，包括“all”机制。 重定向记录示例：“v=spf1 redirect:example.com”
“INCLUDE”、“A”、“MX”、“PTR”、“EXISTS”和“REDIRECT”机制都需要 DNS 查找，因此不能超过 10 个。 这看起来很简单，但这也包括嵌套的 DNS 查找，这意味着导致另一个 SPF 记录的“包含”具有另外两个“包含”机制将被视为三个 DNS 查找。 他们加起来很快！
Twilio SendGrid 客户呢？
我们的大多数发件人都设置了一个 CNAME，将他们的发送域指向 sendgrid.net。 这意味着接收服务器看到指向 sendgrid.net 的 CNAME，并改为检查该 SPF 记录。 因此，如果您查询的大多数 SPF 记录都相同，请不要感到惊讶。
有关更多 Twilio SendGrid 特定问题，请查看我们的发件人策略框架文档页面。 它对一些常见问题和场景有额外的答案。
如何查看我的 SPF 记录？
不是每个人都使用 SPF 身份验证，但是基于 SPF 失败而拒绝的接收者将拒绝交付。 一些收件人还可以隔离未通过 SPF 的邮件而不阻止它。
每条 SPF 记录都会有所不同，但您应该检查以确保正确无误。 以下三个工具可以帮助验证您的记录：
- Scott Kitterman 的 SPF 测试工具：检查您的域是否已经存在 SPF 记录，检查其有效性或测试其性能。
- OpenSPF.org ：查看一系列表单和基于电子邮件的测试人员。
- SPF 记录检查： SPF 记录检查充当 SPF 记录查找和验证器。 它将查找查询域名的 SPF 记录，并对记录运行诊断测试，突出显示可能影响电子邮件送达率的错误。
- SPF 向导：SPF 向导是一个基于浏览器的 SPF 记录生成工具。 填写表格，网站会为您生成 SPF 记录。
将发件人政策框架作为优先事项
简而言之，恶意电子邮件会损害您的业务并降低电子邮件渠道。 当网络钓鱼者看到您的发件人策略框架保护的域时，他们更有可能转向更容易的目标。 虽然 SPF 无法阻止垃圾邮件，但它可以起到威慑作用，让您不易受到攻击。 谁不想那样，对吧？ 这就是我们鼓励所有电子邮件客户端创建 SPF 记录的原因。
结合发件人 ID、DKIM 和 DMARC，SPF 提供了额外级别的电子邮件安全性，通过帮助 ISP 正确识别您的电子邮件以及垃圾邮件发送者，将更好地支持您的用户。