Who Really Owns Your Domain: Registrant vs. Admin vs. Technical Contact

Ask a small business owner who owns their domain and they will usually say "we do." Ask them to prove it, and things get murky. The domain might have been registered by a web designer, a former employee, a cofounder, or a hosting company, and the business might appear only as a "technical" or "admin" contact, or not at all. Registration records list several contacts, but only one of them is the legal holder of the domain: the registrant. This article explains the difference between the registrant, administrative, technical, and billing contacts, how ICANN's rules have changed which contacts exist, why the registrar account matters as much as the record itself, and how to check and fix your own domains. For background on where this data is published, see what WHOIS is and how to look up domain ownership.

The Four Traditional Domain Contacts

Historically, every gTLD registration carried four contact records. They could all be the same person, or four different people.

Contact	Who it represents	Typical responsibilities
Registrant	The legal holder of the domain	Holds the rights to use the domain; agrees to the registration agreement
Administrative (admin)	Someone authorized to act for the registrant	Historically, could approve transfers and handle administrative questions
Technical (tech)	Whoever manages the technical setup	Name servers, DNS, and technical problems
Billing	Whoever pays	Renewal invoices and payment questions

The registrant is often referred to in ICANN policy as the Registered Name Holder (RNH). That phrase is the key to the whole topic: the registrant is the person or organization that holds the registration. The other contacts are roles, not owners.

The Registrant: The Legal Holder

The registrant is the person or entity that entered into the registration agreement with the registrar. In most legal and policy contexts, the registrant is treated as the domain's owner, although technically you hold a right to use the name for the registration period rather than owning it like property.

What being the registrant means in practice:

• Disputes are decided in the registrant's favor by default. If two parties argue over a domain, the registrar generally looks at who is listed as registrant, not who paid or who built the website.
• Changes of registrant require the registrant's consent. Under ICANN's Transfer Policy, a material change to the registrant's name, organization, or email is a Change of Registrant, which the registrar must confirm with the prior registrant (and the new one).
• Transfer authorization flows to the registrant. The authorization code used to move a domain to another registrar is provided to the registrant.
• The registrant receives verification and renewal notices. If the registrant email is out of date, notices are missed and verification can fail, which may lead to suspension.
• Dispute proceedings name the registrant. A UDRP complaint is filed against the registrant of record.

Registrant Name vs. Registrant Organization

The registrant record has both a name field and an organization field. If the organization field is filled in, many registrars treat the organization as the registrant, with the named person as its representative. If it is blank, the individual is the registrant.

This matters a lot for businesses. A domain registered with "Jane Smith" as the name and "Smith Bakery Ltd" as the organization is generally treated as belonging to the company. The same domain with the organization left blank belongs to Jane personally, which can become a problem if Jane leaves or the business is sold. Registrar terms differ, so read yours, but as a rule: for a business domain, put the legal company name in the organization field.

The Administrative Contact

The administrative contact was historically the person authorized to deal with the registrar on the registrant's behalf. Under the pre-2016 inter-registrar transfer policy, either the registrant or the admin contact could approve a transfer, which made the admin contact a powerful role. In practice, it was often an employee, an agency, or the registrant themselves.

The admin contact does not own the domain. That has always been true, but it is often misunderstood, especially by businesses whose web designer listed the business as admin contact and themselves as registrant.

The Admin Contact Is Being Phased Out

ICANN's Registration Data Policy, which gTLD registrars were required to implement by August 2025, no longer requires registrars to collect an administrative contact at all, and makes the technical contact optional. Many registrars have removed the admin contact from their forms, and RDAP records increasingly show only the registrant, an optional technical contact, and the registrar's own entities.

Some registrars still store admin and billing contacts for their own account management, and ccTLD registries set their own rules, so you will still see admin contacts on many records. But under current gTLD policy, the registrant is clearly the contact that matters.

The Technical Contact

The technical contact is whoever handles the domain's technical operation, such as name servers and DNS. For many small sites, this is the hosting company or web developer. Registrars and others may contact this person when there is a DNS or name server issue.

The technical contact has no ownership rights. Listing your developer as the technical contact is perfectly reasonable; listing them as the registrant is not. If you are deciding who should manage DNS versus who should hold the registration, domain registrar vs. DNS host explains how those responsibilities split.

The Billing Contact

The billing contact receives invoices and payment-related messages. In gTLD registration data it has long been optional and is rarely published. Paying for a domain does not make you the registrant. This surprises many people: a business can pay for years of renewals and still not be the legal holder if someone else is listed as registrant.

The Other Thing That Decides Control: The Registrar Account

Contact records are only half the picture. The other half is who controls the registrar account the domain sits in.

Scenario	Who effectively controls the domain?
You are the registrant and you own the registrar account	You, fully
You are the registrant but the agency owns the account	The agency can change DNS and settings; you have the legal claim but not the controls
The agency is the registrant and owns the account	The agency, both legally and practically
The agency is the registrant but you own the account	Rare and messy; fix the registrant record immediately

The account holder can change name servers, disable locks, request authorization codes, and in some cases edit contact details (which may trigger a Change of Registrant confirmation). The registrant has the legal standing. Ideally, they are the same person or organization. If they are not, fix it before you need to rely on it. Securing the account itself is covered in how to secure your domain registrar account with 2FA.

How Contacts Appear in WHOIS and RDAP

In WHOIS text output, contacts appear as prefixed blocks:

Registrant Name: REDACTED FOR PRIVACY
Registrant Organization: Smith Bakery Ltd
Registrant State/Province: ON
Registrant Country: CA
Admin Name: REDACTED FOR PRIVACY
Tech Name: REDACTED FOR PRIVACY
Tech Organization: Example Hosting Inc

In RDAP, contacts are entities with roles. A trimmed example:

{
  "entities": [
    {
      "objectClassName": "entity",
      "roles": ["registrant"],
      "vcardArray": [
        "vcard",
        [
          ["version", {}, "text", "4.0"],
          ["org", {}, "text", "Smith Bakery Ltd"],
          ["adr", {}, "text", ["", "", "", "", "ON", "", "CA"]]
        ]
      ]
    },
    {
      "objectClassName": "entity",
      "roles": ["technical"],
      "vcardArray": [
        "vcard",
        [
          ["version", {}, "text", "4.0"],
          ["org", {}, "text", "Example Hosting Inc"]
        ]
      ]
    },
    {
      "objectClassName": "entity",
      "roles": ["registrar"],
      "vcardArray": [
        "vcard",
        [
          ["version", {}, "text", "4.0"],
          ["fn", {}, "text", "Example Registrar, LLC"]
        ]
      ]
    }
  ]
}

The standard RDAP roles include registrant, administrative, technical, billing, registrar, abuse, and reseller, among others. Personal data is usually redacted, but the organization and country of the registrant are often visible, which is enough to confirm whether your company is listed. For more on reading RDAP output, see what RDAP is and how it is replacing WHOIS.

Listing Contacts by Role With a Script

This Python script prints every entity and its visible organization or name for a domain, following the registry's link to the registrar record where one exists:

import json
import sys
import urllib.request

HEADERS = {"Accept": "application/rdap+json"}


def get(url: str) -> dict:
    req = urllib.request.Request(url, headers=HEADERS)
    with urllib.request.urlopen(req, timeout=15) as resp:
        return json.load(resp)


def vcard_value(entity: dict, prop: str) -> str:
    for item in entity.get("vcardArray", [None, []])[1]:
        if item[0] == prop:
            value = item[3]
            return " ".join(value) if isinstance(value, list) else str(value)
    return ""


def walk(entities: list, depth: int = 0) -> None:
    for ent in entities:
        roles = ", ".join(ent.get("roles", []))
        label = vcard_value(ent, "org") or vcard_value(ent, "fn") or "(redacted)"
        country = vcard_value(ent, "adr").split()[-1:] or [""]
        print(f"{'  ' * depth}- [{roles}] {label} {country[0]}".rstrip())
        walk(ent.get("entities", []), depth + 1)


domain = sys.argv[1] if len(sys.argv) > 1 else "example.com"
data = get(f"https://rdap.org/domain/{domain}")

for link in data.get("links", []):
    if link.get("rel") == "related" and link.get("href", "").startswith("http"):
        try:
            data = get(link["href"])
            break
        except Exception:
            pass

print(f"Contacts for {domain}:")
walk(data.get("entities", []))

Run it with python3 contacts.py yourdomain.com. The output shows which roles exist and who holds them, at least as far as the public redacted view allows. Nested entities are shown indented, because RDAP servers often nest the registrar's abuse contact inside the registrar entity.

Remember that this is the public view. To see your full, unredacted record, log in to your registrar account and open the domain's contact settings.

Common Ownership Problems

The Web Designer Registered It

This is the most common case. A designer or agency registers the domain "to save you the hassle" and lists themselves or their company as registrant. Everything works until the relationship ends, the agency closes, or a fee dispute arises. Many agencies hand over domains willingly, but you should not have to ask.

A Former Employee Is the Registrant

An employee registered the domain years ago with their personal name and a personal email address. When they leave, the company may lose access to renewal notices and verification emails, and in a dispute the registrar will see the employee as the registrant.

A Cofounder or Partner Holds It

When a partnership breaks up, a domain registered in one partner's name can become leverage. Sort this out while relations are good.

The Registrant Email Is Dead

Even if the registrant record is correct, an email address on an old domain or an abandoned mailbox means you will miss renewal notices and verification requests. Expired domains can be lost permanently; see domain grace period and redemption period.

If any of these describe your situation and the current registrant is not cooperating, see how to recover a domain registered under someone else's name.

How to Make Sure You Really Own Your Domain

1. Look up the public record. Use ICANN Lookup, RDAP, or the script above. Confirm the registrant organization and country are yours.
2. Log in to the registrar account and view the full registrant details. If you cannot log in, you do not control the domain.
3. Set the registrant organization to your legal entity name for business domains.
4. Use a role-based email for the registrant, such as domains@ at a different domain you also control, so it survives staff changes and does not depend on the domain it protects.
5. Move the domain into an account you own if it sits in someone else's account. Depending on the registrar, this is an internal account change (often called a "push") or a transfer. See how to transfer domain ownership.
6. Give developers access, not ownership. Many registrars support delegated access or team members. List the developer as technical contact if needed.
7. Turn on locks and two-factor authentication, and enable auto-renewal.
8. Keep evidence of ownership: invoices, contracts with agencies that state who owns the domain, and trademark registrations.

Expect a Change of Registrant Process

When you change the registrant's name, organization, or email on a gTLD domain, the registrar will usually send confirmation requests to the old and new registrant emails. Historically, ICANN's Transfer Policy also applied a 60-day inter-registrar transfer lock after a change of registrant, unless the registrant opted out beforehand; newer versions of the policy relax this, and registrars implement it differently. If you are planning to move registrars soon, ask your registrar how a contact change will affect that. Background on the lock is in what the 60-day domain transfer lock is.

---

Domain Contacts FAQ

Conclusion

Of all the contacts on a domain registration, only the registrant holds the domain. The administrative, technical, and billing contacts are roles that help manage it, and under ICANN's current Registration Data Policy the admin contact is no longer even required for gTLDs. Who paid, who built the site, or who manages DNS does not change who the registrant is, and in a dispute registrars generally side with the registrant of record.

The practical lesson is simple: make sure your business is the registrant, in a registrar account your business controls, with a durable email address and strong account security. Check your records today using RDAP or your registrar dashboard, and fix anything that names an agency, a former employee, or a personal address. It takes minutes now and can save months of arguing later.

Here are some useful references for going deeper on domain contacts and ownership:

1. ICANN: Transfer Policy — the rules for inter-registrar transfers and changes of registrant.
2. ICANN: ICANN Lookup — check the registrant and contact data shown for a gTLD domain.
3. RFC 9083: JSON Responses for the Registration Data Access Protocol — defines RDAP entities and their roles.
4. RFC 7095: jCard: The JSON Format for vCard — the format used for contact data inside RDAP entities.