The .cl Domain: Who Can Register One, and What NIC Chile Actually Requires

A .cl domain is the country-code top-level domain for Chile, run by NIC Chile at the University of Chile. Any natural or legal person, domestic or foreign, may hold one — there is no residency requirement, no local contact requirement, and no Chilean tax ID requirement in the registry regulations.

That last sentence is worth stating plainly because a significant share of the pages ranking for this query say the opposite. Several reseller pages state that a Chilean RUT is typically required. The registry’s own operating regulations say otherwise, and the registry is the authority on its own eligibility rules. If you have been putting off a .cl because you assumed you needed a Chilean entity, you probably do not.

Table of contents

• What .cl is, and who runs it
• Who can register: the registry rule versus the reseller myth
• What the registration actually requires
• Renewals, deletion and revocation
• The DNS records you set once you have it
• Pointing a .cl at a deployed site
• How this fits the rest of the stack
• FAQ

What .cl is, and who runs it

.cl is the ISO country code delegation for Chile. It is administered by NIC Chile, which sits inside the Department of Computer Sciences at the Universidad de Chile — an unusual arrangement compared with the commercial registry operators behind most modern TLDs, and one that has been stable for a long time.

The registry publishes its operating regulations openly, maintains the authoritative WHOIS and information service, and sets the fee schedule. It also authorises registrars to handle registration operations on behalf of customers, so you can register directly with NIC Chile or through an accredited third party. Both routes end in the same registry database.

For a business, the practical reading is that .cl behaves like a normal, well-run ccTLD. There is nothing exotic in the process, and nothing that requires a local presence to navigate.

Who can register: the registry rule versus the reseller myth

The regulations state that any natural or legal person, whether domestic or foreign, may hold a .cl domain name. That is the eligibility rule in full. There is no clause requiring Chilean residency, a Chilean company, or a Chilean tax identification number.

The registry does reserve the right to request information to verify a holder’s identity where necessary, which is an anti-abuse provision rather than an eligibility gate. It also reserves certain names for security and DNS-stability reasons, which every registry does.

So why do you keep reading that a RUT is required? Because some registrars do require one — as their own onboarding policy, not as a registry rule. A reseller that only sells to customers it can bill through a Chilean payment path will describe that constraint as a requirement, and from inside their checkout it genuinely is. It is a fact about that vendor, not about .cl.

If a registrar tells you a RUT is mandatory, the correct response is to try a different registrar, not to abandon the domain.

What the registration actually requires

The registry asks for four things, and the fourth is the one that trips people up later:

1. Acceptance of the operating regulations, including an acknowledgement that you understand which characters are permitted in a domain name.
2. A declaration that the name is registered in good faith, for lawful purposes, and does not infringe third-party rights.
3. Complete and accurate registration data, with an undertaking to keep it current.
4. Contact details for the parties allowed to manage the domain. Appointing an administrative contact is mandatory.

The registration is considered validly filed once the fee is paid; the registry then processes it and activates the domain, and sends a confirmation email to the address on file for direct registrations.

The accuracy undertaking has teeth. If the mandatory data is found to be incomplete or inaccurate, the registry may request a correction, and if that request is not satisfied within five calendar days the registration is at risk. This is the specific reason to avoid registering a domain to a personal address you are about to move out of, or an email alias that will stop existing when someone leaves the company.

Renewals, deletion and revocation

Timely payment of applicable fees is an explicit condition of keeping the registration valid. The registry publishes its fee schedule and reserves the right to change it. Nothing unusual there, but the phrasing is worth respecting: the domain is valid while paid, not paid while valid.

Revocation of a registered name is a defined process rather than an informal complaint. An interested party emails a request to the registry and pays the corresponding fee to begin it. Where an arbitration award or a court order requires the registry to change a holder or deactivate a name, it will comply, and the regulations disclaim liability for those actions.

The operational takeaway for anyone running a business on a .cl: set the renewal to automatic, keep a real monitored mailbox as the registrant contact, and keep the registrant details accurate. Those three habits cover essentially every avoidable way a domain gets lost, on any TLD.

The DNS records you set once you have it

A registered domain does nothing on its own. It becomes useful when its nameservers point somewhere and the records underneath resolve. The set most sites need is short:

• A (and AAAA if you serve IPv6) on the apex, pointing at the address of whatever serves your site.
• CNAME on www, pointing at the apex or at your host’s provided hostname. Pick one of apex or www as canonical and redirect the other rather than serving both.
• MX records if the domain receives email. These are entirely independent of where the website is hosted, and forgetting that is how people break their own email during a migration.
• TXT for domain verification and, if you send email from the domain, for SPF and DKIM.

Apex records deserve a note. The DNS specification does not allow a CNAME on the apex of a zone, which is a problem when your host gives you a hostname rather than a fixed address. Most managed DNS providers solve this with a flattening record under a vendor-specific name — ALIAS, ANAME, or a CNAME-flattening toggle. Check that your provider offers one before committing to an apex-canonical setup.

Propagation is the other thing worth setting expectations on. Lower the TTL on the records you are about to change a day before you change them, not on the day. A record with a 24-hour TTL will be served from resolver caches for up to 24 hours after you update it, regardless of how quickly the registry reflects the change.

Pointing a .cl at a deployed site

Once the records resolve, the remaining question is the certificate. Browsers will refuse a .cl served over plain HTTP as loudly as any other domain, and a ccTLD carries no special certificate handling — it is issued and validated exactly like a .com.

The order of operations that avoids a broken window: deploy the site first and confirm it works on the platform-provided hostname, then add the custom domain in the host’s dashboard, then update the DNS records, then wait for the certificate to be issued and confirm it before announcing the domain anywhere. Doing DNS first means pointing real traffic at a certificate that does not exist yet.

On RunxBuild that sequence is the dashboard’s custom-domain flow: add the domain, set the records it shows you, and the certificate is issued and renewed for you. It works the same for a static site and for a backend service, and the renewal is the part you want automated permanently — a manually renewed certificate is a 90-day countdown with no alarm attached.

We do not sell domains, so register the .cl wherever you like. What happens after the registration is the part worth planning.

How this fits the rest of the stack

The .cl registry is more open than its search results suggest: foreign individuals and companies can register, the requirements are accurate contact data and a mandatory administrative contact, and the only hard obligations are paying on time and keeping your details correct. Once it is yours, the work is ordinary DNS followed by a certificate, and the sequencing matters more than the difficulty. If you are pricing what sits behind the domain — a static site, a backend service, a database, the bandwidth — the RunxBuild hosting calculator lays those out as separate line items so you can see the whole number before committing to any of it.

Useful related references:

• What Is a .link Domain, and When Does It Fit a Project?
• .ES Domain: Requirements, the ID Rules, and Setting It Up
• Domain Squatting: What It Is, What You Can Do, and What Is Not Worth Doing
• Custom domains and certificates on RunxBuild

FAQ

Do I need to live in Chile to register a .cl domain?

No. The NIC Chile operating regulations state that any natural or legal person, whether domestic or foreign, may hold a .cl domain. There is no residency or local-contact requirement in the registry rules.

Is a Chilean RUT required for a .cl domain?

Not by the registry. Some registrars impose one as their own onboarding policy, which is why you will see it stated as a requirement on reseller pages. If your chosen registrar demands a RUT, use a different registrar rather than assuming the domain is unavailable to you.

Who operates the .cl registry?

NIC Chile, based in the Department of Computer Sciences at the Universidad de Chile. It maintains the registry database and WHOIS service, sets the fee schedule, and authorises registrars to perform registration operations for their customers.

Can a .cl domain be revoked?

Yes, through a defined process. An interested party must submit a request to the registry and pay the corresponding fee. The registry will also act on arbitration awards or court orders from a competent authority. Separately, registrations with inaccurate mandatory data can be challenged if not corrected within five calendar days of a request.

How long does a .cl domain take to work after registration?

Registration activates once the fee is paid and processed. Actually resolving to your site depends on DNS, not the registry: set the records, and allow for resolver caches to expire based on the TTL you had configured. Lower the TTL in advance of a planned change rather than at the moment of change.