.UK (DRAFT) policies

.UK Legacy platform

The .UK Registry currently operates on our legacy platform; we have announced that we will move .UK to our Registry Services Provider (RSP) platform in 2026.  To find out current information about the legacy platform please use the UK namespace section of registrar resources.

This area of registrar resources will document the upcoming features and policies for .uk on our more modern RSP platform; planned transition will be in 2026.

The policies currently listed below are the confirmed drafts based on the results of the 2024 consultation. They remain labelled as draft until we have completed the wider consultation on all policies and agreements that integrate with them – at this time we do not expect to have any substantive changes to these policies.


.UK Inter-registrar transfer policy

  1. Policy version DRAFT-2024-06
  2. This document sets out the inter-Registrar transfer policy for the .UK top level domain.
  3. It is a fundamental policy principle for the registry that Registrants may choose from a competitive Registrar market to register or maintain their domains and must be able to move between Registrars accordingly.
  4. Registrant request transfer authorisation code from losing Registrar.
    4.1. To transfer a domain between Registrars, a Registrant must ask the losing Registrar to:
    4.2. Set and provide them with a Transfer Authorisation Code. Any request to set a new Transfer Authorisation Code will also be a request to expire any existing transfer authorisation codes.
    4.3. Remove any Registrar set transfer locks on their domain before requesting the gaining Registrar to transfer the domain.
  5. Losing Registrars must when asked to transfer a domain:
    5.1. Ensure the request is authentic from their Registrant.
    5.2. Remove any transfer locks that the Registrar has set on the domain at no charge within 5-days when asked to do so by the Registrant – unless the Registrar can show the lock is in place to prevent a case where they reasonably believe domain name abuse is taking place and/or to adhere to other registry policies.
    5.2.1. For the avoidance of doubt, a Registrar imposing a transfer lock without consent of the Registrant after create, update or transfer in of a domain or its associated objects where there is no other evidence of domain name abuse or breach of policy is not allowed. Consent may be provided within a registrar’s terms and conditions, but any terms may not restrict the registrants right to removal of the lock in accordance with registry policy.
    5.3. Set a Transfer Authorisation Code at the registry for the domain.
    5.4. Provide the Transfer Authorisation Code to the Registrant within 5-days at no charge.
    5.5. Retain records, which must be made available to Nominet’s compliance team in a transfer dispute or audit of compliance, pertaining to the provision of the Transfer Authorisation Code for 15 months including:
    5.5.1. Timestamp of Transfer Authorisation Code being set.
    5.5.2. Communication method of the Transfer Authorisation Code.
    5.5.3. Who the Transfer Authorisation Code was provided to.
  6. The registry will set a Time To Live (TTL) on any Transfer Authorisation Code that is created. Only one Registrar set Transfer Authorisation Code may exist at a time on any one domain.
  7. The Registrant:
    7.1. May request that the transfer is done:
    7.1.1. without renewal, provided the gaining registrar supports incoming transfer without renewal, except if the domain is in the auto renew grace period; or
    7.1.2. With renewal of a period of 1-10 years except where that would result in an expiry date of more than 10 years in the future.
    7.2. Must:
    7.2.1. agree to the gaining Registrars’ terms and conditions of service including binding to current registry policies and Registrant Terms and Conditions.
    7.2.2. request the transfer of the domain by providing a valid Transfer Authorisation Code to the gaining Registrar.
  8. The gaining Registrar must:
    8.1. bind the Registrant to their terms and conditions and the registry policies and Registrant Terms and Conditions and be able demonstrate this to Nominet’s compliance team.
    8.2. submit a transfer request to the registry:
    8.2.1. including the Transfer Authorisation Code.
    8.2.2. only request a renewal with transfer if the Registrant has requested the renewal period. For the avoidance of doubt registrars are free to charge for incoming transfers whether a renewal is requested or not.
    8.2.3. If the domain is in the auto renew grace period, the registrar must request a minimum of one year renewal for the transfer to be accepted.
  9. The Registry will immediately upon receipt of a transfer request:
    9.1. Verify that:
    9.1.1. no locks exist on the domain to prevent transfer;
    9.1.2. the Transfer Authorisation Code for the domain is valid.
    9.2. Provided the verification in preceding step is OK, move the domain immediately to the new Registrar:
    9.2.1. If the Registrar did not request renewal, the domain will transfer with no charge from the Registry to the Registrar.
    9.2.2. If the Registrar requested a renewal the appropriate renewal term will be processed as part of the transfer.
    9.2.3. If the domain is in the auto renew grace period, the auto renewal will be cancelled resulting in only the renewal requested as part of the transfer request being charged.
    9.2.4. Expire the Transfer Authorisation Code from the domain.
  10. The registry will if it has not received a transfer request in 15-days from the time the Transfer Authorisation Code was set, expire the Transfer Authorisation Code.
  11. Complaints regarding inter-Registrar transfers
    11.1. A complaint may be made to Nominet by a Registrant against the losing Registrar if:
    11.1.1. the losing Registrar fails to remove a transfer lock and/or provide a Transfer Authorisation Code to a Registrant in accordance with this policy.
    11.1.2. The losing Registrar does not take reasonable steps to ensure the authenticity of a request to provide a Transfer Authorisation Code; and/or provides the Transfer Authorisation Code to an unauthorised third party.
    11.2. A complaint may be made by the losing Registrar to Nominet as to the legitimacy of an inter-registrar transfer
    11.2.1. The losing Registrar may dispute an inter-registrar transfer which has completed on behalf of, and with the consent of, the Registrant by raising a complaint with Nominet.
    11.2.2. The outcome of any compliance investigation into any complaint under this policy may result in the Registry:
    11.2.2.1. Upholding the status quo.
    11.2.2.2. Putting a domain into the state the Registrant intended.
    11.2.2.3. Suspending a Registrar’s Accreditation for breach of policy.
    11.2.2.4. Terminating a Registrar’s Registry-Registrar Agreement for breach of policy.

.UK Registry-Registrar Lifecycle Policy

  1. Policy version: DRAFT-2024-06
  2. The registry operates a lifecycle with Registry Grace Periods as follows:
    2.1. Add Grace Period (subject to add grace period limits policy): 5 days.
    2.2. Renew Grace Period: 5 days
    2.3. Transfer Grace Period: 5 days
    2.4. Auto-renew Grace Period: 45 days
    2.5. Redemption Grace Period: 30 days
    2.6. Pending Delete Grace Period: 5 days.
  3. Transfer Lock on registration, transfer or change of registrant
    3.1. The registry will not apply a transfer lock on registration, transfer or change of registrant.
    3.1.1. Registrars may and are encouraged to utilise transfer locks as a matter of good security practice but where they do so must remove them at the Registrants request in accordance with the .UK Inter-Registrar Transfer Policy.
  4. Notice to Registrants of Fees and Procedures
    4.1. Registrars must make their renewal fees reasonably available to Registrants and prospective Registrants at the time of registration of a domain.
    4.2. 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.2.1. Additionally, Registrars must ensure that these fees are displayed on their resellers’ websites.
  5. Domain cancellation
    5.1. If a Registrant wishes to cancel their domain, they may do so at any time subject to registry policies.
    5.2. To cancel a domain a Registrant must do so via their Registrar, requesting the deletion of their domain.
    5.3. Registrars must:
    5.3.1. Reject cancellation requests for any domains with a ‘server delete prohibited’ lock.
    5.3.2. Process properly authorised domain cancellation requests from a registrant within 5 days by requesting the registry to ‘delete’ the domain.
    5.4. The registry will:
    5.4.1. Provided a domain is not subject to a delete prohibition place a deleted domain into the Redemption Period.
    5.4.2. If the domain is not restored within the Redemption Period put the domain into a pending delete grace period.
    5.4.3. At the end of the pending delete grace period purge the domain from the registry.
  6. Expiration Reminder Notices
    6.1. Registrars are required to notify Registrants of their expiry date at least as follows:
    6.1.1. Approximately one month prior to expiry;
    6.1.2. Approximately one week prior to expiry;
    6.1.3. If not renewed by the Registrant with the Registrar before expiry at or within 5 days after expiry.
    6.1.4. If a change of Registrant occurs at or after one month before expiry the new Registrant must be notified of the expiry date.
    6.2. Registrars must describe the methods used to deliver pre- and post-expiration reminder notifications to Registrants.
    6.2.1. If a Registrar offers registration and renewal via a website the information must be displayed there.
    6.2.2. 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 Registrant, telephone call to administrative contact, postal mail to customer, etc.).
    6.2.3. 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.
    6.2.4. Additionally, Registrars must ensure that these communication methods are described on their resellers’ websites.
  7. Renewals
    7.1. A Registrar must not renew a domain without the explicit consent of a Registrant. A Registrar is offered, by the registry, the benefit of the auto-renew grace period to receive that consent.
    7.2. Failure by the Registrant to consent to the renewal of a domain, shall in the absence of extenuating circumstances, result in the deletion of the domain by the end of the auto-renew grace period by the Registrar (although the Registrar may choose to delete the name earlier).
    7.2.1. Extenuating circumstances are defined as:
    7.2.1.1. Dispute service action
    7.2.1.2. Valid court order
    7.2.1.3. failure of a Registrar’s renewal process (which does not include failure of a Registrant to respond),
    7.2.1.4. the domain is used by a nameserver that provides DNS service to third-parties (additional time may be required to migrate the records managed by the nameserver),
    7.2.1.5. the Registrant is subject to bankruptcy proceedings, payment dispute (where a Registrant claims to have paid for a renewal, or a discrepancy in the amount paid), billing dispute (where a Registrant disputes the amount on a bill),
    7.2.1.6. domain subject to litigation in a court of competent jurisdiction
    7.2.1.7. other circumstance as approved specifically by Nominet.
    7.3. Where the Registrar chooses, under extenuating circumstances, to renew a domain without the explicit consent of the Registrant, the Registrar must maintain a record of the extenuating circumstances associated with renewing that specific domain for inspection by Nominet.
    7.4. In the absence of consent to renew by the Registrant or extenuating circumstances, a Registrar must request deletion of a domain within the auto-renew period.
    7.4.1. A Registrar may achieve compliance with this requirement by configuring their accreditation at the registry to auto-delete at the end of the auto-renew period and triggering manual renewals for all renewed domains.
    7.5. Registrars are not required by registry policy to interrupt the DNS resolution path during the auto-renew grace period of an expired domain. However, if the Registrar directs web traffic to the domain to a web page while the domain is still renewable by the Registrant, that web page must conspicuously indicate that the domain is expired and provide renewal instructions.
    7.6. Registrars shall provide notice to each new Registrant describing the details of their deletion and auto-renewal policy including the expected time, at which a non-renewed domain would be deleted relative to the domains expiration date, or a date range not to exceed ten (10) days in length. If a Registrar makes any material changes to its deletion policy during the period of the registration agreement, it must make at least the same effort to inform the Registrant of the changes as it would to inform the Registrant of other material changes to the registration agreement.
    7.7. If the Registrar operates a website for domain registration or renewal, details of the Registrar’s deletion and auto-renewal policies must be clearly displayed on the website.
    7.8. Beginning at the time of expiration and through to the end of the Redemption Grace Period the Registrant at the time of expiration must be permitted by the Registrar to renew the expired domain.
  8. Renew Grace Period
    8.1. Only one Renew Grace Period can apply to a domain.
    8.2. Domains in Renew Grace Period can be renewed but in doing so that confirms the acceptance of the early end of any existing Renew Grace Period.
    8.3. A registrar may un-renew a domain during the Renew Grace Period.
    8.3.1. In the event an un-renew returns the domain to an expiry timestamp in the past, the domain will be treated as having entered the Auto-Renew Grace period at the expiry timestamp as if it had never had a Renew Grace Period.
  9. Redemption Grace Period
    9.1. The registry offers a Redemption Grace Period immediately following the deletion request of a domain, during which time the deleted domain may be restored at the request of the Registrant by the Registrar that deleted it. Domains deleted during the registry add-grace period are not subject to the Redemption Grace Period.
    9.2. During the Redemption Grace Period, the registry disables DNS resolution and prohibits updates. The registry will also clearly indicate in its Registration Data Directory Service result for the domain that it is in its Redemption Grace Period.
    9.3. Registrars must permit the Registrant to restore a deleted domain during Redemption Grace Period for no additional charge other any outstanding renewal fees.
    9.4. The registry restore fee will be zero pounds (GBP 0).
    9.5. Registrars must not restore domain to assume rights, use or sell the domain for themselves or a third-party that is not the Registrant.
  10. Impact of disputes. If a domain which is the subject of a Registration dispute is deleted or expires during the Registration dispute, the complainant in the dispute will have the option to renew or restore the domain under the same commercial terms as the Registrant. If the complainant renews or restores the domain, the domain will be placed in clientHold and clientTransferProhibited status, the RDDS contact information for the Registrant will be removed, and the RDDS contact entry will indicate that the domain is subject to dispute. If the complaint is terminated, or the dispute finds against the complainant, the domain must be deleted within 45 days. The Registrant retains the right under the existing Redemption Grace Period provisions to recover the domain at any time during the Redemption Grace Period and retains the right to renew the domain before it is deleted.

.UK add grace period limits policy

  1. Policy version: DRAFT-2024-01
  2. The Add Grace Period (AGP) shall be restricted as:
    2.1. During any given month, Nominet shall not offer any refund to a Registrar for any domains deleted during the AGP that exceed:
    2.1.1. 10% of that Registrar’s net new registrations (calculated as the total number of net adds of one-year through ten-year registrations, or
    2.1.2. fifty (50) domains, whichever is greater, unless an exemption has been granted by Nominet.
    2.2. A Registrar may seek an exemption from Nominet from the application of such restrictions in a specific month, upon demonstrating:
    2.2.1. extraordinary circumstances;
    2.2.1.1. For any Registrar requesting such an exemption, the Registrar must confirm in writing to Nominet how, at the time the domains were deleted, these extraordinary circumstances were unknown, reasonably could not have been known, and were outside the Registrar’s control. Acceptance of any exemption will be at the sole and reasonable discretion of the Nominet. However, “extraordinary circumstances” which reoccur regularly for the same Registrar will not be deemed extraordinary.
    2.2.2. evidence the domain(s) were being used to commit DNS Abuse or were fraudulent registrations.
    2.2.2.1. For any Registrar requesting such an exemption, the Registrar must confirm in writing to Nominet full details of the DNS abuse or fraudulent registrations.

.UK Interim Data Quality Policy

  1. Policy version: DRAFT-2024-06
  2. We intend to work with stakeholders to develop a suitable Know Your Customer policy ahead of transitioning .UK to the new Registry platform. In the event this work is not completed ahead of transition, this Interim Data Quality policy will come into effect at transition to the Nominet Registry Services Provider platform.
  3. Introduction: Improving and maintaining the quality of the data on the register for .UK domain names is a key objective for Nominet. We have and will continue to take steps to achieve this and believe that registrars play a key role in helping us to do so. This Data Quality Policy sets out some of the ways we expect registrars to help us improve our data quality. N.B. terms that have been capitalised in this document have the meaning set out in the “Definitions” section at the end of this Policy.
  4. Data Quality Policy Statement. Registrars must submit Complete and accurate data in their transactions with us.
    4.1. Registrars must ensure that data they submit to us can be Validated.
    4.2. All Registrars must be satisfied that the email address for the Registrant is a reliable means by which to contact the Registrant.
  5. Incomplete Data
    5.1. Where data submitted by a Registrar is incomplete, it will not be accepted by our systems and the relevant transaction submitted by the Registrar will be rejected in real time.
  6. Data Validation
    6.1. Nominet may Validate any Registrant data submitted to us. Where Nominet determines that data submitted cannot be Validated, Registrars will be required to take steps to resolve the issue. These requirements are:
    6.1.1. The Registrar must take appropriate steps to confirm to Nominet that the data
    is Valid. For example, the Registrar may choose: to ask the Registrant to provide corrected data; to confirm that the data is reliable based on its own knowledge or information from a trustworthy third party source; or, to obtain documentary evidence that the data is reliable such as a utility bill or similar document.
    6.1.2. Nominet may suspend domain names where we are unable to Validate data.
  7. Processes and Auditing
    7.1. Nominet will monitor a Registrar’s compliance with this policy through its data quality audits of Registrars.
  8. Updating this Policy.
    8.1. Nominet will review this policy on a regular basis to ensure it continues to reflect best practice and current practices within the industry. We may update this policy by providing all Registrars with at least 30 days notice and posting the new policy on our website.
  9. Definitions
    9.1. “Complete” means that data complies with the format requirements enforced by the registry system;
    9.2. “Incomplete” means data that is not Complete; and,
    9.3. “Validate” means confirming that data is reliable by comparing it to data provided by a trustworthy source (which may be a third-party database), and “Valid” and “Validated” shall be understood accordingly.

Minerva House, Edmund Halley Road, Oxford Science Park, OX4 4DQ, United Kingdom