RDAP vs WHOIS: Verify Domain Ownership in 2026

For generic top-level domains such as .com, .net, and .org, RDAP became the definitive registration-data source on 28 January 2025. Use ICANN Lookup or an RDAP client to verify the registrar, IANA ID, registration dates, EPP statuses, nameservers, DNSSEC state, and abuse contacts. Do not treat the result as standalone proof of legal ownership. Public registrant information may be redacted, so ownership verification normally requires access to the registrar account, supporting registration records, or a DNS TXT challenge.

Written by the ServerSpan Technical Team

RDAP replaced contractual WHOIS service for generic domains

ICANN designated the Registration Data Access Protocol as the definitive source for generic top-level domain registration information from 28 January 2025. ICANN-accredited registrars and gTLD registries had already provided RDAP services since 2019, but the 2025 date completed the contractual sunset of their traditional WHOIS obligations.

The scope matters. The transition applies to generic top-level domains governed by ICANN agreements. Country-code registries such as those responsible for national extensions establish their own registration-data policies. A ccTLD may offer RDAP, continue to provide WHOIS, operate both, or use a registry-specific lookup interface.

Legacy WHOIS tools may still return data for some extensions in 2026. That does not make WHOIS the preferred source for gTLD registration checks. Use the RDAP response or ICANN’s RDAP-based Lookup service first.

If you are registering a new name rather than investigating an existing record, ServerSpan provides domain registration and transfer services. The registration account remains the place where ownership, renewal, contact, and transfer settings are administered.

RDAP produces structured data instead of unlabelled text

WHOIS is a TCP query protocol that normally listens on port 43 and returns human-readable text. Different servers historically used different labels, layouts, encodings, and referral behaviour. Scripts often had to parse each registry or registrar format separately.

RDAP uses HTTP and returns structured JSON. Clients can identify fields by their defined JSON members instead of guessing from lines such as Registrar:, Updated Date:, or Name Server:. RDAP also supports secure HTTPS transport, internationalized data, service discovery, authentication, and differentiated access.

Feature	WHOIS	RDAP
Transport	TCP port 43	HTTP or HTTPS
Response format	Free-form text	Structured JSON
Authoritative service discovery	Often depended on hard-coded servers or referrals	Uses IANA bootstrap registries
Internationalization	No dependable character-set mechanism	Designed to support internationalized data
Access control	No protocol-level mechanism	Can support authenticated and differentiated access
Automation	Requires text parsing	Stable JSON members are easier to process
Current gTLD role	Legacy and optional after the sunset	Definitive registration-data source

ICANN Lookup is the simplest way to inspect a domain

For a manual investigation, start with ICANN Lookup. Enter the complete domain name without a protocol, path, or email address. Use example.com, not https://example.com/contact.

A normal public gTLD result can contain:

• The normalized domain name and registry identifier.
• The sponsoring registrar and its IANA identifier.
• Registrar abuse email and phone details.
• Creation, expiration, update, and RDAP-database event dates.
• Current EPP domain statuses.
• Authoritative nameservers.
• DNSSEC delegation information.
• Links to the registry and registrar RDAP sources.
• Redaction notices and contact-relay information.

The sponsoring registrar is the company responsible for the registration record. It may be different from the DNS provider, website host, email provider, reseller, or company shown in the nameservers.

Nameservers identify the service responsible for authoritative DNS. They do not prove which registrar manages the domain. A domain registered through one company can use DNS hosted by another and web hosting from a third.

The ICANN command-line client is better for repeatable checks

ICANN maintains an open-source RDAP command-line client. After installing it according to the project instructions, run a basic domain lookup:

rdap example.com

A successful query should show the domain object, registrar, events, statuses, nameservers, notices, and relevant links. An error stating that no bootstrap service exists may indicate an unsupported extension, an outdated local bootstrap cache, or a TLD without a published RDAP endpoint.

To display only the registrar section:

rdap -p registrar example.com

This is useful when you need the sponsoring registrar, IANA ID, or registrar contact without reviewing the full response.

For structured output that can be saved or passed into another tool:

rdap -O pretty-json example.com

Do not disable certificate checks to make a failed query work. An invalid TLS certificate, mismatched hostname, or unexpected HTTP endpoint requires investigation. The authoritative registration-data path should use a valid secure connection.

IANA bootstrapping locates the authoritative RDAP server

An RDAP client does not need a manually maintained list of registry servers. It retrieves an IANA bootstrap registry, matches the domain extension, and obtains the base URL for the authoritative service.

You can inspect the current endpoint for a TLD with curl and jq:

curl -fsS https://data.iana.org/rdap/dns.json | \
  jq -r '.services[] | select(.[0] | index("com")) | .[1][]'

The result should contain one or more HTTPS base URLs serving the selected extension. No output means the extension was not matched in the current bootstrap file or the filter used the wrong TLD label.

RDAP domain queries append domain/<fully-qualified-domain> to the base URL. For a base ending in a slash, the resulting pattern is:

https://authoritative-rdap.example/rdap/domain/example.com

Prefer a bootstrapping client for production automation. Hard-coding one endpoint for every extension will eventually fail because different registries operate different RDAP services.

Registrar and status fields reveal the operational state

The registrar entity identifies where the domain registration is managed. Confirm both the displayed registrar name and the IANA registrar ID. Similar company names, resellers, and acquired brands can make the text label alone ambiguous.

Domain statuses describe restrictions and lifecycle conditions. Use ICANN’s EPP status-code reference rather than guessing from the name.

RDAP status	Practical meaning	What to do
clientTransferProhibited	The registrar has instructed the registry to reject transfers	Leave it enabled for protection or remove it through the registrar before an authorized transfer
clientUpdateProhibited	Updates to the registration are restricted	Check the registrar account and confirm why the lock exists
serverTransferProhibited	The registry is blocking transfers	Contact the registrar because registry involvement may be required
clientHold or serverHold	The domain is not active in DNS	Check payment, validation, abuse, legal, or delegation issues with the registrar
redemptionPeriod	The registrar requested deletion and the recovery window is running	Contact the registrar immediately and request restoration
pendingDelete	The registry is preparing to purge the domain	Recovery may no longer be possible; contact the registrar immediately

An expiration date alone does not tell you whether the domain is available. Auto-renew grace periods, redemption, registry policies, and registrar processing can keep the registration unavailable after the displayed date.

The ServerSpan article You Don’t Own Your Domain. You Rent It From a Clock That Never Stops explains the renewal and deletion lifecycle in more detail.

RDAP data is not standalone proof of domain ownership

RDAP verifies the public registration record. It does not automatically prove that the person showing you the result owns the domain, controls the registrar account, or has the legal authority to sell or transfer it.

Public registrant fields may be redacted for privacy or legal reasons. A privacy or proxy service may also appear instead of the underlying customer. Even when a company name is published, the RDAP response does not prove that the person negotiating with you is authorized to act for that company.

What you need to verify	Useful evidence	What RDAP contributes
The current sponsoring registrar	Authoritative RDAP registrar entity and IANA ID	Strong public evidence
Current DNS control	A unique DNS TXT token published under the domain	Nameserver data helps identify where DNS is hosted
Registrar-account control	Live screen share or controlled action inside the registrar account	Identifies which registrar account must be accessed
Registration purchase and renewal history	Invoices, order confirmations, renewal receipts, and account records	Provides dates that can be compared with the documents
Legal ownership or authority to sell	Contracts, company records, assignment documents, and legal review	May identify a published registrant organization, when available
Ability to transfer the domain	Registrar unlock, transfer eligibility, and authorization code held securely	Shows transfer-related EPP statuses

A DNS TXT challenge is the safest simple proof of current technical control. Generate a random value and ask the claimant to publish it under a dedicated hostname:

_ownership-check.example.com. 300 IN TXT "verify-2026-random-token"

Verify it from an independent resolver:

dig TXT _ownership-check.example.com +short

The expected output is the exact token. This proves current DNS control, not legal ownership and not necessarily registrar-account access. A hosting provider, DNS administrator, former employee, or managed-service company may be able to edit DNS without owning the registration.

For a transfer, verify registrar-account control separately. Keep the authorization code private and submit it only through the receiving registrar’s secured transfer process. The ServerSpan guide to transferring a domain without downtime covers locking, DNS continuity, email protection, and cutover planning.

Redacted data requires a registrar disclosure process

A missing registrant name or email does not mean the domain has no owner. ICANN policy permits or requires personal information to be redacted in public registration-data responses under defined conditions.

The registrar may publish an anonymized email address or a web form that forwards a message without revealing the underlying contact. Use that mechanism for ordinary contact attempts.

When nonpublic information is required for a legitimate legal, cybersecurity, consumer-protection, or intellectual-property purpose, first confirm that the data is not available through ICANN Lookup. You can then use the Registration Data Request Service for participating registrars or contact the sponsoring registrar directly.

A disclosure request is not guaranteed to succeed. The registrar evaluates the request, applicable law, stated purpose, supporting evidence, and the rights of the data subject.

Registration, DNS, hosting, and website control are separate

A correct ownership investigation separates four systems:

• Registrar: manages the registration, renewal, registrant data, locks, and transfer authorization.
• Registry: operates the authoritative database for the top-level domain.
• DNS provider: hosts the authoritative DNS zone and records.
• Hosting provider: runs the website, application, or email service reached through DNS.

Control of one system does not prove control of the others. A web developer may control the server while the client controls the registrar. A managed DNS provider may edit records without access to the domain transfer settings. A registrar may provide DNS services, but the roles remain technically separate.

Use dig when you need to inspect DNS rather than registration data:

dig NS example.com +short
dig A example.com +short
dig MX example.com +short
dig DS example.com +short

These commands show nameserver delegation, website addresses, mail routing, and DNSSEC delegation. They do not identify the registrar. The ServerSpan guide What Is a DNS Record? explains how these records affect services without changing registration ownership.

Common WHOIS-era checks now produce incomplete conclusions

The most common mistake is opening an old WHOIS website, seeing a blank registrant field, and concluding that the domain record is broken. The public data may simply be redacted, and the website may be showing cached or registry-only information.

• Do not identify the registrar from nameservers.
• Do not treat the public registrant field as the only ownership evidence.
• Do not assume an expired date means the domain is available.
• Do not accept a screenshot as proof of current account control.
• Do not expose a transfer authorization code during preliminary verification.
• Do not hard-code one RDAP endpoint for every TLD.
• Do not disable TLS validation to work around a failed lookup.

For a routine audit, use ICANN Lookup, record the registrar and IANA ID, inspect the status codes, compare nameservers, and verify control with a temporary DNS TXT token. For a purchase or legal transfer, add registrar-account verification, payment records, assignment documentation, and professional legal review where the domain has meaningful value.

If you need to register a new domain or move an existing registration under one account, ServerSpan’s domain registration service provides the commercial handoff after the technical and ownership checks are complete.

The practical rule is simple. Use RDAP to verify the authoritative public registration record. Use the registrar account to verify administrative control. Use DNS challenges to verify current technical control. Use contracts and account records when legal ownership matters.