中文 English

80元十年域名买完后，下一步就交给 Cloudflare

发布时间: 2026-05-13
Cloudflare DNS DDNS 域名 企业邮箱 Email Routing API Token Agent OpenClaw HermesAgent

先说结论

便宜域名买完只是第一步。真正能把这个域名玩起来的地方，是把它接到 Cloudflare：DNS 解析、动态 DDNS、企业邮箱验证、邮件转发、证书自动化、甚至让 OpenClaw / HermesAgent 这类 Agent 通过受限 API Token 帮你维护复杂配置，都可以从这里开始。前文已经讲了如何购买最便宜的 10 年 80 元 左右的 .xyz 域名，本文就接着讲：买完以后，怎么把它交给 Cloudflare 这个“互联网大善人”，并且尽量少走弯路。

本文所有截图和示例都使用 example.xyz、203.0.113.10、2001:db8::10 这类公开文档占位符，不包含真实域名、真实 IP、Cloudflare 账号、Zone ID、API Token 或任何内网信息。你照着做时，把占位符替换成自己的域名和服务地址即可。

把域名接入 Cloudflare 的总路线

图 1：买完域名后的高效利用路径：先接入 Cloudflare，再围绕 DNS、DDNS、邮箱和 Agent 自动化逐步扩展。

1. 为什么域名买完后第一站建议去 Cloudflare

很多人买域名时只盯着价格：哪里首年便宜，哪里十年总价低，哪里支持支付宝或银行卡。这个思路没错，尤其是 .xyz 这种经常能做到十年几十块、上百块以内的后缀，拿来做个人服务、Homelab、临时项目、内测系统、邮箱别名都很合适。但域名买完以后，如果继续使用域名商自带 DNS，经常会遇到几个现实问题：控制台慢，解析记录支持不完整，批量修改麻烦，API 不好用，DDNS 生态少，邮箱验证记录容易填错，后续想接 CDN、Workers、Zero Trust、证书自动化时又要搬家。

Cloudflare 的价值正好在这里。它不是只做 CDN，也不只是“橙云加速”。对普通用户来说，它更像一个免费的域名基础设施控制面：权威 DNS 免费，解析生效快，记录类型完整，API 成熟，文档清楚，Access / Workers / Pages / Email Routing 等服务可以按需慢慢用。你可以先只把它当 DNS 面板，等以后需求变复杂，再逐步打开其他能力。

当然，Cloudflare 不是神药。国内不同运营商、不同地区、不同时间访问 Cloudflare 相关服务的体验差异很大，有时非常顺，有时就比较抽象。这个不是本文能解决的问题，需要你自己准备好合适的网络环境，也就是俗称“魔法上网”。尤其是注册、登录、API 调试、Workers 管理台、部分文档访问这些操作，如果网络本身不稳定，排查 DNS 配置会变得非常痛苦。

所以本文的目标不是宣传 Cloudflare 多完美，而是给出一条务实路线：域名注册商只负责续费和所有权；Cloudflare 负责权威 DNS 和后续玩法；Agent 只拿最小权限 Token 做自动化；任何真实密钥都不写进文章、截图和公开仓库。

2. 先理解 NS：不是“加一条解析”，而是换权威 DNS

把域名接入 Cloudflare 的核心动作，是把域名的 Nameserver，也就是 NS 服务器，改成 Cloudflare 分配给你的两台服务器。很多新手会把它理解成“在域名商那里新增两条 NS 解析”，这通常是错的。我们要改的是域名注册商侧的“权威 DNS 服务器设置”，不是在 DNS 记录表里给根域名加 NS 记录。

可以把域名解析想象成一条问路链：用户访问 www.example.xyz，递归 DNS 先问根服务器，再问 .xyz 顶级域，顶级域告诉它“这个域名的权威 DNS 在哪几台 NS 上”，然后递归 DNS 再去问这些权威 NS，最终拿到 A、AAAA、CNAME、MX、TXT 等记录。也就是说，Cloudflare 想替你回答 example.xyz 的解析问题，前提是顶级域那里登记的权威 NS 已经指向 Cloudflare。

Cloudflare 官方文档里把这种方式称为 Full setup / Primary setup。它会给每个 zone 分配两台权威 nameserver。你需要把这两条值复制回域名商。域名如果是直接在 Cloudflare Registrar 购买的，通常会自动使用 Cloudflare DNS；但本文讨论的是“域名在别处买，DNS 放 Cloudflare 管”的情况。

3. 在 Cloudflare 添加域名并获取 NS 服务器

Cloudflare 添加站点示意截图

图 2：在 Cloudflare Dashboard 添加 example.xyz。这里是隐私安全的复刻示意截图，真实页面可能随官方 UI 更新略有变化。

操作步骤如下：

  1. 打开 https://dash.cloudflare.com/，登录 Cloudflare 账号。
  2. 进入 Domains 或 Websites，点击 Add a domain / Onboard a domain。
  3. 输入根域名，例如 example.xyz，不要写 www.example.xyz。
  4. 选择套餐。个人域名、入门 DNS、DDNS、邮箱转发玩法，通常 Free 计划已经够用。
  5. Cloudflare 可能会自动扫描已有 DNS 记录。刚买的新域名往往没有记录，直接继续即可；如果是老域名迁移，一定要核对已有 A、AAAA、CNAME、MX、TXT 记录，避免切 NS 后业务中断。

完成 onboarding 后，Cloudflare 会显示分配给这个域名的两条 NS。例如示意图里是：

arya.ns.cloudflare.com
brad.ns.cloudflare.com

注意，这两条只是示例。Cloudflare 会按账号和域名分配不同的 nameserver，你必须复制自己页面上看到的值。不要从教程里照抄别人的 NS，也不要只复制一条。

Cloudflare 获取 NS 服务器示意截图

图 3：Cloudflare 会在 onboarding 或域名 Overview 页面显示两条 nameserver。两条都要复制，且必须使用你自己账号里显示的值。

如果 onboarding 页面已经关掉，也可以进入对应域名的 Overview 页面重新查看。域名未激活时，Cloudflare 通常也会在页面上提示“等待你到注册商处更新 nameserver”。这不是报错，只是说明权威 NS 还没切过去。

4. 回到域名商，把 NS 改成 Cloudflare

域名商替换 Nameserver 示意截图

图 4：在域名购买平台把默认 nameserver 全部替换为 Cloudflare 给出的两条。不同域名商入口名称不同，常见叫 DNS 服务器、Nameserver、自定义 DNS。

接下来回到你买 .xyz 域名的平台，找到域名管理页面。不同注册商叫法不一样，但大概会有这些入口：

  1. Nameserver / Name Server
  2. DNS Server / DNS 服务器
  3. 自定义 DNS
  4. 修改 NS
  5. Change nameservers

进入后通常会看到域名商默认提供的两条或多条 NS。你要做的是选择“自定义 nameserver”，删除原有值，填入 Cloudflare 分配的两条。保存后等待生效。

这里有几个坑要避开：

  1. 不要混用 NS。 不要一条填 Cloudflare，一条保留域名商默认 NS。权威 DNS 混搭会导致部分地区解析到旧记录，部分地区解析到新记录，排查会非常难受。
  2. 不要把 NS 写到普通 DNS 记录里。 有些控制台既有 DNS 记录管理，又有 Nameserver 设置。你要改的是后者。
  3. DNSSEC 迁移时要谨慎。 如果旧域名商开启过 DNSSEC，迁移前后要按 Cloudflare 文档处理 DS 记录，否则可能出现解析验证失败。刚买的新域名通常没有这个问题。
  4. 等待 Pending 变 Active。 Cloudflare 检测到顶级域 NS 指向自己后，zone 状态会从 Pending 变成 Active。通常几分钟到数小时，也可能受注册商和缓存影响更久。

可以用下面命令从公网角度确认 NS 是否已经切换。示例里的域名换成自己的：

dig NS example.xyz +short

理想结果应该只看到 Cloudflare 分配的两条 nameserver。也可以查权威链路：

dig +trace example.xyz NS

但对普通用户来说，Cloudflare Dashboard 变 Active 加上 dig NS 返回正确，基本就够判断了。

5. 配置 API Token：给 Agent 权限，但不要给它一把万能钥匙

Cloudflare API Token 权限示意截图

图 5：推荐给 Agent 使用受限 API Token，而不是 Global API Key。DNS 自动化通常只需要指定 zone 的 DNS:Edit 与 Zone:Read。

Cloudflare 的强大之处在于 API 很完整。你可以自己写脚本，也可以把 API Token 交给 OpenClaw / HermesAgent / Claude Code / Codex 这类 Agent，让它帮你创建 DNS 记录、维护 DDNS、配置邮箱验证记录、检查代理状态、批量导入记录。问题是，自动化越强，权限越要收紧。

很多老教程会让你找 Global API Key。不建议这样做。Global API Key 基本等价于账号级万能钥匙，一旦泄露，影响范围很大。更合理的方式是创建 scoped API Token，也就是只允许它操作某个域名、某几类资源、某几个动作。

对本文场景，建议拆成几个 Token：

  1. DNS 管理 Token：用于 Agent 配置 A、AAAA、CNAME、TXT、MX。权限给指定 zone 的 Zone:Read 和 DNS:Edit。
  2. DDNS Token：只用于家庭网络或服务器更新动态解析。权限同样尽量限制在指定 zone 的 DNS:Edit，最好单独创建，方便随时吊销。
  3. 邮箱验证 Token：如果只是让 Agent 帮你添加 Google Workspace、腾讯企业邮箱等验证记录，仍然只需要 DNS 相关权限。
  4. 高级玩法 Token：如果你明确要让 Agent 配 Workers、Rules、Access、Zero Trust，再单独创建对应权限的 Token，不要和 DNS Token 混在一起。

创建路径通常是：右上角头像 -> My Profile -> API Tokens -> Create Token。如果有模板就选 Edit zone DNS 作为起点，然后把 zone 限制到 example.xyz 这一类具体域名。创建后 Cloudflare 只会显示一次 token 内容，复制后放到你的密钥管理位置。

喂给 Agent 时，不要直接贴在聊天窗口里。更推荐使用环境变量、密钥文件或运行时 secret。例如：

export CLOUDFLARE_API_TOKEN="<YOUR_RESTRICTED_TOKEN>"
export CLOUDFLARE_ZONE_NAME="example.xyz"

然后给 Agent 的任务描述写成：

请使用环境变量 CLOUDFLARE_API_TOKEN 管理 example.xyz 的 DNS 记录。
只允许修改 docs.example.xyz、home.example.xyz、mail 相关记录。
执行前先列出计划，执行后用 Cloudflare API 和 dig 验证。
不要读取、打印或提交 token。

如果是 OpenClaw / HermesAgent 这类长期运行的 Agent，可以把 Token 放进它们支持的 secret 配置里，而不是写进普通配置、日志、Markdown、截图或 Git 仓库。Agent 做完以后，也要看一眼 Cloudflare 审计日志和 DNS 记录变化。自动化不是免审计，只是减少重复点击。

6. 域名玩法 1：在 Cloudflare 配置常见 DNS 记录

Cloudflare DNS 记录类型示意截图

图 6：常见 DNS 记录的用途。A/AAAA/CNAME 可以选择橙云代理或灰云 DNS only；MX/TXT 等邮箱记录通常保持 DNS only。

Cloudflare DNS 页面最常用的记录类型大概就这些：

  1. A：把域名指向 IPv4，例如 203.0.113.10。
  2. AAAA：把域名指向 IPv6，例如 2001:db8::10。
  3. CNAME：把一个域名指向另一个主机名，例如 www 指向 example.xyz，或者 blog 指向某个托管平台给你的域名。
  4. TXT：放验证文本、SPF、DKIM、DMARC、站点所有权验证等。
  5. MX：告诉外界这个域名的邮件应该投递到哪台邮件服务器。
  6. CAA：限制哪些 CA 可以给你的域名签发证书，进阶安全项，后面有需要再配。

最容易混淆的是橙云和灰云。Cloudflare 文档里把橙云叫 Proxied，灰云叫 DNS only。橙云表示 HTTP/HTTPS 流量经过 Cloudflare 网络，可以使用缓存、防护、规则、证书等能力；灰云表示 Cloudflare 只返回 DNS 结果，不代理流量。

经验规则如下：

  1. 网站、博客、Web 面板：如果服务支持通过 Cloudflare 代理访问，可以开橙云。
  2. SSH、数据库、邮件、非 HTTP 服务：通常保持灰云，除非你明确使用 Cloudflare Tunnel、Spectrum 或其他对应方案。
  3. 第三方验证 CNAME：通常保持灰云，因为服务商只是要验证 DNS，不需要你的流量经过 Cloudflare。
  4. MX、TXT：没有橙云概念，按服务商要求填。

一个基础网站可以这样配：

A      @      203.0.113.10       Proxied
CNAME  www    example.xyz        Proxied
TXT    @      "v=spf1 include:_spf.example.net ~all"  DNS only

如果你的根域名不放网站，只想把 blog.example.xyz 指向 GitHub Pages、Vercel、Netlify、对象存储或某个反代服务，也完全可以只配子域名。根域名可以留空、做跳转，或者以后再用。

7. 域名玩法 2：配置 DDNS，让变化的公网地址也能固定访问

DDNS 工作流示意图

图 7：DDNS 的核心是“检测公网 IP -> 对比当前 DNS -> 变化时更新 Cloudflare 记录”。Cloudflare API 很适合做这类自动化。

如果你的宽带有公网 IPv4 或公网 IPv6，但地址会变化，就适合做 DDNS。典型场景：家里的 NAS、旁路由、临时测试机、摄像头反代、个人监控页、Minecraft 服务器、远程桌面网关等。你不想每次 IP 变了都手动改解析，所以让脚本或 Agent 定时更新 Cloudflare DNS。

Cloudflare DDNS 的逻辑很简单：

  1. 本地脚本查询当前公网 IP。
  2. 读取 Cloudflare 上 home.example.xyz 当前 A 或 AAAA 记录。
  3. 如果相同，不做任何事。
  4. 如果不同，调用 API 更新记录。
  5. 更新后用 dig home.example.xyz 验证。

给 DDNS 的记录建议单独规划，例如：

home.example.xyz     家宽入口
nas.example.xyz      NAS 入口
router.example.xyz   路由器或网关入口
lab.example.xyz      临时实验服务

如果你使用 IPv6，很多家宽环境的 IPv6 反而更容易拿到公网地址，这时 AAAA 记录会很有用。但要注意防火墙。公网 IPv6 不等于自动安全，设备暴露到公网后，入站规则、系统更新、弱口令、管理面板保护都要认真处理。

DDNS 记录是否开橙云要看服务类型。如果只是 Web 服务，且你希望隐藏源站 IP、使用 Cloudflare 证书和规则，可以开橙云。如果是 SSH、WireGuard、邮件或非 HTTP 服务，普通 Cloudflare DNS 的橙云代理并不适用，保持灰云更稳。很多人一看到橙云就全部打开，结果非 Web 服务访问异常，这不是 DNS 错，而是代理层不支持对应协议。

把 DDNS 交给 Agent 时，要给它非常明确的边界。例如只允许维护 home.example.xyz 和 nas.example.xyz，不允许改根域名、邮箱记录和其他生产记录。这样即使 Agent 判断失误，影响面也比较小。

8. 域名玩法 3：配置 Google Workspace、腾讯企业邮箱等第三方企业邮箱

企业邮箱方案对比示意图

图 8：第三方企业邮箱和 Cloudflare Email Routing 不是同一个东西。前者通常能完整收发，后者更适合做收信转发和邮箱别名。

企业邮箱的本质不是“创建一个 mail 子域名”这么简单。它通常需要几类 DNS 记录配合：

  1. MX：决定别人发到 user@example.xyz 的邮件交给哪家邮件服务商处理。
  2. TXT 验证记录：证明你拥有这个域名。
  3. SPF TXT：声明哪些服务器有权代表你的域名发信。
  4. DKIM TXT / CNAME：给发出的邮件做签名，降低被判垃圾邮件的概率。
  5. DMARC TXT：告诉收件方 SPF/DKIM 校验失败时怎么处理，并可接收报表。
  6. Autodiscover / 服务入口 CNAME：部分邮箱或协作套件会要求配置，用来自动发现服务地址。

以 Google Workspace 为例，你通常会在 Google 管理后台拿到 MX、TXT、DKIM 等记录，再回到 Cloudflare DNS 页面逐条添加。以腾讯企业邮箱为例，也是在腾讯侧拿到域名验证、MX、SPF、DKIM 等记录，再回到 Cloudflare 填写。这里不要背某个固定值，因为服务商可能调整记录要求，最稳的是以你邮箱后台当时显示的值为准。

配置时重点注意：

  1. MX 记录通常填根域名 @，优先级按服务商要求填写。
  2. 邮箱相关记录不要开橙云，MX/TXT 本身也不是代理流量。
  3. 同一个根域名最终应该只有一套主要 MX。不要同时把 Google、腾讯、Cloudflare Email Routing 的 MX 都混在一起。
  4. SPF 不是越多越好。一个域名最好只有一条 SPF TXT，多家发信源要合并在同一条里。
  5. DKIM 配好后要在邮箱后台点击启用或验证，不是 DNS 填完就自动完成。
  6. DMARC 可以先从 p=none 观察，再逐步收紧到 quarantine 或 reject。

这类配置非常适合让 Agent 辅助，因为记录多、名字长、容易复制错。但仍然建议先让 Agent 输出计划：它准备添加哪些记录、删除哪些旧记录、哪些记录会影响收信。确认后再执行。执行后让它用 Cloudflare API、dig MX、dig TXT 和邮箱后台校验状态做交叉验证。

9. 域名玩法 4：用 Cloudflare Email Routing 做自己的“轻量企业邮箱”

Cloudflare Email Routing 很适合个人域名：你可以创建 admin@example.xyz、hello@example.xyz、billing@example.xyz 这类地址，然后转发到自己的 Gmail、Outlook 或其他真实邮箱。对外看起来是你的域名邮箱，对内不需要维护一套完整邮件服务器。

但要把边界说清楚：Cloudflare Email Routing 主要解决“收信转发”，它不是传统意义上的完整邮箱托管，也没有普通 SMTP 发信服务器。Cloudflare 文档明确说明，Email Routing 不处理出站邮件，也不提供 SMTP。也就是说，你可以收 hello@example.xyz，但不能简单地把它当成一个完整的企业邮箱账号直接用 SMTP 发信。现在 Cloudflare 也在推进 Email Service 相关能力，但入门用户理解时仍应把 Email Routing 当成“转发和路由”，不要误以为它天然等于 Google Workspace 或腾讯企业邮箱。

启用流程大概是：

  1. 进入域名的 Email / Email Routing 页面。
  2. 添加 destination address，也就是你的真实收件邮箱。
  3. Cloudflare 会给目标邮箱发验证邮件，点击确认。
  4. 创建 custom address，例如 hello@example.xyz。
  5. 选择转发到已经验证的目标邮箱。
  6. Cloudflare 自动添加或提示添加所需 MX / TXT 记录。
  7. 发一封测试邮件到 hello@example.xyz，确认能转发到目标邮箱。

这个功能很适合以下场景：

  1. 给不同平台分配不同别名，例如 github@example.xyz、cloud@example.xyz。
  2. 对外公布 hello@example.xyz，但不暴露私人邮箱。
  3. 做一次性项目邮箱，项目结束后直接停掉别名。
  4. 给家庭或小团队做简单收件入口。

如果你要正式企业通信、多人邮箱、日历、网盘、会议、SMTP 发信、归档审计，还是应该上 Google Workspace、Microsoft 365、腾讯企业邮箱、飞书邮箱这类完整服务。Cloudflare Email Routing 适合轻量，不适合假装成完整邮局。

10. Agent 介入 Cloudflare 的正确姿势

把 Cloudflare API Token 喂给 Agent 的最大收益，是把复杂、重复、容易点错的工作交给它：批量创建子域名、维护 DDNS、按服务商文档添加邮箱记录、检查橙云灰云状态、导出 DNS 记录、生成变更计划、做迁移前后对比。尤其是 OpenClaw / HermesAgent 这类运行在自己环境里的 Agent，如果能稳定访问 Cloudflare API，就可以承担一部分“DNS 运维助手”的角色。

但正确姿势不是“把账号密码给它，让它随便配”。我建议固定使用这个流程：

  1. 先定义目标。 例如“把 docs.example.xyz 指向某托管平台，并配置验证 TXT”。
  2. 给最小权限。 只给指定 zone 的 DNS 权限。
  3. 让 Agent 先读后写。 先列出现有记录和变更计划，不要上来就改。
  4. 要求差异输出。 哪些记录新增、哪些修改、哪些删除，一条条列出来。
  5. 执行后验证。 用 Cloudflare API 看记录，用 dig 看公网解析，用服务商后台看验证状态。
  6. 保留回滚信息。 删除或修改记录前，先记录旧值。
  7. Token 定期轮换。 DDNS 这类长期 Token 尤其要能随时吊销。

一个比较稳的 Agent 指令可以这样写：

你将维护 Cloudflare 上 example.xyz 的 DNS。
使用环境变量 CLOUDFLARE_API_TOKEN，不要打印 token。
本次只允许修改 docs.example.xyz 与 _verify.docs.example.xyz。
先读取现有记录并给出变更计划，等待确认后再执行。
执行后使用 Cloudflare API 与 dig 验证结果。
不要修改 MX、根域名 @、www 或任何未授权记录。

如果 Agent 框架支持审批模式，DNS 这种外部可见配置建议开启审批。DNS 记录看起来只是几行文本，但错误删除 MX 会影响收信，错误打开橙云可能导致服务不可访问，错误暴露源站可能影响安全。自动化要做，但要带边界。

11. 常见排查：为什么我改完还是不生效

DNS 最大的敌人不是复杂，而是缓存和层级。你在 Cloudflare 改完记录，不代表所有递归 DNS 立刻都看到新值。你在域名商改完 NS，也不代表顶级域、递归 DNS、浏览器、操作系统缓存都马上刷新。

排查顺序建议这样：

  1. dig NS example.xyz +short：先确认权威 NS 是否已经是 Cloudflare。
  2. dig @arya.ns.cloudflare.com example.xyz A：直接问 Cloudflare 权威 NS，确认 Cloudflare 自己返回什么。
  3. dig example.xyz A：问默认递归 DNS，确认普通用户路径是否更新。
  4. Cloudflare DNS 页面检查记录是否写错 Name。@ 是根域名，www 是 www.example.xyz，不要写成 www.example.xyz.example.xyz。
  5. 检查橙云灰云。非 Web 服务开橙云访问不了，很常见。
  6. 邮箱问题先查 MX，再查 SPF/DKIM/DMARC。不要只看后台“未验证”就反复乱改。
  7. 如果国内访问 Cloudflare Dashboard 或相关服务异常，先换网络环境，再继续排查配置。

如果你让 Agent 帮你排查，也不要只问“为什么不通”。更好的问法是：

请检查 example.xyz 的 NS、A、AAAA、CNAME、MX、TXT 记录是否符合以下目标。
请分别从 Cloudflare API、权威 DNS 查询、公共递归 DNS 查询三个角度验证。
不要修改任何记录，只输出问题和建议修复计划。

这样 Agent 会更容易按层次诊断，而不是直接猜一个原因。

12. 最后给一套推荐落地顺序

如果你刚买完一个便宜 .xyz 域名，我建议按下面顺序来，不要一口气把所有玩法都打开：

  1. 在 Cloudflare 添加根域名，复制两条 NS。
  2. 到域名商替换 nameserver，等待 Cloudflare zone 变 Active。
  3. 添加最基础的 @、www 或 blog 记录，确认 Web 访问正常。
  4. 创建受限 API Token，只给指定 zone 的 DNS 权限。
  5. 让 Agent 读取 DNS 记录并输出清单，确认它能安全访问 API。
  6. 配一个低风险子域名给 Agent 练手，例如 test.example.xyz。
  7. 再配置 DDNS，把家庭或服务器动态地址绑定到独立子域名。
  8. 需要邮箱时，先决定是完整第三方企业邮箱，还是 Cloudflare Email Routing 转发。
  9. 邮箱记录稳定后，再考虑 DMARC 收紧、CAA、访问规则、Workers、Pages、Tunnel 等高级玩法。

域名便宜只是入口。真正值钱的是把它变成一个稳定、可维护、可自动化的个人基础设施入口。Cloudflare 的好处是上限很高，下限也不复杂：刚开始只需要会改 NS 和加 DNS 记录；等你熟了，再把 API Token、DDNS、邮箱、Agent 自动化逐步接上。这样一个十年几十块的域名，才算真正用起来。

参考资料

  1. Cloudflare DNS：Set up a primary zone (Full setup) - https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/
  2. Cloudflare DNS：Update nameservers - https://developers.cloudflare.com/dns/nameservers/update-nameservers/
  3. Cloudflare Fundamentals：API token permissions - https://developers.cloudflare.com/fundamentals/api/reference/permissions/
  4. Cloudflare DNS：Vendor-specific DNS records - https://developers.cloudflare.com/dns/manage-dns-records/reference/vendor-specific-records/
  5. Cloudflare Email Routing：Enable Email Routing - https://developers.cloudflare.com/email-routing/get-started/enable-email-routing/
  6. Cloudflare Email Routing：Get started - https://developers.cloudflare.com/email-routing/get-started/