关于SPF记录部署、防钓鱼及多客户场景最佳实践的疑问
Great question—this is a super common pain point for multi-tenant email hosts, so let’s break this down into clear, actionable advice.
多客户托管场景下的SPF最佳实践
主域名必须配置基础SPF记录：哪怕你的主域名
domain.com本身不对外发送邮件，也要配置一个严格的最小SPF记录，比如：v=spf1 -all这会明确告诉邮件接收系统：没有任何服务器被授权以
domain.com的名义发送邮件，避免主域名被恶意利用。如果主域名需要发送内部邮件，可以调整为包含仅内部服务器的IP，比如v=spf1 ip4:10.0.0.0/24 -all。子域名SPF独立配置，严格限定发送源：每个客户的子域名（比如
customer1.domain.com）应该拥有独立的SPF记录，仅包含该客户授权的发送IP、邮件服务商或中继服务器。例如：v=spf1 ip4:192.168.1.10 include:spf.mailchimp.com -all这里的
-all表示拒绝所有未在记录中列出的发送源，是最严格的配置；如果需要过渡，也可以用~all（软拒绝，标记为可疑），但最终建议切换到-all。禁止子域名SPF引用主域名：绝对不要让客户的子域名SPF包含
include:domain.com——这不仅会增加SPF查询次数（SPF有最多10次查询的限制，超过会导致校验失效），还会埋下滥用隐患：如果某个客户的SPF配置被篡改，或者主域名的SPF后续变更，可能影响所有关联子域名的邮件投递。托管商统一规范与审计：作为托管商，应该为客户提供标准化的SPF配置模板，明确告知客户只能添加自身的发送源；同时定期审计所有子域名的SPF记录，发现违规配置（比如引用主域名、包含未知IP）及时通知客户修正。
针对中继域名SPF被滥用的接收方处理方式
如果你的中继域名SPF错误地设置为domain.com，导致其他客户可能伪造邮件，接收方可以通过以下方式防护：
严格执行SPF校验：当邮件声称来自
customer1.domain.com，但实际发送IP不在该子域名的SPF记录中时，接收系统会返回SPF fail（如果用了-all）。此时接收方通常会将邮件标记为垃圾邮件，或者直接拒绝投递，具体取决于邮件系统的过滤策略。结合DKIM与DMARC强化防护：SPF只验证发送IP，而DKIM通过数字签名验证邮件内容未被篡改，DMARC则可以指定SPF/DKIM校验失败后的处理规则。建议为每个子域名配置DKIM签名，并在主域名
domain.com设置DMARC记录，比如：v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@domain.com; ruf=mailto:dmarc-forensics@domain.com这里的
p=quarantine表示将校验失败的邮件隔离到垃圾邮箱，后续可以升级为p=reject直接拒绝；rua和ruf用于接收合规性报告，帮助你追踪滥用情况。基于发件人信誉的二次过滤：多数主流邮件系统会维护发件IP的信誉数据库，如果某IP频繁发送伪造子域名的邮件，会被标记为低信誉IP，后续来自该IP的邮件会被优先拦截或标记为垃圾。
内容的提问来源于stack exchange，提问作者user5016380
