SPF 记录是一种 DNS 记录，它主要指出哪些 IP/域被允许代表该域发送电子邮件。
当使用第三方电子邮件服务时，该服务通常建议对其所有服务器使用“catch-all”SPF 记录。Sendgrid 的建议如下：
v=spf1 include:sendgrid.net ~all
与此记录关联的域（例如 example.com）将“允许”来自所有 sendgrid.net 域的所有电子邮件。
在我看来，攻击者只需注册一个 Sendgrid 帐户并代表 example.com 发送电子邮件即可“通过”SPF 检查。
这是真的？
我知道 SPF 并非旨在验证消息的真实性。但在适当的情况下，如此广受赞誉的技术却存在如此容易被利用的弱点，这似乎有点奇怪。是的，我确实意识到从第三方电子邮件服务请求私有 IP 可以缓解这种担忧。
答案1
您提到的 DNS 记录显示：
我，该域名的所有者，相信 Sendgrid 将
From:验证全部留下的电子邮件全部SMTP 服务器在其 IP 池中，并且 Sendgrid 将阻止未经授权的内容。
这不是 RFC 所说的，但这是实际意义。
这就是 SPF 的架构。称其为缺陷虽然可以理解，但毫无建设性。确实，在 DMARC 保护下，SPF 仅作为 DKIM 失败时的后备机制（DKIM 在统计上往往容易出错）。事实上，批量邮件服务将 SPF 作为主要机制，通常根本不提及 DKIM，而且通常彻底失败授权标题From:说明了他们的无知核心业务。
面对这种情况，我总是建议使用 ，这可以在一定程度上减轻冒充 CEO、CFO、HR 等的影响。不过，无论谁想让我设置该域名记录，我总是要求他们接受风险。（我插入了他们 CEO 的真实姓名。他们通常会接受这一点。呵呵。）From: [email protected]From: [email protected]