Skip to main content
Resources

Expired Registration Recovery Policy

Please note that the English language version of all translated content and documents are the official versions and that translations in other languages are for informational purposes only.

Updated 21 February 2024 to reflect changes required to implement the Registration Data Policy. Contracted parties may implement this updated Policy beginning on 21 August 2024 and must implement no later than 21 August 2025.

  1. Registrant at Expiration

    1.1. A Registrant at Expiration ("RAE") is defined as the Registered Name Holder who is eligible to renew a domain name registration immediately prior to its expiration.

    1.2. If a domain name registration is modified pursuant to a term of the registration agreement authorizing the modification of registration data in relation to the expiration of the registration, the RAE is the entity or individual identified as the Registered Name Holder immediately prior to that modification. In all other cases of transfers of gTLD registrations between Registered Name Holders, the Registered Name Holder who receives the registration is the RAE.

  2. Renewal of Registrations

    2.1. Expiration Reminder Notices

    2.1.1. Prior to the expiration of any gTLD registration, registrars must notify the Registered Name Holder of the expiration at least two times. One of these notices must be sent approximately one month prior to expiration and one must be sent approximately one week prior to expiration. In the event the registration is transferred to a different Registered Name Holder pursuant to a provision of the registration agreement and in relation to the expiration of the registration (as described in paragraph 1.2) these renewal notices must be transmitted instead to the RAE. Nothing in this policy is intended to preclude registrars from sending additional notices, provided that at least two required notices are sent at the required times.

    2.1.2. If a registration is not renewed by the RAE or deleted by the registrar, within five days after the expiration of the registration, the registrar must transmit at least one additional expiration notice to the RAE that includes instructions for renewing the registration.

    2.1.3. Notifications of expiration may be presented in one or more languages, but must be provided in the language of the registration agreement and must be communicated in a manner, such as by email, that does not require affirmative action to receive the notification.

    2.2. Post-Expiration Renewal

    2.2.1. Subject to applicable consensus policies and provisions of the Registrar Accreditation Agreement ("RAA"), registrars may delete registrations at any time after they expire.

    2.2.2. For registrations deleted within eight days of expiration: The existing DNS resolution path specified by the RAE must be interrupted by the registrar from expiration of the registration until its deletion, to the extent the applicable registry permits such interruptions.

    2.2.3. For registrations deleted eight or more days after expiration: For at least the last eight consecutive days (after expiration) that the registration is renewable by the RAE, the existing DNS resolution path specified by the RAE must be interrupted by the registrar to the extent that the applicable registry permits such interruptions.

    2.2.4. In interrupting the DNS resolution path of the registration, if the registrar directs web traffic to the domain name to a web page while the registration is still renewable by the RAE, that web page must conspicuously indicate that the domain name registration is expired and provide renewal instructions.

    2.2.5. Beginning at the time of expiration and through the DNS resolution interruption period described in paragraphs 2.2.2 and 2.2.3, the RAE must be permitted by the registrar to renew the expired registration.

    2.2.6. Upon renewal of the registration by the RAE, the registrar must restore the DNS resolution path set by the RAE immediately or as soon as is commercially reasonable.

  3. Redemption Grace Period

    3.1. With the exception of sponsored gTLD registries, all gTLD registries must offer a Redemption Grace Period ("RGP") of 30 days immediately following the deletion of a registration, during which time the deleted registration may be restored at the request of the RAE by the registrar that deleted it. Registrations deleted during a registry's add-grace period, if applicable, should not be subject to the RGP.

    3.2. During the Redemption Grace Period, the registry must disable DNS resolution and prohibit attempted transfers of the registration. ICANN-approved bulk transfers and permitted partial bulk transfers are not subject to the prohibition of attempted transfers. The registry must also clearly indicate in its Registration Data Directory Services (RDDS) result for the registration that it is in its Redemption Grace Period.

    3.3. Registrars must permit the RAE to redeem a deleted registration during RGP (if RGP is offered by the respective registry).

  4. Notice to Registered Name Holders of Fees and Procedures

    4.1. Registrars must make their renewal fees, post-expiration renewal fees (if different), and redemption/restore fees reasonably available to Registered Name Holders and prospective Registered Name Holders at the time of registration of a gTLD name.

    4.1.1. At a minimum, these fees must be clearly displayed on the registrar's website and a link to these fees must be included in the registrar's registration agreements. Registrars who do not offer or provide registrar services through a website must at least include the fees in their registration agreements.

    4.1.2. Additionally, registrars must ensure that these fees are displayed on their resellers' websites.

    4.2. Registrars must describe on their websites (if used) the methods used to deliver pre- and post-expiration notifications described in section 2 above.

    4.2.1. This description should generally include communications channels/media that will be used and identification of the point of contact to which the notices will be transmitted (e.g., email to Registered Name Holder, telephone call to Registered Name Holder, postal mail to customer, etc.).

    4.2.2. Registrars' registration agreements must include either a similar description of its notification methods or a link to the applicable page(s) on its website where this information is available.

    4.2.3. Additionally, registrars must ensure that these communication methods are described on their resellers' websites.

    4.3. In the event ICANN publishes Registered Name Holder education materials addressing proper stewardship of domain names and renewal and redemption of gTLD registrations online, registrars must, after reasonable notice from ICANN, make this material (or similar material adapted by the registrar to its specific practices) available to Registered Name Holders by:

    4.3.1. including a link to this material in a communication sent to the Registered Name Holders immediately following completion of the registration transaction and in all subsequent registration data accuracy reminder notices, such as the annual notices required by the Registration Data Reminder Policy <https://www.icann.org/resources/pages/drp-2024-02-21-en>; and

    4.3.2. displaying a link to this material on the websites through which registrations are offered, in a manner and location that is at least as clear and conspicuous as links to other documents and policies that must be posted by the registrar pursuant to its registrar accreditation agreement and incorporated consensus policies.

Notes

Introduction and Background: At the request of ICANN's At-Large Advisory Committee, on 5 December 2008, ICANN published an Issues Report <http://gnso.icann.org/issues/post-expiration-recovery/report-05dec08.pdf> [PDF, 422 KB] on the topic of Post-Expiration Domain Name Recovery. The Generic Names Supporting Organization Council ("GNSO") initiated a Policy Development Process in May 2009, which resulted in the submission of several policy and process recommendations <http://gnso.icann.org/en/resolutions/#201107> to the ICANN Board of Directors. The ICANN Board approved the recommendations on 28 October 2011 <http://www.icann.org/en/groups/board/documents/resolutions-28oct11-en.htm#1.5>, directing staff to implement this policy.

The Expired Registration Recovery Policy is intended to help align Registered Name Holder expectations with registrar practices by establishing certain minimum communications requirements, making renewal and redemption of registrations uniformly available in prescribed circumstances, and through the creation and promotion of Registered Name Holder educational materials.

The Expired Registration Recovery Policy has been developed in consultation with an Implementation Review Team convened by the GNSO to ensure that the policy meets the letter and intent of the policy recommendations approved by the GNSO and adopted by the ICANN Board.

All registrars and registries are required to comply with this policy beginning 31 August 2013.

Expiration Reminder Notices: The policy recommendations by the GNSO recognize that some flexibility is required in the timing of pre-expiration renewal notices. As such, if the notices required to be sent approximately one month and one week prior to expiration described in paragraph 2.1.1 are transmitted between 26-35 days and between 4-10 days prior to expiration, respectively, this would be considered compliant with the policy.

Post-Expiration Renewal: Paragraph 2.2.4 of the policy explains that registrars must include an expiration notice and renewal instructions if the registrar directs web traffic to the domain name to a web page while it is renewable by the RAE. To be clear, this requirement applies at any time during which the registration is renewable by the RAE, not just during the period described in paragraphs 2.2.2 and 2.2.3. The renewal instructions required by this section need not be elaborate and could simply direct the RAE to the appropriate place on the registrar's website.

Paragraph 2.2.2 describes the duration for which a registrar must interrupt the DNS resolution path of a registration if the registration is deleted within eight days of its expiration. By way of example, if a registration expires on 1 October, and the registrar deletes the name on 3 October, the resolution path must be interrupted from 1-3 October. Paragraph 2.2.3 describes the duration for which a registrar must interrupt the DNS resolution path of a registration if the registration is deleted more than eight days after its expiration. For example, if a registration expires on 1 October, and the registrar deletes the name on 20 October, the resolution path must be interrupted, at a minimum, from 12-20 October.

Paragraph 2.2.6 requires that registrars restore the DNS resolution path previously set by the RAE immediately or within a commercially reasonable amount of time. The term "commercially reasonable" is intended in this instance to allow, for example, for situations in which manual intervention is required to restore the DNS resolution path or where a registrar cannot immediately restore the DNS resolution path because the post-expiration renewal occurred on a holiday or other non-business day.

Notice to Registered Name Holder of Fees and Procedures: Paragraph 4.1.1 of the policy requires registrars to, at a minimum, include renewal fees, post-expiration renewal fees (if different), and redemption/restore fees in the registration agreement (and on their websites, if a website is used). Registrars are, however, encouraged to present these fees in a sufficiently prominent manner at the time of registration to help Registered Name Holders make an informed decision and avoid confusion, particularly if renewal prices are anticipated to be greater than the registration or transfer fee being charged.

Suggested Best Practices: The GNSO recommends the following best practices for registrars:

  • If the post-expiration notifications described in paragraph 2.1.2 are normally sent to a point of contact using the domain in question, and delivery is known to have been interrupted by post-expiration actions (such as an interruption of DNS resolution, as described in paragraphs 2.2.2 and 2.2.3), post-expiration notifications should be sent to some other contact point associated with the Registered Name Holder if one exists.
  • Registrars should advise Registered Name Holder to provide a secondary email point of contact that is not associated with the domain name itself so that in case of expiration, reminders can be delivered to this secondary email point of contact.
  • The notification method explanation required by paragraph 4.2 should include the registrar's email address from which notification messages are sent and a suggestion that Registered Name Holder save this email address as a 'safe sender' to avoid notification emails being blocked by spam filter software.
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."