Registering a domain

Registration is two things in sequence: a contact record the registry will accept, and then the domain itself. The second part takes a minute. The first part is where people get stuck, so do it first.

Contacts and verification

A domain needs an Owner (Owner-C) and an Administrator (Admin-C). Create them under Domains → Contacts, as either a person or an organisation.

A registration is refused unless the Owner-C has both a verified email address and a verified phone number. The portal states the reason:

According to the NIS2 regulation, contact details for domains must be verified
to ensure the domain holder can be reached.

What verification actually looks like

You get a 6-digit code, not a link. Ask for it with Send code next to the contact, then type it into Enter verification code.

Channel	How it arrives	How long the code lasts
Email	Email containing the code	15 minutes
Phone	SMS containing the code	10 minutes

If the code has run out you get Code expired. Please request a new one. Ask for a new one rather than retyping the old.

Your own address may already be done

If the contact's email address is the same as the verified email on your account, it is verified the moment the contact is created and the portal says Email was automatically verified. The phone number still needs a code.

The deadline on a new contact

A contact you create carries a verification deadline 30 days out. The portal counts it down as {days} days remaining, warns as it approaches, and then shows:

The verification deadline has passed. Please update and verify your contact
details.

An expired contact cannot register a domain

Past the deadline the contact is no longer usable for a new registration, and the failure surfaces during checkout rather than when you pick the contact. Verify a contact the day you create it.

Verification does not last forever

A year after its email was confirmed, a contact needs confirming again. You are reminded by email, and reminded again every 30 days. If nothing is confirmed within 60 days of the first reminder the email goes back to unverified, and the contact stops being usable for new registrations until you confirm it again. The portal flags this as Verification expired - please confirm again.

Organisation contacts are published

Organisation data is publicly visible in WHOIS (RDDS). The portal's own advice is worth following: use a functional address such as info@, admin@ or domain@ on an organisation contact rather than someone's personal mailbox.

Searching

Domains → Register domain takes either a bare name or a full one. A bare name (example) is checked across extensions; a full name (example.co.uk) checks only that one. Press Enter to run the check.

Multi-check accepts a list, one per line, separated by line breaks, commas or semicolons, and you can upload a file instead. The line format also carries an auth code for a domain you are bringing in:

example.co.uk
example.com:AUTHCODE

Results are labelled Available, Taken, Invalid, Not supported or Error. Taken is still actionable: the result offers a transfer instead of a registration, which is the entry point described under Transfers. Not supported means the extension is one we cannot sell; a few registries impose requirements the portal cannot satisfy, and those are refused at checkout rather than half-ordered.

Adding to the cart is an icon button on the result row, not a labelled one; its tooltip reads Register or Transfer depending on the status.

Search is rate limited to 10 checks a minute. Prefer one multi-check over many single checks.

Checkout

Everything goes through the cart, including transfers. Before you can check out with a domain in it, the cart shows a panel headed Verified contact required listing what is missing:

Line	Meaning
Email verified / Email not verified	The Owner-C's email
Phone verified / Phone not verified	The Owner-C's phone number
Verification deadline expired	The contact is past its 30 days

Verify contacts takes you straight there. Both lines have to be green.

Rules differ by extension

Each extension carries its own registry rules, and the portal applies them rather than letting the registry reject you later. What varies:

Rule	What it means for you
Permitted contact types	Some extensions accept only a person, some only an organisation, for owner or admin or both
Local presence	The owner or the admin must be resident in the extension's country
Name length	A minimum and a maximum number of characters, excluding the extension
IDN	Whether non-ASCII characters are accepted at all, and which ones
WHOIS protection	Whether the registry offers it
Trustee	Whether a trustee can stand in for a local contact
Transfer lock	Whether the extension supports locking
Auth code	Whether a transfer of this extension needs one

A non-ASCII name is stored alongside its ASCII form, and the ASCII form is what DNS and certificates actually carry. So xn-- turning up in a certificate or a dig answer for a domain you registered with umlauts is correct, not a fault.

Some extensions are HTTPS-only, at the browser

.app, .dev, .page, .new and fourteen more in the same family are on the HSTS preload list. Browsers refuse plain HTTP on them outright, so a plain-HTTP test of a fresh site under one of these fails before it reaches any server of ours. Serve HTTPS from the start; there is nothing to configure at the registry, and ordering one accepts that condition.

Paid add-ons

Two extras are available per domain, from Domain Actions, where the registry offers them:

• WHOIS protection hides your personal data from public WHOIS queries.
• Trustee service puts a local trustee in the admin contact role, which is what makes an extension with a local-presence rule usable.

Both are billed per year and the charge lands at the next renewal, not immediately. The portal says so before you confirm:

{addon} will be added to your contract for {price} per year (incl. VAT).
Billing occurs at the next renewal.

Where the registry does not offer one you get {addon} is not available for .{tld} domains. That is the registry's rule, not a setting, so there is nothing to change.

What's next

• DNS records to point the new domain somewhere
• Renewal, cancellation and restore for what happens a year from now
• Gateway API if it is going to serve a Kubernetes workload