SPF 认证：概述与最佳实践

鸟

2016年12月19日

电子邮件

1 min read

SPF 认证：概述与最佳实践

关键要点

    • SPF (Sender Policy Framework) 是一种基于路径的电子邮件认证协议，用于验证发送服务器是否被授权为某个域发送邮件。

    • SPF 策略以DNS TXT 记录形式存在，格式包含定义哪些服务器、IP 或网络被允许代表某个域发送邮件的机制。

    • SPF 验证与Return-Path 域（退信域）或HELO 主机名相关，而不是可见的发件人地址。

    • 由于 SPF 仅检查发送路径，它可以在SMTP 事务中早期进行验证，从而可用于快速拒绝未授权邮件。

    • SPF 是有效的，但并不完美——它容易出现误报问题，尤其在邮件转发和邮件列表的情况下。

    • SPF 记录依赖于类似 mx、a、ipv4、ipv6、include、redirect、exists 的机制，并且必须以 all 修饰符(-all, ~all, ?all, +all) 结束。

    • DNS 查询限制适用：SPF 评估不能超过 10 个 DNS 查询，因此记录规划很重要。

    • ptr 机制现在被认为是“不可使用”，但验证器仍然必须接受它。由于兼容性问题，一些发送者仍在使用它。

    • 仅靠 SPF 不能保证邮件是合法的——它只是保证邮件来自授权的服务器。它在与 DKIM、DMARC 和其他防欺诈技术结合使用时效果最佳。

Q&A 精华

  • SPF是什么的简单说法？

    SPF允许一个域声明哪些服务器被允许以其名义发送电子邮件。接收服务器检查这一点以检测未经授权的发件人。

  • 为什么SPF被称为“路径为基础”？

    因为SPF验证了路径（具体来说，是发送服务器的IP），而不是消息内容中的任何内容。

  • SPF政策存储在哪里？

    A: 作为一个DNS TXT 记录，以v=spf1开始，后跟定义允许发件人的机制。

  • SPF 验证哪个域？

    The Return-Path（也称为退回域）。

    如果 Return-Path 为空（NULL 发件人），SPF 将检查HELO域。

  • SMTP 交易中能否提前检查 SPF？

    是的。因为它仅依赖于发送服务器的IP和域，SPF可以在接收消息正文之前进行验证——使其在过滤时更有效。

  • 为什么SPF有时即使对于合法邮件也会失败？

    常见原因包括：

    • Email forwarding（转发者未在原始域的SPF记录中）

    • Mailing lists（邮件由不同的服务器重新发送）
      这会导致误报，这是路径认证固有的问题。

  • 机制如include、redirect和exists的作用是什么？

    • include — 授权另一个域的SPF记录 (例如，您的ESP)

    • redirect — 重用另一个域的SPF策略

    • exists — 基于DNS查找动态授权 (对于复杂的基础设施很有用)

  • “all” 修饰符如何工作？

    • -all → 拒绝未列出的任何内容（严格）

    • ~all → 软失败（接受但标记）

    • ?all → 中立

    • +all → 通过所有（有效禁用SPF）

  • 为什么不建议使用ptr机制？

    它在现代规范中已经缓慢、不可靠并且已被弃用，但SPF验证器仍然必须支持它。

  • 仅靠SPF是否足够进行电子邮件身份验证？

    不，SPF验证发送基础设施，但：

    • 它不保护消息完整性

    • 它与可见的发件人域不一致

    • 它在转发时发生故障
      当与DKIM和DMARC结合使用时，SPF最强。

在深入了解技术实施之前，值得了解电子邮件验证技术的演变和种类。从简单的语法检查到现代的数据驱动方法，不同的验证方法提供不同程度的准确性和可靠性。

当我们谈论“Email Authentication”时，我们指的是一种技术，旨在使消息接收者对消息确实来源于声明的消息源有一定程度的确定性。其目的是达到一定程度的防御，例如钓鱼和欺骗邮件，这可能会削弱接收者接收电子邮件的信任。对于需要超出身份验证的消息级加密的组织，S/MIME提供了端到端的安全性，自动收件人公钥收集使实现更具可扩展性。尽管如此，发送经过身份验证的邮件这一行为本身并不能断言邮件是好的或被需要的；这仅意味着可以可靠地建立和使用经过身份验证的实体的信誉，以做出电子邮件接收和放置决定。

目前使用的两种主要电子邮件身份验证形式是—Sender Policy Framework (SPF) 和DomainKeys Identifed Mail (DKIM)。 在这篇博客文章中，我将解释什么是SPF及其工作原理。

在深入了解技术实施之前，值得了解电子邮件验证技术的演变和种类。从简单的语法检查到现代的数据驱动方法，不同的验证方法提供不同程度的准确性和可靠性。

当我们谈论“Email Authentication”时，我们指的是一种技术，旨在使消息接收者对消息确实来源于声明的消息源有一定程度的确定性。其目的是达到一定程度的防御，例如钓鱼和欺骗邮件，这可能会削弱接收者接收电子邮件的信任。对于需要超出身份验证的消息级加密的组织，S/MIME提供了端到端的安全性，自动收件人公钥收集使实现更具可扩展性。尽管如此，发送经过身份验证的邮件这一行为本身并不能断言邮件是好的或被需要的；这仅意味着可以可靠地建立和使用经过身份验证的实体的信誉，以做出电子邮件接收和放置决定。

目前使用的两种主要电子邮件身份验证形式是—Sender Policy Framework (SPF) 和DomainKeys Identifed Mail (DKIM)。 在这篇博客文章中，我将解释什么是SPF及其工作原理。

在深入了解技术实施之前，值得了解电子邮件验证技术的演变和种类。从简单的语法检查到现代的数据驱动方法，不同的验证方法提供不同程度的准确性和可靠性。

当我们谈论“Email Authentication”时，我们指的是一种技术，旨在使消息接收者对消息确实来源于声明的消息源有一定程度的确定性。其目的是达到一定程度的防御，例如钓鱼和欺骗邮件，这可能会削弱接收者接收电子邮件的信任。对于需要超出身份验证的消息级加密的组织，S/MIME提供了端到端的安全性，自动收件人公钥收集使实现更具可扩展性。尽管如此，发送经过身份验证的邮件这一行为本身并不能断言邮件是好的或被需要的；这仅意味着可以可靠地建立和使用经过身份验证的实体的信誉，以做出电子邮件接收和放置决定。

目前使用的两种主要电子邮件身份验证形式是—Sender Policy Framework (SPF) 和DomainKeys Identifed Mail (DKIM)。 在这篇博客文章中，我将解释什么是SPF及其工作原理。

SPF 概览

发送方策略框架 (SPF)，引用RFC 7208，是一种协议，不仅允许组织授权主机和网络在发送电子邮件时使用其域名，还提供了一种接收主机可以检查该授权的方法。

当你读完这篇文章后，希望你能了解到以下内容：

  • SPF是一个“路径式”认证系统。

  • SPF策略在DNS TXT记录中声明。

  • 验证与Return-Path域（我们在SparkPost称之为“退回域”）或HELO域相关。

  • 验证可以在SMTP事务早期进行，因此是快速拒绝未经认证邮件的良好检查。

  • 它容易出现相对高比例的误判。

发送方策略框架 (SPF)，引用RFC 7208，是一种协议，不仅允许组织授权主机和网络在发送电子邮件时使用其域名，还提供了一种接收主机可以检查该授权的方法。

当你读完这篇文章后，希望你能了解到以下内容：

  • SPF是一个“路径式”认证系统。

  • SPF策略在DNS TXT记录中声明。

  • 验证与Return-Path域（我们在SparkPost称之为“退回域”）或HELO域相关。

  • 验证可以在SMTP事务早期进行，因此是快速拒绝未经认证邮件的良好检查。

  • 它容易出现相对高比例的误判。

发送方策略框架 (SPF)，引用RFC 7208，是一种协议，不仅允许组织授权主机和网络在发送电子邮件时使用其域名，还提供了一种接收主机可以检查该授权的方法。

当你读完这篇文章后，希望你能了解到以下内容：

  • SPF是一个“路径式”认证系统。

  • SPF策略在DNS TXT记录中声明。

  • 验证与Return-Path域（我们在SparkPost称之为“退回域”）或HELO域相关。

  • 验证可以在SMTP事务早期进行，因此是快速拒绝未经认证邮件的良好检查。

  • 它容易出现相对高比例的误判。

“Path-Based” Authentication

SPF 被认为是一种基于路径的身份验证系统，因为它仅与消息从起点到目的地的路径有关。当发送服务器与接收服务器启动 SMTP 事务时，接收服务器将根据域的 SPF 策略决定发送服务器是否被授权发送该消息。这完全是依据消息来源的决策，与消息内容无关。

SPF 被认为是一种基于路径的身份验证系统，因为它仅与消息从起点到目的地的路径有关。当发送服务器与接收服务器启动 SMTP 事务时，接收服务器将根据域的 SPF 策略决定发送服务器是否被授权发送该消息。这完全是依据消息来源的决策，与消息内容无关。

SPF 被认为是一种基于路径的身份验证系统，因为它仅与消息从起点到目的地的路径有关。当发送服务器与接收服务器启动 SMTP 事务时，接收服务器将根据域的 SPF 策略决定发送服务器是否被授权发送该消息。这完全是依据消息来源的决策，与消息内容无关。

声明一个SPF策略

一个域名的SPF策略记录仅仅是一个专门格式化的DNS TXT记录，通常包含以下一种或多种“机制”：

  • v=spf1 – 必须的第一个标识符，用于表明TXT记录是SPF记录（一个域名可以有多个TXT记录）

  • ipv4, ipv6 – 用于指定被允许为该域发送邮件的IP地址和网络

  • a – 如果发送域有一个DNS“A”记录解析到发送IP，则该IP被允许

  • mx – 如果发送IP也是发送域的MX记录之一，则该IP被允许

  • all – 必须的最后标识符，总是修改如下：

    • -all – 只有这里列出的可以通过；拒绝不符合的。

    • ~all – 这里没有的东西应该软失败；接受但记录说明。

    • ?all – 不确定这里没有的东西是否应该通过。

    • +all – 我们认为SPF无用；通行所有。

其他不太常见但仍然广泛使用的机制有：

  • include – 在域不仅有自己的服务器，还使用别人的服务器时使用。必须谨慎使用。每个include是另一个DNS查询，而SPF记录不能要求超过十个DNS查询来解析。

  • redirect – 当域A和域B由同一实体拥有并使用相同基础设施时使用。所有者通常想只维护一份SPF记录，并配置B来重定向查询到A。

  • exists – 如果一个域有很多小的、不连续的网络块，可以使用这种机制指定其SPF记录，而不是列出它们。帮助保持在DNS响应的大小限制（512字节）以内。

关于“ptr”机制的说明

最后一个机制，“ptr”在SPF的原始规范中存在，但在当前规范中已被宣布为“不使用”。ptr机制用于声明，若发送IP地址有一个DNS PTR记录解析到相关的域名，则该IP地址被授权为该域发送邮件。

该机制的当前状态是不应使用。然而，做SPF验证的站点必须接受该机制为有效。

一个域名的SPF策略记录仅仅是一个专门格式化的DNS TXT记录，通常包含以下一种或多种“机制”：

  • v=spf1 – 必须的第一个标识符，用于表明TXT记录是SPF记录（一个域名可以有多个TXT记录）

  • ipv4, ipv6 – 用于指定被允许为该域发送邮件的IP地址和网络

  • a – 如果发送域有一个DNS“A”记录解析到发送IP，则该IP被允许

  • mx – 如果发送IP也是发送域的MX记录之一，则该IP被允许

  • all – 必须的最后标识符，总是修改如下：

    • -all – 只有这里列出的可以通过；拒绝不符合的。

    • ~all – 这里没有的东西应该软失败；接受但记录说明。

    • ?all – 不确定这里没有的东西是否应该通过。

    • +all – 我们认为SPF无用；通行所有。

其他不太常见但仍然广泛使用的机制有：

  • include – 在域不仅有自己的服务器，还使用别人的服务器时使用。必须谨慎使用。每个include是另一个DNS查询，而SPF记录不能要求超过十个DNS查询来解析。

  • redirect – 当域A和域B由同一实体拥有并使用相同基础设施时使用。所有者通常想只维护一份SPF记录，并配置B来重定向查询到A。

  • exists – 如果一个域有很多小的、不连续的网络块，可以使用这种机制指定其SPF记录，而不是列出它们。帮助保持在DNS响应的大小限制（512字节）以内。

关于“ptr”机制的说明

最后一个机制，“ptr”在SPF的原始规范中存在，但在当前规范中已被宣布为“不使用”。ptr机制用于声明，若发送IP地址有一个DNS PTR记录解析到相关的域名，则该IP地址被授权为该域发送邮件。

该机制的当前状态是不应使用。然而，做SPF验证的站点必须接受该机制为有效。

一个域名的SPF策略记录仅仅是一个专门格式化的DNS TXT记录，通常包含以下一种或多种“机制”：

  • v=spf1 – 必须的第一个标识符，用于表明TXT记录是SPF记录（一个域名可以有多个TXT记录）

  • ipv4, ipv6 – 用于指定被允许为该域发送邮件的IP地址和网络

  • a – 如果发送域有一个DNS“A”记录解析到发送IP，则该IP被允许

  • mx – 如果发送IP也是发送域的MX记录之一，则该IP被允许

  • all – 必须的最后标识符，总是修改如下：

    • -all – 只有这里列出的可以通过；拒绝不符合的。

    • ~all – 这里没有的东西应该软失败；接受但记录说明。

    • ?all – 不确定这里没有的东西是否应该通过。

    • +all – 我们认为SPF无用；通行所有。

其他不太常见但仍然广泛使用的机制有：

  • include – 在域不仅有自己的服务器，还使用别人的服务器时使用。必须谨慎使用。每个include是另一个DNS查询，而SPF记录不能要求超过十个DNS查询来解析。

  • redirect – 当域A和域B由同一实体拥有并使用相同基础设施时使用。所有者通常想只维护一份SPF记录，并配置B来重定向查询到A。

  • exists – 如果一个域有很多小的、不连续的网络块，可以使用这种机制指定其SPF记录，而不是列出它们。帮助保持在DNS响应的大小限制（512字节）以内。

关于“ptr”机制的说明

最后一个机制，“ptr”在SPF的原始规范中存在，但在当前规范中已被宣布为“不使用”。ptr机制用于声明，若发送IP地址有一个DNS PTR记录解析到相关的域名，则该IP地址被授权为该域发送邮件。

该机制的当前状态是不应使用。然而，做SPF验证的站点必须接受该机制为有效。

一些示例SPF记录

以下是一些示例记录及其含义。此示例显示了 RFC 1918 地址，但我知道此类地址永远不会出现在真实的 SPF 记录中。

  • MX 记录，一个 IP 地址，一个 IP 网络，其余全部软失败：

    • “v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”

  • A 记录，两个 IP 网络，拒绝所有其他：

    • “v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”

  • 我们不发送邮件：

    • “v=spf1 -all”

  • 我们认为 SPF 很愚蠢：

    • “v=spf1 +all”

  • 域 sparkpostmail.com 的 SPF 记录 (使用重定向机制)：

    • “v=spf1 redirect=_spf.sparkpostmail.com”

  • _spf.sparkpostmail.com 的 SPF 记录（使用 exists 和 ptr 机制）：

    • “v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”

在 SparkPost，我们当前在 SPF 记录中使用 ptr 机制。我们发现，由于缺乏对验证 exists 机制的普遍支持，这是必要的。而且到目前为止，我们还未见因为使用 ptr 机制而导致的 SPF 失败。

以下是一些示例记录及其含义。此示例显示了 RFC 1918 地址，但我知道此类地址永远不会出现在真实的 SPF 记录中。

  • MX 记录，一个 IP 地址，一个 IP 网络，其余全部软失败：

    • “v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”

  • A 记录，两个 IP 网络，拒绝所有其他：

    • “v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”

  • 我们不发送邮件：

    • “v=spf1 -all”

  • 我们认为 SPF 很愚蠢：

    • “v=spf1 +all”

  • 域 sparkpostmail.com 的 SPF 记录 (使用重定向机制)：

    • “v=spf1 redirect=_spf.sparkpostmail.com”

  • _spf.sparkpostmail.com 的 SPF 记录（使用 exists 和 ptr 机制）：

    • “v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”

在 SparkPost，我们当前在 SPF 记录中使用 ptr 机制。我们发现，由于缺乏对验证 exists 机制的普遍支持，这是必要的。而且到目前为止，我们还未见因为使用 ptr 机制而导致的 SPF 失败。

以下是一些示例记录及其含义。此示例显示了 RFC 1918 地址，但我知道此类地址永远不会出现在真实的 SPF 记录中。

  • MX 记录，一个 IP 地址，一个 IP 网络，其余全部软失败：

    • “v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”

  • A 记录，两个 IP 网络，拒绝所有其他：

    • “v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”

  • 我们不发送邮件：

    • “v=spf1 -all”

  • 我们认为 SPF 很愚蠢：

    • “v=spf1 +all”

  • 域 sparkpostmail.com 的 SPF 记录 (使用重定向机制)：

    • “v=spf1 redirect=_spf.sparkpostmail.com”

  • _spf.sparkpostmail.com 的 SPF 记录（使用 exists 和 ptr 机制）：

    • “v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”

在 SparkPost，我们当前在 SPF 记录中使用 ptr 机制。我们发现，由于缺乏对验证 exists 机制的普遍支持，这是必要的。而且到目前为止，我们还未见因为使用 ptr 机制而导致的 SPF 失败。

SPF Authentication 如何运作？

以下是涉及 SPF 时典型的 SMTP 事务的样子：

  • 发送服务器（客户端）连接到接收服务器

  • 接收服务器记录客户端的连接 IP 地址

  • 他们交换问候，包括客户端的 HELO 主机名

  • 客户端发出 SMTP MAIL FROM 命令

接收服务器现在可以查找 MAIL FROM 域或 HELO 主机名的 SPF 记录，以确定连接 IP 是否被授权为该域发送邮件，并决定是否接受该消息。

以下是涉及 SPF 时典型的 SMTP 事务的样子：

  • 发送服务器（客户端）连接到接收服务器

  • 接收服务器记录客户端的连接 IP 地址

  • 他们交换问候，包括客户端的 HELO 主机名

  • 客户端发出 SMTP MAIL FROM 命令

接收服务器现在可以查找 MAIL FROM 域或 HELO 主机名的 SPF 记录，以确定连接 IP 是否被授权为该域发送邮件，并决定是否接受该消息。

以下是涉及 SPF 时典型的 SMTP 事务的样子：

  • 发送服务器（客户端）连接到接收服务器

  • 接收服务器记录客户端的连接 IP 地址

  • 他们交换问候，包括客户端的 HELO 主机名

  • 客户端发出 SMTP MAIL FROM 命令

接收服务器现在可以查找 MAIL FROM 域或 HELO 主机名的 SPF 记录，以确定连接 IP 是否被授权为该域发送邮件，并决定是否接受该消息。

MAIL FROM 或 HELO – 哪一个需要检查？

SPF规范规定接收站点必须检查MAIL FROM域，并建议检查HELO主机名。在实践中，只对MAIL FROM域进行检查，除了在MAIL FROM地址是空发送者（即“<>”）的时候，此时HELO主机名是唯一可用的身份。

SPF规范规定接收站点必须检查MAIL FROM域，并建议检查HELO主机名。在实践中，只对MAIL FROM域进行检查，除了在MAIL FROM地址是空发送者（即“<>”）的时候，此时HELO主机名是唯一可用的身份。

SPF规范规定接收站点必须检查MAIL FROM域，并建议检查HELO主机名。在实践中，只对MAIL FROM域进行检查，除了在MAIL FROM地址是空发送者（即“<>”）的时候，此时HELO主机名是唯一可用的身份。

SPF 并非万无一失

虽然这看起来是一种相对简单的电子邮件认证方式，但SPF容易出现形式为假阴性的失败。这些失败发生的频率可能比许多人能接受的要高。

以下是两个常见场景，其中完全合法的邮件可能无法通过SPF验证，因此看起来是欺诈的：

  • 自动转发，例如发送到jsmith@alumni.university.edu的邮件，自动转发所有邮件到jsmith@isp.com的邮箱

  • 邮件列表，例如发送到talk-about-stuff@listserv.foo.com的邮件被“扩展”并发送到每个订阅者

在这两种情况下，如果退回路径与原始邮件保持不变，邮件可能无法通过SPF检查（取决于使用的'all'机制的修饰符）。这是因为邮件从中间服务器而不是原始服务器到达最终目的地，而那个中间服务器不太可能在域的SPF记录中。一种称为“Sender Rewriting Scheme”或“SRS”的技术可以降低这种风险，一些大型网站采用了这种技术，但它并不普遍。

虽然这看起来是一种相对简单的电子邮件认证方式，但SPF容易出现形式为假阴性的失败。这些失败发生的频率可能比许多人能接受的要高。

以下是两个常见场景，其中完全合法的邮件可能无法通过SPF验证，因此看起来是欺诈的：

  • 自动转发，例如发送到jsmith@alumni.university.edu的邮件，自动转发所有邮件到jsmith@isp.com的邮箱

  • 邮件列表，例如发送到talk-about-stuff@listserv.foo.com的邮件被“扩展”并发送到每个订阅者

在这两种情况下，如果退回路径与原始邮件保持不变，邮件可能无法通过SPF检查（取决于使用的'all'机制的修饰符）。这是因为邮件从中间服务器而不是原始服务器到达最终目的地，而那个中间服务器不太可能在域的SPF记录中。一种称为“Sender Rewriting Scheme”或“SRS”的技术可以降低这种风险，一些大型网站采用了这种技术，但它并不普遍。

虽然这看起来是一种相对简单的电子邮件认证方式，但SPF容易出现形式为假阴性的失败。这些失败发生的频率可能比许多人能接受的要高。

以下是两个常见场景，其中完全合法的邮件可能无法通过SPF验证，因此看起来是欺诈的：

  • 自动转发，例如发送到jsmith@alumni.university.edu的邮件，自动转发所有邮件到jsmith@isp.com的邮箱

  • 邮件列表，例如发送到talk-about-stuff@listserv.foo.com的邮件被“扩展”并发送到每个订阅者

在这两种情况下，如果退回路径与原始邮件保持不变，邮件可能无法通过SPF检查（取决于使用的'all'机制的修饰符）。这是因为邮件从中间服务器而不是原始服务器到达最终目的地，而那个中间服务器不太可能在域的SPF记录中。一种称为“Sender Rewriting Scheme”或“SRS”的技术可以降低这种风险，一些大型网站采用了这种技术，但它并不普遍。

Wrap Up

这就是SPF身份验证，如何运作，如何声明SPF政策，以及使用SPF时的陷阱。SPF是首个获得广泛采用的电子邮件身份验证方案，但并不是唯一的。SPF身份验证在与其他反欺诈技术结合使用时最为有效。

这就是SPF身份验证，如何运作，如何声明SPF政策，以及使用SPF时的陷阱。SPF是首个获得广泛采用的电子邮件身份验证方案，但并不是唯一的。SPF身份验证在与其他反欺诈技术结合使用时最为有效。

这就是SPF身份验证，如何运作，如何声明SPF政策，以及使用SPF时的陷阱。SPF是首个获得广泛采用的电子邮件身份验证方案，但并不是唯一的。SPF身份验证在与其他反欺诈技术结合使用时最为有效。

其他新闻

阅读更多来自此类别的内容

A person is standing at a desk while typing on a laptop.

完整的AI原生平台，可与您的业务一起扩展。

联系销售

免费开始

© 2025 Bird

联系 Support

A person is standing at a desk while typing on a laptop.

完整的AI原生平台，可与您的业务一起扩展。

联系销售

免费开始

© 2025 Bird

联系 Support

A person is standing at a desk while typing on a laptop.

完整的AI原生平台，可与您的业务一起扩展。

联系销售

免费开始

© 2025 Bird

联系 Support