Skip to main content

Registration Data Reminder Policy

Updated 21 February 2024 to reflect changes required to implement the Registration Data Policy. This policy was previously known as the Whois Data Reminder Policy. Contracted parties may implement this updated Policy beginning on 21 August 2024 and must implement no later than 21 August 2025.

At least annually, a registrar must present to the Registered Name Holder the current Registration Data, and remind the Registered Name Holder that provision of false contact information can be grounds for cancellation of their domain name registration. Registered Name Holders must review their Registration Data, and make any corrections.


Introduction: The Registration Data Reminder Policy (RDRP) (formerly Whois Data Reminder Policy) was adopted by ICANN as a consensus policy on 27 March 2003. All ICANN-accredited registrars must comply with the RDRP with respect to registrations they sponsor in all top-level domains for which they are accredited. Details of compliance requirements are provided below.

Process by Which the Policy Was Adopted: The RDRP was established as a consensus policy by ICANN Board resolution 03.41, which was adopted by a 13-1-0 vote by ICANN's Board of Directors on 27 March 2003. It was one of four policies concerning Whois issues that the Generic Names Supporting Organization (GNSO) Council, by a 21-3-0 vote on 20 February 2003, recommended be established as consensus policies.

The GNSO Council and Board votes were based on the Final Report of the GNSO Council's Whois Task Force on Whois Data Accuracy and Bulk Access. That report documented the extent of agreement and disagreement among impacted groups, the outreach process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and the nature and intensity of reasoned support and opposition to the proposed policy.

The report was posted on the ICANN web site on 11 March 2003, with a call for public comment. Various public comments were received and considered by the Board, and the report was discussed at the ICANN Public Forum session held in Rio de Janeiro on 26 March 2003.

Pursuant to Resolution 03.42, notice of the adoption of this policy was given to all registrars on 16 June 2003.

From the policy effective date, each registrar must provide, before the passage of the anniversary of the creation date of each registration the registrar sponsors, a RDRP Notice (described below) to the Registered Name Holder for that registration. By way of example, a registrar with a Compliance Date of 31 October 2003 is required to give a RRDP notice for registrations it sponsors on the following schedule:

Compliance Date is 31 October 2003
Domain Name Creation Date RDRP Notice Required No Later Than 14 October 1995 14 October 2004 (and by 14 October of every year thereafter) 25 June 2003 25 June 2004 (and by 25 June of every year thereafter) 15 June 2003 15 June 2004 (and by 15 June of every year thereafter) 12 November 1997 12 November 2003 (and by 12 November of every year thereafter) 1 January 1993 1 January 2004 (and by 1 January of every year thereafter) 31 December 2002 31 December 2003 (and by 31 December of every year thereafter)

(Note: RDRP Notices for registrations with creation dates of 29 February may be given no later than 1 March in non-leap years.)

What the RDRP Notice Must Include: Each RDRP notice must include a copy of the data elements that are collected by registrars pursuant to Section 6 of the Registration Data Policy and contained in the registrar's database for each registration, plus a statement reminding the Registered Name Holder that under the terms of the registration agreement the provision of false contact information can be grounds for cancellation of a domain name registration (See Registrar Accreditation Agreement, Section

How, and to Whom, the RDRP Notice May Be Presented: The RDRP Notice can be presented via web, fax, postal mail, e-mail, or other appropriate means. It can be presented in one or more languages, including at least the language of the registration agreement.

Documentation Requirements: Registrars must maintain either copies of each RDRP Notice or an electronic database documenting the date and time, and the content, of each RDRP notice sent under this policy (See Registrar Accreditation Agreement, Section 3.4). Registrars shall make these records available for inspection by ICANN in accordance with the usual terms of the Registrar Accreditation Agreement (See Section 3.4.3). ICANN will consider proper notification to have been given for a registration if the registrar can show that a RDRP Notice meeting the requirements stated above was given at any time in the year before each anniversary of the registration's creation date (for anniversary dates on or after the Compliance Date).

Model RDRP Notice: In order to assist registrars in preparing the required notice, ICANN has provided the following Model RDRP Notice:

[Sample] Registration Data Reminder


Dear Valued Customer,

This message is a reminder to help you keep the contact data associated with your domain registration up-to-date. Our records include the following information:

Registrar Name: IANA_RESERVED

Name: Internet Assigned Numbers Authority (IANA)
Address: 4676 Admiralty Way, Suite 330
City: Marina del Rey
State/Province: CA
Country: US
Postal Code: 92092

Technical Contact:1
Name: Internet Assigned Numbers Authority (IANA)
Phone: 310-823-9358

Original Creation Date: 11/01/2001
Expiration Date: 11/01/2001

Nameserver Information:

If any of the information above is inaccurate, you must correct it by visiting our website. (If your review indicates that all of the information above is accurate, you do not need to take any action.) Please remember that under the terms of your registration agreement, the provision of false contact information can be grounds for cancellation of your domain name registration.

Thank you for your attention.

Best regards,
Your ICANN-Accredited Registrar

A set of frequently asked questions concerning the RDRP, from the perspective of the registrant, can be found here.

1 Note: If Technical Contact is collected pursuant to Section 6 of the Registration Data Policy.

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"""" is not an IDN."