Generate and validate SPF (Sender Policy Framework) records to prevent email spoofing.
生成并验证 SPF（发件人策略框架）记录，防止邮件伪造
Understanding SPF records and email authentication best practices
本页提供关于生成 SPF 记录的原创、经人工审校的内容，讲解机制选择、第三方发件服务的 include，以及如何将记录控制在 DNS 查询限制之内。
SPF (Sender Policy Framework) records are DNS TXT records that specify which mail servers are authorized to send emails on behalf of your domain. They help prevent email spoofing and improve email deliverability.
包含来自其他域名的 SPF 记录（邮件服务商最常用）
授权特定的 IPv4 地址或网段
授权域名 MX 记录中列出的所有服务器
SPF records are limited to 10 DNS lookups. Exceeding this limit causes SPF validation to fail.
解决方案：使用 SPF 扁平化或减少 include: 机制。
Having multiple SPF records in DNS causes all of them to be ignored.
解决方案：将所有 SPF 机制合并到一条 TXT 记录中。
SPF records longer than 255 characters may not be processed correctly.
解决方案：使用 SPF 扁平化或优化机制语法。
这些限定符决定了来自未授权服务器的邮件将如何处理：
SPF 记录更改通常会在 24-48 小时内传播生效，但根据 DNS TTL 设置，最长可能需要 72 小时。大多数更改会在几小时内生效。
不可以。每个域名只能有一条 SPF 记录。如果存在多条 SPF 记录，所有记录都会被忽略。如果需要授权多个邮件来源，请将它们合并到一条 SPF 记录中。
SPF 记录在验证时最多允许 10 次 DNS 查询。“include:”、“a”、“mx”、“exists”和“redirect”等机制都会计入此限制。超过 10 次查询会导致 SPF 验证失败。
对邮件服务商（如 Google、Microsoft）应使用“include”，因为它们的 IP 地址可能会变化。“ip4”只用于你自己的静态 IP 邮件服务器。
你可以使用以下工具测试 SPF 记录：
超过 255 个字符的 SPF 记录可能会被部分邮件服务器截断或忽略。建议使用 SPF 扁平化服务，或删除不必要的机制来优化记录，使其保持在限制以内。
