When a renewal answer is lost, do not retry. An unchanged expiry date does not prove nothing happened — the renewal may still be pending, or the read may be stale — and a changed one does not prove your request changed it, because an automatic renewal or somebody else can move it too. Settle the outcome from the registrar's own record of that request, in the terms its documentation says are final. Until you have that, the outcome is unknown, and it stays unknown.
Domain renewals fail in a particular way: the request is a purchase, the answer can be lost, and the domain carries a date that looks as though it should settle the question. On its own it does not. What makes getting this right urgent is the timeline — the consequences of a mistake escalate on a schedule you do not control.
ICANN's Expired Registration Recovery Policy sets out what registrars must do around expiry for generic top-level domains, including the notices before expiry and a period after it during which the registrant can recover the name. After that recovery period a domain typically enters redemption, where restoring it carries a separate restore fee — the policy requires registrars to publish it — and then it is released.
The operational consequence: notice earlier for domains than for hosting. A hosting customer who misses a renewal has a suspended website; a domain customer who misses one can lose the name, and with it their email.
The expiry date is evidence, and it is worth recording before every attempt. It is not proof in either direction.
Record the expiry date before every attempt anyway. It is the cheapest corroborating evidence you have — just not the deciding evidence.
EPP's renew command carries the domain's current expiry date, and RFC 5731 gives the reason: it ensures repeated renew commands do not result in multiple, unanticipated successful renewals. Some registrar HTTP APIs offer the same guard as a parameter. Where yours documents one, send it.
Be clear about what it protects. It refuses a repeat once the first renewal has moved the date. While the first is still pending the date has not moved, so the guard cannot tell a repeat from a first attempt. It makes a mistaken retry cheaper; it does not replace the reconciliation above.
| What came back | What it means | What to do |
|---|---|---|
| A code the registrar documents as a refusal with no action taken | The registrar declined | Record the reason. Correct it and try again deliberately |
| An accepted or pending response | The registrar has the request and has not finished it | Pending. Follow the documented status; do not retry |
| An unrecognised code | You do not know what happened | Unknown. Reconcile with the registrar |
| Nothing — a timeout | The request may have been processed | Unknown. Reconcile with the registrar |
| A rate-limit response | Unknown, unless the registrar documents that a rate-limited request is never processed | Reconcile with the registrar |
| A redirect | Something other than the documented endpoint answered | Unknown. Reconcile, and investigate the endpoint |
The first row and the unrecognised code are the distinction that matters most. Mapping every non-success to "refused" is a claim that nothing happened — and after a purchase, that is a claim you can only make from a code the registrar documents as meaning exactly that.
A domain in an uncertain state is worth a proactive message. "We are confirming your renewal with the registrar and will update you today" costs nothing and can head off the support ticket that starts with "my email has stopped working". Keep the customer-facing status honest: renewing is not renewed.
GENV's registrar adapters classify outcomes into five states, including an explicit ambiguous one: an unrecognised or missing response code after an effecting write is treated as unknown, never as a refusal. An unknown registrar request is never retried automatically — somebody establishes what happened and records it, and the record says it was reconciled, which is a different claim from the registrar having said so. Renewals are not routed to real registrars in the shipped build.
Earlier than for hosting. For gTLDs, ICANN's Expired Registration Recovery Policy requires the registrar to send at least two reminders — approximately one month and one week before expiry — and another within five days after it. If you resell, set your own schedule knowing the registrar's notices may reach the same customer, and leave room for a failed payment to be fixed before the name is at risk.
Then you have a reason to look closer, not an answer. The registry's date is the deadline that governs the name, but depending on the TLD it can move at expiry through an automatic renewal the registrar may later reverse, and a registrar's display can lag behind. Neither date tells you whether your request was processed; the registrar's record of the request does.
You can automate gathering the evidence: the registrar's documented status or transaction queries, the domain read, the comparison with the recorded date. Automate the conclusion only where the registrar documents that a particular answer is final. Everywhere else, make the conclusion a recorded act — who or what established it, and from which evidence — so that an audit can tell "the registrar confirmed it" from "somebody assumed it".
Official documentation, each requested on 21 September 2026. Provider behaviour changes; check the source before relying on a detail.