.gov.uk Registry Operational Policies

This document sets out the policies that cover the operation of the .gov.uk domain registry which consists of the single .gov.uk DNS zone. In agreeing to the .gov.uk Registry-Registrar Agreement (“RRA”), registrars and registrants agree to adhere to the policies set out in this document: 

  1. .gov.uk Registry Contact Data Policy
  2. .gov.uk New Registration Policy 
  3. .gov.uk Inter-registrar Transfer Policy 
  4. .gov.uk Registry-Registrar Lifecycle Policy 
  5. .gov.uk Add Grace Period Limits Policy 
  6. .gov.uk Registry Lock Policy 
  7. .gov.uk Billing and Pricing Policy 
  8. .gov.uk Reseller Policy 
  9. .gov.uk Registry Checks Policy 

Note: minor updates were made on the 16th August 2024 to policies to remove references to the Cabinet Office following CDDO being transferred to the Department for Science, Innovation and Technology.


.gov.uk Registry contact data Policy.

1. Policy version: 1.0 – 15th February 2024

2. Contact Information

2.1. Registrant must supply contact information to the Registrar at the time of registration and it must be updated as and when the contact data changes. Registrant’s are responsible for ensuring all contact data remains accurate.

2.2. Registrar must supply the Registrant’s contact information to the Registry at the time of registration and it must be updated as and when the contact data changes.

2.3. There are four types of contacts stored in the Registry.

2.3.1. Registrant is mandatory:

2.3.1.1. This contact will be recognised as the beneficial user who is legally responsible for the domain and must be provided by the Registrar to the Registry operator.

2.3.1.2. The data within this contact object must be Role based, not including any personal details and will be published.

2.3.2. Administrative contacts are optional:

2.3.2.1. This contact may be either an individual or a role. They must be at the registrant organisation.

2.3.2.2. The registry may add additional administrative contacts per the Registry Lock policy.

2.3.3. Technical contacts are optional:

2.3.3.1. This contact may be either an individual or a role. They may be at the registrant organisation or a third-party providing service to the registrant, but they must be involved in the process the registrant uses to effect change to their authoritative DNS.

2.3.3.2. Multiple technical contacts are allowed per domain.

2.3.3.3. This data will not be published but may be used by the Registry or CDDO to contact the registrant.

2.3.4. Billing contacts are optional:

2.3.4.1. This contact, if provided, should represent either an individual or a role at the registrant organisation that is responsible for arranging payment for service to the registrar.

2.3.4.2. This data will not be published but may be used by the Registry or CDDO to contact the registrant.

2.4. The sole purpose of the Contacts is to provide legal and/or role specific contact details for the Registrant to the Registry and/or third parties for legitimate purposes (e.g. CDDO contacting registrants to address domain related vulnerabilities, or if a Registrar ceases trading and domains need to be moved to an alternative Registrar, or legitimate legally valid requests for disclosure, etc.).

2.5. Registrars and/or Resellers and/or Registrants must not:

2.5.1. use the Contact fields for any purpose other than as set out in paragraph 2.c. (e.g. “This domain is for sale”).

2.5.2. do anything which may have the effect of concealing the true identity of the Registrant from the Registry Operator unless specifically permitted otherwise by another published Registry policy.

2.6. Each contact is made up of the following information:

2.6.1. Name

2.6.1.1. If an individual then the contacts legal name.

2.6.1.2. If an organisation then the role within the organisation.

2.6.2. Organisation

2.6.2.1. The legal name of the organisation.

2.6.3. Address

2.6.3.1. A full postal address for the contact.

2.6.4. Telephone

2.6.4.1. A phone number including country code for the contact.

2.6.5. Fax

2.6.5.1. Optional fax number for the organisation.

2.6.6. Email

2.6.6.1. An email address for the contact.

2.6.7. Disclosure fields

2.6.7.1. The registry will not adhere to disclosure fields and is configured to disclose data as defined in this policy.

2.7. Registrars can update the contact information in the Registry using EPP or website.

3. DISCLOSURE OF CONTACT INFORMATION

3.1. When a contact object is associated as the Registrant of a domain, the details within that contact will be published in full on the Registry Data Directory Service (“RDDS”) for gov.uk. A registrar is not permitted to include any personal information on contacts used for registrants except where explicit consent for disclosure is provided.

3.2. Contact objects associated with Administrative, Technical or Billing contacts linked to the domain will not be published on RDDS.

4. MAINTENANCE OF CONTACT INFORMATION

4.1. Failure to notify changes to contact or other information may result in the suspension or deletion of the Registrant’s domain.

4.2. Registrars must update Registrant data in the Registry within five (5) business days of receiving the updated information from the Registrant.

4.3. At least annually, a Registrar must present to the Registrant the current domain contact information and remind the Registrant that the provision of inaccurate contact data can be grounds for suspension or deletion of their domain. Registrants must review their domain contact information and make any corrections.

4.4. When a Registrar restores a domain (from the redemption grace period) that had been deleted on the basis of submission of false contact data or non-response to Registrar inquiries, the domain must be placed on clientHold status until such time that the Registrant has provided updated and accurate contact information.

4.5. Change of Registrant versus updates to contact details.

4.5.1. Updates to a single contact object will be recognised as corrections to existing contact data for an existing legal entity.

4.5.2. To change the legal entity that is the Registrant of a domain a new contact object should be created with the new Registrants’ details and the domain updated to utilise the new contact object.

5. PROHIBITION OF PRIVACY and PROXY services – Registrars, Resellers and Registrants are forbidden from providing privacy and/or proxy services for domain contact information to the Registry.


.gov.uk New Registration Policy.

1. Policy version: 1.1 – 16th August 2024

2. .gov.uk is a restricted registry, in which new registrations are immediate but require the supply of a pre-approved registration Membership Token to the registry system.

3. Membership tokens are supplied by the Central Digital & Data Office (“CDDO”) following the approval of an application made to them.

4. To register a domain:

4.1. a potential registrant must:

4.1.1. Select an accredited registrar.

4.1.2. Request their registrar apply for the domain name on their behalf.

4.2. A registrar:

4.2.1. Must submit an application to CDDO to request approval for the potential registrant to register their chosen domain name string.

4.2.2. Must obtain the registration membership token from CDDO.

4.2.3. May validate if a token is valid for a particular domain using the registry web portal or EPP service.

4.2.4. Must supply the registration token to the registry using either the registry web portal or EPP service as part of a normal domain registration request.

4.3. The registry will immediately validate and verify the details within the token in response to either a check or a registration request.

5. Registration membership tokens expire; it is important to use the token to create the domain before that expiry time or it will not be possible to register the domain unless a new token is obtained.


.gov.uk Inter-registrar transfer policy.

1. Policy version: 1.0 – 15th February 2024

2. 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.

3. Registrant request transfer authorisation code from losing Registrar.

3.1. In order to transfer a domain between Registrars a Registrant must ask the losing Registrar to:

3.1.1. Set and provide them with a Transfer Authorisation Code. Any request to set a new Transfer Authorisation Code will also be considered to be a request to expire any existing transfer authorisation codes.

3.1.2. Remove any Registrar set transfer locks on their domain before requesting the gaining Registrar to transfer the domain.

4. Losing Registrars must when asked to transfer a domain:

4.1. Ensure authenticity of the request from their Registrant.

4.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.

4.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.

4.3. Set a Transfer Authorisation Code at the registry for the domain.

4.4. Provide the Transfer Authorisation Code to the Registrant within 5-days at no charge.

4.5. Retain records, which must be made available to the registry compliance team in a dispute or audit, pertaining to the provision of the Transfer Authorisation Code for 15 months including:

4.5.1. Timestamp of Transfer Authorisation Code being set.

4.5.2. Communication method of the Transfer Authorisation Code.

4.5.3. Who the Transfer Authorisation Code was provided to.

5. The Registrant:

5.1. May request that the transfer is done:

5.1.1. without renewal except if the domain is in the auto renew grace period; or

5.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.

5.2. Must:

5.2.1. agree to the gaining Registrars’ terms and conditions of service including binding to current registry policies and Registrant Terms and Conditions.

5.2.2. request the transfer of the domain by providing a valid Transfer Authorisation Code to the gaining Registrar.

6. The gaining Registrar must:

6.1. bind the Registrant to their terms and conditions and the registry policies and be able demonstrate this to the registry compliance team.

6.2. submit a transfer request to the registry:

6.2.1. including the Transfer Authorisation Code.

6.2.2. only request a renewal with transfer if the Registrant has requested the renewal period.

6.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.

7. The Registry will upon receipt of a transfer request:

7.1. Verify that:

7.1.1. no locks exist on the domain to prevent transfer;

7.1.2. the Transfer Authorisation Code for the domain is valid.

7.2. Provided the verification in preceding step is OK, move the domain to the new Registrar:

7.2.1. If the Registrar did not request renewal the domain will transfer with no charge from the Registry to the Registrar.

7.2.2. If the Registrar requested a renewal the appropriate renewal term will be processed as part of the transfer.

7.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.

8. Complaints regarding inter-Registrar transfers

8.1. A complaint may be made to the registry by a Registrant against the losing Registrar if:

8.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.

8.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.

8.2. A complaint may be made by the losing Registrar to the registry as to the legitimacy of an inter-registrar transfer

8.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 the registry.

8.3. The outcome of any compliance investigation into any complaint under this policy may result in the Registry:

8.3.1. Upholding the status quo.

8.3.2. Putting a domain into the state the Registrant intended.

8.3.3. Suspending a Registrar’s Accreditation for breach of policy.

8.3.4. Terminating a Registrar’s Registry-Registrar Agreement for breach of policy.

Diagram of Inter-Registrar Transfer process.


.gov.uk Registry-Registrar Lifecycle policy.

1. Policy version: 1.0 – 15th February 2024

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. Pending Transfer Period – 0 days.

2.4. Transfer Grace Period – 5 days.

2.5. Transfer Lock on registration, transfer or change of registrant – No lock and no registrar-imposed lock allowed except with explicit consent of the registrant.

2.6. Auto-renew Grace Period – 45 days.

2.7. Redemption Grace Period – 30 days.

2.8. Pending Delete Grace Period – 0 days.

3. Notice to Registrants of Fees and Procedures

3.1. Registrars must make their renewal fees reasonably available to Registrants and prospective Registrants at the time of registration of a domain.

3.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.

3.1.2. Additionally, Registrars must ensure that these fees are displayed on their resellers’ websites.

4. Domain cancellation

4.1. If a Registrant wishes to cancel their domain, they may do so at any time subject to registry policies.

4.1.1. To cancel a domain a Registrant must do so via their Registrar, requesting the deletion of their domain.

4.2. Registrars must:

4.2.1. Reject cancellation requests for any domains with a ‘server delete prohibited’ lock.

4.2.2. Process properly authorised domain cancellation requests from a registrant within 5 days by requesting the registry to ‘delete’ the domain.

4.3. The registry will:

4.3.1. Provided a domain is not subject to a delete prohibition place a deleted domain into the Redemption Period.

4.3.2. If the domain is not restored within the Redemption Period put the domain into a pending delete grace period.

4.3.3. At the end of the pending delete grace period purge the domain from the registry.

5. Expiration Reminder Notices

5.1. Registrars are required to notify Registrants of their expiry date at least as follows:

5.1.1. Approximately one month prior to expiry;

5.1.2. Approximately one week prior to expiry;

5.1.3. If not renewed by the Registrant with the Registrar before expiry at or within 5 days after expiry.

5.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.

5.1.5. Registrars must describe the methods used to deliver pre- and post-expiration reminder notifications to Registrants.

5.1.5.1. If a Registrar offers registration and renewal via a website the information must be displayed there.

5.1.5.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.).

5.1.5.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.

5.1.5.4. Additionally, Registrars must ensure that these communication methods are described on their resellers’ websites.

6. Renewals

6.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.

6.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).

6.3. Failure by the Registrar to delete the domain within the auto-renew grace period will result in the domain being renewed for a 1-year period.

6.4. Extenuating circumstances are defined as:

6.4.1. Dispute service action

6.4.2. Valid court order

6.4.3. failure of a Registrar’s renewal process (which does not include failure of a Registrant to respond),

6.4.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),

6.4.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),

6.4.6. domain subject to litigation in a court of competent jurisdiction

6.4.7. other circumstance as approved specifically by the registry.

6.5. 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 the registry.

6.6. 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.

6.7. Registrars are not required by registry policy to interrupt the DNS resolution path during the auto-renew grace period of an expired domain but 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.

6.8. 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.

6.9. 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.

6.10. 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.

7. Renew Grace Period

7.1. Only one Renew Grace Period can apply to a domain.

7.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. Redemption Grace Period

8.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.

8.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.

8.3. Registrars must permit the Registrant to restore a deleted domain during Redemption Grace Period for no additional charge other any outstanding renewal fees.

8.3.1. The registry restore fee will be zero pounds (GBP 0).

9. Impact of disputes. In the event that a domain which is the subject of a Registration dispute is deleted or expires during the course of 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.


.gov.uk add grace period limits policy.

1. Policy version: 1.0 – 15th February 2024

2. The Add Grace Period (AGP) shall be restricted as:

2.1. During any given month, the registry 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 the registry.

2.2. A Registrar may seek an exemption from the registry 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 the registry how, at the time the domains were deleted, these extraordinary circumstances were not known, 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 the registry full details of the DNS abuse or fraudulent registrations.


.gov.uk Registry Lock Policy.

1.Policy version: 0.1 – 15th February 2024

2. It is intended that this policy will evolve to align with industry standard approaches to Registry Lock where the registrar is able to arrange it for the customer but at the time of transition to Nominet the .gov.uk Registry Lock will operate directly with the registry dealing with the registrant.

2.1. The evolution of the policy will be notified as a policy update.

3. To setup a new Registry Lock please contact the CDDO support team.

4. CDDO will carry out initial authentication of the security contacts for a domain at the registrant and add the authorised contacts to the registry.

5. The authorisation contacts for any domain will be added as an additional ‘Administrative’ contact linked to a domain.

5.1. The contact object will be locked so only the Registry and CDDO can update it.

6. Authentication of any request to unlock a domain will be carried out by the Registry.

7. Re-locking will be arranged by the registry with the security contact.

8. Registrars will be unable to delete any domains which are locked by the registry from deletion for whatever reason and therefore will be liable for renewal of those domains at the time of expiry; registrars may wish to ensure their terms and conditions with registrants cover this scenario.


.gov.uk Domain Billing and Pricing Policy.

1.Policy version: 1.1 – 16th August 2024

2. Pricing for domains in .gov.uk is set by the Central Digital & Data Office (“CDDO”) and billed by and paid to the Registry Operator.

3. Standard domain pricing is:

3.1. Each annual increment of a create or renew is GBP10.

3.2. Transfer between registrars without renewal is GBP0.

3.3. Restore a domain from redemption period is GBP0.

4. Pricing may be varied by CDDO at any time; any increase for a registered domain will have a minimum of six (6) months notice.

5. The registry system will always confirm the up-to-date prices for any domain.

6. Registrars will receive consolidated monthly invoices for all transactions.


.gov.uk Reseller Policy

1. Policy version: 1.0 – 15th February 2024

2. Registrars are encouraged to deal directly with Registrants but are not prohibited from dealing with Registrants indirectly (for example, through ‘Resellers’) but:

2.1. Registrar’s may not transfer, subcontract or delegate any of their rights or obligations under the Registry-Registrar Agreement or Registry Policies;

2.2. as between Registrar and Registry, Registrars are responsible for the Registrant and the information, service, marketing and advice they are given, whether or not the Registrar actually deal with them directly;

2.3. the Registry is not required to deal with, or give any recognition or special privilege to, any Registrar’s Resellers;

2.4. any actions by a Registrar’s Resellers may have a direct impact on that Registrar’s compliance and will be treated as actions by the Registrar for the purposes of compliance with both Registry Registrar Agreement and Registry Policy;

2.5. Registrar’s must make their Resellers aware of the Registry’s policies and Registrar Accreditation Agreement terms, available from our website, and ensure that the way that they deal with Registrants is compatible with those policies and terms; and Registrar’s contract with their Reseller must be compatible with the terms of the Registry Registrar Agreement and Registry Policies. If we ask for it, a Registrar must provide the Registry with copies of their contracts with their Resellers, or relevant excerpts that relate to our domain registrations or the issue at hand.

2.6. It is a Registrar’s responsibility to ensure that information given to their Resellers which is relevant to the domain entry is provided to the Registrar and that the Registry is updated accordingly. For example, where we oblige the Registrar to do something because the Registrar becomes aware of a change in Registrant’s information or situation, this also applies to a situation where the Registrar’s Reseller has become aware of a change in Registrant’s information or situation.

2.7. On request a Registrar must confirm to the Registry whether a person or organisation is a Reseller and provide the Registry with full contact details for them.


.gov.uk Registry Checks Policy

1. Policy version: 0.2 – 16th August 2024

2. The purpose of this policy is to ensure domains registered in the .gov.uk registry meet technical and operational requirements set by the Central Digital & Data Office (“CDDO”). The aim of these requirements is to ensure a safe, secure and robust public sector namespace.

3. The Registry may carry out checks on the configuration status of any domain name:

3.1. at the point of create of a domain name;

3.2. at the point of update of a domain name; and

3.3. from time to time.

4. Any checks carried out by the Registry may either be a:

4.1. Soft check – which is done in the background and has no impact on other aspects of registry behaviour.

4.2. Hard check – which must pass before the registry systems will allow a create or update to complete.

5.1.1. When a hard check is required before a create or an update is made the domain will be entered into a pendingCreate or pendingUpdate state while the check is being carried out.

5.1.2. If all Hard check pass:

5.1.2.1. The create or update is implemented.

5.1.3. If one or more Hard checks fail:

5.1.3.1. The Registrar will be notified by EPP; and

5.1.3.2. The Registrar’s web interface will show the failure information on the domain and the domain will remain in pending state.

5.1.4. Hard checks will be re-tested automatically;

5.1.5. If the Hard checks continue to fail after 48-hours the create or update request will be automatically cancelled.

5.1.6. The Registry will operate a comply or justify approach to Hard checks before completing any create or update request. Where there is a sound reason that a particular check should not apply to a particular domain at that time the Registry may at its discretion override a failure and complete the update. Any request to override the Hard check should be made by the Registrar to the Registry support team with a justification.

5.1.7. The Registrar will be able to withdraw a create or update request which is failing a hard check via the web portal.

6. The Registry may, from time to time, provide Registrars with list of soft check failures for domains they manage that must be resolved.

7. When either a soft check or a hard check fails Registrars must work with Registrants to resolve any check failures in a timely manner:

7.1. Registrars are required to ensure the Registrant is aware of any failures and advise on how to correct them, and should retain evidence of notifications to registrants for the purposes of audit;

7.2. Registrants are required to correct any failing checks in a timely manner.

7.3. The Registry reserves the right to place restrictions on a domain that is not updated to ensure checks pass.

8. Registrars must ensure their agreements with Registrants require Registrants to implement any DNS updates required to ensure checks do not fail.


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