域名续费与转移：四条时间线、三把 60 天锁、一份倒排清单

直接答案

域名不是「买一次、到期再买一次」的东西。它同时被四套时钟推着走，而这四套时钟分属三个不同的主体：

时钟	谁在管	关键数字	到点后发生什么
自动续费尝试	注册商的计费系统	到期前约 30 天起，最后一次在到期前一天；失败后再试 3 次	仍失败则必须手动续费
Redemption Grace Period（RGP）	注册局	到期后 30 天	可恢复，但可能收费，且期间不能转移
转移锁（新建／上次转移／注册人变更）	ICANN 政策 + 注册商	各 60 天，共三把	转出被拒，或必须被拒
到期后先续费再转移	注册局	原到期日 + 45 天	否则注册局可能不给你加那一年

先说清适用范围：上表中「30 天」「3 次」「几封提醒」来自 Cloudflare Registrar 的公开文档，是这一家注册商的实现，不是 ICANN 对所有注册商的统一要求——换一家注册商，重试次数和通知节奏可能完全不同。而 60 天锁、FOA 的 24 小时、5 个日历日的默认批准，是 ICANN 转移政策对所有认证注册商的约束，换到哪家都成立。

这就是为什么「我开了自动续费」和「我买了十年」都不是安全感：它们各自只覆盖了四套时钟里的一套。

一、自动续费是重试机制，不是保证

Cloudflare 的文档把这句话写得很直白：

There is no guarantee that the renewal will succeed. Renewals may fail for various reasons, including billing failures and registry downtime.

接着是重试节奏，分两处写：

The first auto-renew attempt will occur approximately 30 days prior to expiration.

Several more attempts are made if the first attempt fails. The last attempt to renew is made on the day before expiration.

以及失败之后：

If the renewal fails, you will receive an email notification and Cloudflare will try to renew the domain three additional times. If these attempts fail, you must manually renew your domain.

这三句要合起来读，因为它们各自都不构成一条完整时间线。页面给了起点（约 -30 天）、给了终点（到期前一天）、给了失败后的额外次数（3 次），但没有给总次数，也没有给每次的具体日期。所以任何「我还有 5 次机会」「大概每三天试一次」的说法都是替文档补它没写的东西。可操作的结论只有一句：看到失败邮件的那一刻，就当归零处理，手动续费。

三个容易被忽略的细节：

① 关闭自动续费有截止时间。 文档写「If you wish to disable auto-renew, do so at least 30 days prior to the expiration date.」——首次尝试就在这个时点。页面没有承诺「首次尝试之后再关掉就一定能阻止扣款」，所以不要把「我关了」当成「不会扣」。

② 同一天续期的域名，只扣一次主支付方式。 原文是「If multiple domains are auto-renewed on the same date, only one charge will be made to the primary payment method.」编辑判断：这条便利的反面是单点故障——一张卡失效，同一天到期的所有域名会一起失败。域名多的人，值得把续费卡和日常订阅卡分开，并留一个不依赖邮件提醒的日历闹钟。

③ 早续不亏。 文档明确「When renewing a domain, additional years are always added to the current expiration date regardless of when the renewal takes place.」提前半年续费，新加的年数仍然接在现有到期日之后，不会从续费当天起算。手动续费一次最长可选 10 年。

反过来，这条也意味着续费是终局：「All renewals are final and Cloudflare will not issue refunds.」先想清楚再点，尤其是想「先续十年当投资、以后再说」的时候。

二、提醒矩阵：最密集的几封，发给的不是账号主人

这条最容易吃亏。文档把通知分成两组，收件人不同：

收件人	频率	触发条件
域名 Super Admin	每月一封	未来 45 天内将自动续费的域名
域名 Super Admin	每月一封	未来 60–90 天内到期的域名
WHOIS Registrant	每周一封	未来一个月内到期
WHOIS Registrant	每天一封	7 天内到期
WHOIS Registrant	到期后 1 天	已过期
WHOIS Registrant	到期后 20 天	仍未处理

三个推论，前两个是事实，第三个是编辑判断：

1. 「还有 7 天」的每日提醒，发往 WHOIS Registrant 的邮箱，不是登录后台的那个账号邮箱。如果注册人联系信息是一个你早已不看的地址（旧公司邮箱、代注册时随手填的地址），这套提醒对你等于不存在。
2. 注册人邮箱未验证，会直接换掉你的 NS。 原文：「If your email is unverified or if the verification has expired, ICANN places a hold on the domain and replaces your nameservers with parking server nameservers (NS). Once you complete verification, your nameservers are automatically restored.」这是「网站突然打不开、但 DNS 配置看起来没动」的一种成因——不是解析配错，是域名被 hold 了。
3. 只依赖「7 天内」的每日提醒，等于把处置窗口压到一周；真正的提前量在那两封 45 天与 60–90 天的月报里。所以：把注册人邮箱换成一个每天都会看的地址，并把 registrar 的发件域加进白名单——这两件事的收益，比任何监控面板都直接。

三、三把 60 天锁，和一条关于顺序的建议

ICANN 政策把「60 天」用在三个完全不同的地方，它们不是同一条规则的三种说法：

锁	起算点	政策条款	强度
新建锁	域名创建日	3.7.5「within 60 days of the creation date」	注册商可以拒绝
转移后锁	上一次转移完成	3.7.6「within 60 days … after being transferred」	注册商可以拒绝
注册人变更锁	注册人姓名／组织／邮箱变更	3.8.5	注册商必须拒绝，除非事先 opt out

差别在措辞里：3.7 是「The Registrar of Record may deny a transfer request only in the following specific instances」——一份封闭清单；3.8 是「The Registrar of Record must deny」——强制。注册人变更锁落在强制那一档：

3.8.5 The Registrar imposed a 60-day inter-registrar transfer lock following a Change of Registrant, and the Registered Name Holder did not opt out of the 60-day inter-registrar transfer lock prior to the Change of Registrant request.

Cloudflare 的转移前置条件把这三条并列写了出来，并补了一句关键的现实差异：「Some registrars let you opt out of this lock during the change, but not all do.」——能不能豁免，取决于你在哪家注册商，别默认可以。

于是有一条顺序建议，ICANN 自己写了：如果最终目的是转移到另一家注册商，应当在做 Change of Registrant 之前先发起转移，以避免触发那 60 天锁（除非注册商给了 opt-out 且你用了）。翻成一人公司的场景：

• 你换了邮箱，想先把注册人信息改对，再慢慢转移 → 顺序反了，改完要再等 60 天。
• 正确顺序：先转移（此时注册人信息还是旧的，但你能收到邮件），转移完成后再改注册人信息。

还有一条与「到期」交叉的规则：FOA（授权表）在「the domain name expires before the inter-registrar transfer is completed」时失效（2.2.3.2）。别在到期前最后几天发起转移——转移没走完、域名先过期，授权作废，你得从续费重新开始。

四、解锁不等于能转：还有三道闸

很多人把「转移失败」理解成一个报错。实际更常见的是卡住不动，而卡住的原因分布在四个互不相干的地方：

① 注册商锁（registrar lock）。 多数注册商默认开启。ICANN 3.9.3 规定：单纯处于 Registrar Lock Status 不能作为拒绝理由，除非持有人在提出转移请求之前已获得合理机会与能力去解锁。3.7.4 还要求：持有人提出解除请求后，注册商必须在 5 个日历日内解锁，或提供一条合理可达的自助解除路径。编辑判断：解锁要走工单时，把请求时间和回复留档——这是你唯一能证明「我要求过」的东西。

② DNSSEC。 这是最容易被忽略、后果又最像「DNS 坏了」的一道。原文：

Disable it before you change nameservers. DNSSEC validates DNS responses using cryptographic signatures tied to your current provider. When you point nameservers to Cloudflare, those signatures will no longer match, which causes DNS resolution failures and can prevent your domain from becoming active.

并且要求「Wait at least 24 hours for the change to propagate before changing nameservers」。转移完成后再一键开回来。顺序是：先关 DNSSEC → 等 ≥24 小时 → 再改 NS，不是同时做。

③ 注册人邮箱验证。 见上一节的 hold + parking NS。它不只影响续费，也影响转移期间的可用性。

④ 域名已过期。 文档要求「If your domain has expired, renew it at your current registrar first.」过期域名不能直接转；而「刚过期又续费」的情形，还要满足下一节的 45 天。

另外，少数后缀在转移完成后还有一层单独验证：.ca、.mx、.nz 会另发一封验证邮件，「Failure to complete this verification within the required timeframe may result in domain suspension」。这三类域名的转移，不能以「转移完成」作为收工标准。

五、转移的时钟与钱：三个数字，一个反直觉

总时长：「Active work: About 30 minutes. Total time: Up to 10 days, depending on your registrar.」主动操作约半小时，其余是等待。

等待的构成有两个强制节点：

• FOA 必须在收到注册局转出请求后 24 小时内发出（3.4，「not later than twenty-four (24) hours」）。
• 转出注册商 5 个日历日内不响应，注册局按默认「approval」放行（3.5）；3.6 进一步写「the default action will be that the Registrar of Record must allow the transfer to proceed」。

也就是说，对方不回复不是僵局，是倒计时。Cloudflare 侧的表述与此吻合：「most registrars process it within 5 business days (but some TLDs, such as .mx, can take up to 10 business days)」。

钱的部分有一个反直觉点：转移不是「再买一年」，而是「把现有注册延长一年」。

Most transfers include a one-year extension from your current expiration date.

Each transfer adds one year to your domain registration. You will pay the other registrar for the first transfer, and Cloudflare for the second. These are not redundant charges — each extends your registration.

所以「为了转个注册商白花一年钱」是错的：那一年加在你的到期日上。反过来，如果你的域名只剩两个月，转移相当于顺手续了一年。部分国家代码顶级域（文档举 .uk）没有转移费。

还有那条 45 天：

If your domain recently expired and you renewed it, wait at least 45 days after the original expiration date before transferring. Otherwise, the registry may not add the extra year.

注意它约束的是「那一年加不加」，不是「能不能转」。你可以转，但可能拿不到延长——这才是这条规则真正贵的地方：它不报错，只是让你少一年。

六、按日期倒排的清单

把上面所有数字压成一张表，T 是到期日。这份表以 Cloudflare Registrar 的节奏为准；用别家注册商时，前三行与最后两行要按对方文档替换，中间三把锁与 FOA 规则不变。

时点	动作	通过标准
T-90	盘一遍域名：注册商、到期日、auto-renew 状态、注册人邮箱、DNSSEC、lock 状态	每个域名都能答出「谁、在什么时候、发到哪个邮箱提醒我」
T-60	若要转移：核三把锁、申请解锁、关 DNSSEC	三项都有明确日期，且都不落在未来 60 天内；若还要改注册人信息，先转移
T-45	若域名是「过期后才续费」的	转移排在原到期日 +45 天之后，否则可能少一年
T-30	首次自动续费尝试	扣款卡有效、额度够；此时不要才去关 auto-renew（官方要求提前 30 天）
T-14	验证注册人邮箱能收信	用该地址实收一封测试邮件；registrar 发件域在白名单里
T-7	每日提醒开始	确认收到，而不是「应该会收到」
T-1	最后一次自动续费尝试	后台状态不是 Renewal Pending 或失败
T-0	到期，进入 30 天 RGP	若已过期：可恢复，但可能收费，且不能转移
T+1 / T+20	两封过期提醒	只在已过期时发出；收到即代表已进入 RGP
T+30	RGP 结束	文档只写到这 30 天，之后的行为不在本文范围

如果只能记住一件事：T-30 之前必须有一次人工确认。因为从 T-30 起，剩下的全是自动流程，而自动流程的失败通知只有一封邮件。

七、六种误读

1. 「开了自动续费就不会掉。」 官方原文是「no guarantee」，失败原因包括计费失败与注册局宕机。
2. 「失败了会一直重试到成功。」 再试 3 次，然后「you must manually renew」。
3. 「RGP 是免费宽限期。」 是 30 天恢复期，但「restoration may require an additional fee」，且期间不能转移。
4. 「解锁了就能转。」 DNSSEC、注册人邮箱验证、三把 60 天锁，任何一道都能单独挡住。
5. 「转移等于重复买一年。」 转移把一年加在当前到期日上，两次转移付两次钱，但「not redundant charges」。
6. 「到期前随时都能转。」 域名在转移完成前到期，FOA 直接失效；过期域名要先在原注册商续费。

八、这周可以做的五件事

1. 把域名列成一张表，四列：到期日、注册人邮箱、auto-renew、DNSSEC。缺哪列就先补哪列。
2. 登录注册人邮箱，确认它现在还能收信——不是「应该能」。
3. 查一次 lock 状态；如果要转，今天就把解锁工单发出去，留时间戳。
4. 如果域名开了 DNSSEC 且你准备换 NS，先把「关 DNSSEC → 等 24 小时」写进日历。
5. 给每个域名设一个不依赖邮件的到期前 45 天提醒，作为整套通知矩阵的兜底。

---

边界说明：本文不写任何续费或转移的价格数字（各注册商与各后缀差异过大，且会变），不写「掉签」「抢注」概率，也不比较哪家注册商更快更便宜。文中「编辑判断」标注的段落是运营建议，不是 ICANN 政策或厂商文档的结论。Cloudflare 文档中的 30 天、3 次重试、通知频率属该注册商的实现细节，不可推广到所有注册商；ICANN 政策条款则对所有认证注册商适用。

来源

以下页面均于 2026-10-27 逐条访问并验证为 HTTP 200；字节数为当日抓取的实际大小。

1. Renew domains with Cloudflare Registrar核查于 2026/10/27（200，108 593 B）：默认开启自动续费；「no guarantee that the renewal will succeed」与计费失败、注册局宕机两类原因；首次尝试约在到期前 30 天、最后一次在到期前一天、失败后再试 3 次；关闭 auto-renew 须提前 30 天；同日多域名只扣主支付方式一次；45 天与 60–90 天月报、每周／每日／到期后 1 天与 20 天的注册人通知；RGP 30 天、可能收费、不可转移、续费不退；续费年数叠加在当前到期日；手动续费最长 10 年。
2. Transfer your domain to Cloudflare核查于 2026/10/27（200，155 921 B）：总时长「Up to 10 days」、主动操作约 30 分钟；多数转移含一年延长、部分 ccTLD 无转移费；创建后 60 天、上次转移后 60 天、注册人信息变更后 60 天三项前置条件与 opt-out 的不确定性；DNSSEC 必须先关、需等 24 小时传播、不关会导致解析失败；注册人邮箱未验证会被 hold 并换成 parking NS、验证后自动恢复；过期后先续费、刚过期又续费需等原到期日 45 天；FOA 与「5 business days／.mx 最多 10 business days」；两种转移状态的含义；.ca／.mx／.nz 的转移后验证。
3. ICANN Transfer Policy（2024-02-21 更新版）核查于 2026/10/27（200，270 498 B）：3.4 FOA 须在 24 小时内发出；3.5 五个日历日未响应即默认「approval」、3.6 默认必须放行；3.7 拒绝理由的封闭清单（含 3.7.5 创建后 60 天、3.7.6 转移后 60 天）；3.8.5 注册人变更后 60 天锁为强制拒绝；3.9.3 单纯 Registrar Lock 不能作为拒绝理由、3.7.4 解锁请求须在 5 个日历日内处理；2.2.3.2 域名在转移完成前到期则 FOA 失效；Change of Registrant 一节建议先做注册商间转移以避免触发 60 天锁。