Quick answer: an RDAP lookup — still often called a "WHOIS lookup" — is the right starting point for finding out who's behind a domain. Public results can show the registrar, key dates, nameservers, and status codes, and sometimes registrant details, depending on the extension and applicable privacy rules. Privacy rules may redact personal data, while privacy or proxy services may publish alternative contact details; with a proxy service, the provider may appear as the registered name holder. What you get is a public record, not conclusive proof of legal ownership.
People run this lookup for different reasons: buying a domain someone else holds, reporting phishing or malware, investigating a trademark conflict, or double-checking their own registration. This guide covers how to run the lookup, what each result means, and what to do next.

The process is the same whether you're checking a domain you're thinking about buying or one you already manage.
Type the full domain, including the extension, into a registration-data lookup tool — Atak Domain's WHOIS lookup or ICANN Lookup both work. A typo returns a different domain's data or no result at all, so double-check the spelling before reading anything into the result.
The result identifies the sponsoring registrar — the company the domain is registered through — and the registry that operates the extension's authoritative database. The registrar and registry perform different roles, even where corporate relationships exist. Neither should automatically be treated as the domain's registrant or website operator.
The reported creation date indicates when the current registration record was created. It can help estimate the domain's age, but it may not reveal earlier registrations if the domain was previously deleted and registered again. Nameservers show where the domain's DNS is managed, which is a separate question from who owns it. Status codes indicate whether the domain is locked, in a grace period, or otherwise restricted.
If a registrant organization or contact is published, it will appear here. For most gTLDs today, individual registrant contact details are redacted by default under ICANN's Registration Data Policy, and you'll see a privacy service or a generic registrar contact instead of a person's name.
What you do with the result depends entirely on why you looked it up. Use the table below as a quick reference, and see the sections further down for the full detail on each situation.
| Lookup result | Next action |
|---|---|
| Domain appears available | Verify with a live registration attempt before treating it as confirmed — a lookup result is a snapshot, not a reservation |
| Registrant contact is public | Contact them directly; keep first outreach brief and professional |
| Contact is redacted | Try a privacy relay, the registrar's contact route, or a domain broker rather than assuming the domain is unreachable |
| Domain is listed for sale | Use the marketplace's own contact and offer process |
| Abuse is suspected | Report to the registrar's published abuse contact, not the registrant field |
| The record appears inaccurate | Recheck the exact spelling first; if it's still wrong, this is a registrar or registry matter, not something a lookup tool can fix |
| Domain is expired or in redemption | Don't assume it will become available on schedule — see the status-code section below before acting |

Before going further, it's worth running the lookup on the actual domain you're researching — the sections that follow will make more sense against a real result in front of you.
DOMAIN LOOKUP
Use Atak Domain's lookup tool to review available registrar information, important dates, nameservers, status codes, and public contact routes.
Public details vary by TLD, registry, registrar, jurisdiction, and applicable privacy rules.
WHOIS is the original registration-data lookup protocol. RDAP, or Registration Data Access Protocol, is its standardized successor. Since January 28, 2025, RDAP has been the definitive source for delivering gTLD registration data. Most ICANN-contracted gTLD registries and registrars are no longer required to provide WHOIS services, although limited contractual exceptions remain, including .com, .name, and .post. Country-code registries set their own lookup policies and timelines. "WHOIS lookup" nevertheless remains the familiar phrase many users and tools use for domain-registration searches, even when the tool behind it is actually querying RDAP. This guide uses both terms for that reason.
| Aspect | WHOIS | RDAP |
|---|---|---|
| Data format | Unstructured plain text | Structured, machine-readable JSON |
| Access method | Port 43 / basic web query | RESTful HTTPS |
| Standardization | No formal schema across providers | IETF-standardized (RFC 7480–7484 and related) |
| Internationalization | Limited, inconsistent character support | Built-in support for non-ASCII data |
| Access control | All-or-nothing public response | Supports differentiated access based on requester |
| Current role (gTLDs) | Legacy protocol; generally no longer required for gTLD registration-data delivery, subject to limited exceptions (.com, .name, .post) | Definitive source for gTLD registration data since January 28, 2025 |
| Typical user experience | Plain text, easy to read manually | Structured response, easier for tools to parse |
See ICANN's RDAP overview for the technical background and ICANN's Registration Data Policy for the current rules governing what gTLD registrars must collect, publish, and redact.

A registration-data record is a set of fields, and each one answers a different question. Not every field appears for every domain.
• Domain name — the exact registered string, confirming you're looking at the right record.
• Registrar — the ICANN-accredited company (or ccTLD-authorized provider) the domain is registered through.
• Registry — the organization operating the authoritative database for that extension.
• Creation date — when the domain was first registered, under its current registration chain.
• Updated date — when the record last changed — this is not the same as when the domain was first acquired, and a recent update doesn't necessarily mean a change of hands.
• Expiration or registry expiry date — when the current registration term ends. This date needs careful interpretation — see the note below — and shouldn't be used alone to predict when a name will become available.
• Nameservers — where the domain's DNS is managed, which can be entirely separate from who owns the registration.
• DNSSEC — whether the domain uses DNS Security Extensions to help prevent certain spoofing attacks.
• Domain status codes — EPP codes indicating whether the domain can currently be transferred, updated, or deleted. See the dedicated section below.
• Registrant organization or contact, when published — visible only where policy, consent, and the specific TLD allow it.
• Registrar abuse contact — the address for reporting misuse of the domain, distinct from the registrant.
• Remarks, notices, and redaction indicators — text explaining why certain fields are withheld or how to request more information.
An annotated example: here's what a typical redacted result looks like for a fictional domain, with each line explained.
Reading this: nothing here is unusual, and none of it identifies a real person — this is a fictional, illustrative record showing a routine transfer lock and a standard privacy notice.
A note on expiration dates: the listed expiry date is when the current term ends, not a guaranteed public-availability date. Auto-renewal, grace periods, and redemption processing can all extend the real timeline well past that date — see the domain expiration guide for how that process actually works.
Redacted contact data is the default outcome for most individual registrants on gTLDs today, not an exception or a red flag.
• Privacy-related redaction — under ICANN's Registration Data Policy, registrars limit public display of personal registrant data by default.
• Consent and publication rules — some registrants can opt into fuller publication; most simply don't, and nothing requires them to.
• Privacy and proxy services — a separate service's contact details appear in place of the registrant's own, with the service relaying communication.
• Registrar or registry policies — individual providers can apply additional limits beyond the policy baseline.
• ccTLD-specific rules — country-code registries set their own publication and redaction rules, which may look nothing like gTLD practice.
Redaction does not mean nobody is accountable. Every registered domain still has a registrant on record with the registrar, and legitimate abuse or legal requests are handled through defined channels — not by assuming a locked record has something to hide.
The registrar managing a domain is not necessarily its owner.
| Entity | Role | Can usually be contacted for |
|---|---|---|
| Registrant / registered name holder | The party the domain is registered to | Direct ownership questions, where contact details are available |
| Registrar | Sells and administers the registration under ICANN or ccTLD accreditation | Abuse reports, transfer questions, account-level issues |
| Registry operator | Runs the authoritative database for the entire extension | Rarely contacted directly by end users; policy and technical issues |
| Privacy/proxy service | Stands in for the registrant's public contact details | Relayed messages to the underlying registrant |
| Website operator | Runs the site the domain points to — may or may not be the registrant | Content or website-specific issues, not registration questions |
| Beneficial or legal owner | The party with an actual legal or equitable claim to the name | Not something a lookup alone can confirm |
The right contact route depends on what's actually published.
• Published email or web form — use it directly and identify yourself and your reason for contacting.
• Privacy relay — many privacy services forward messages to the underlying registrant without exposing their identity to you.
• Website contact page — often faster than registration data if the domain resolves to an active site.
• Marketplace listing — if the domain is listed for sale, the platform typically has its own contact and offer process.
• Domain broker — useful when the name has real business value and you'd rather not approach the owner directly yourself.
• Registrar contact route — some registrars offer a formal message-forwarding option when no other contact is published.
A short, workable acquisition message: "Hello — I'm reaching out about example.com. I'm interested in acquiring the domain for a project and would like to know if you'd consider an offer. Happy to discuss details if you're open to it."
Keep initial outreach polite, brief, and low-pressure — no need to state your maximum budget or a deadline in the first message.
Avoid: mass unsolicited contact, scraping registration data for marketing lists, repeated messages after no response, and pressure tactics. For a real purchase, use escrow and a documented transfer process rather than an informal handshake deal.
The right move depends entirely on your reason for looking.
Check whether the domain is listed for sale, try the registrar's relay option if one exists, or use a domain broker service to make contact on your behalf. If it's not for sale and there's no working contact route, treat that as a real "no" for now rather than escalating.
Use the registrar's published abuse contact for registration-related complaints. If harmful content is hosted elsewhere, reporting it to the hosting provider, platform, or other relevant service may also be necessary.
☐ The exact domain and full URL involved
☐ Date and time of the observed activity, with timezone
☐ Screenshots of the abusive content or behavior
☐ Relevant headers or technical indicators, where applicable (e.g., email headers for phishing)
☐ A clear, factual explanation of the harm caused
☐ Your own contact details, so the registrar can follow up
☐ Any supporting rights or authority, if relevant (e.g., trademark registration for impersonation cases)
This is a case for a lawyer, not a workaround. Formal legal processes — including UDRP for cybersquatting disputes — have their own evidence and procedural requirements that a registration-data lookup alone doesn't satisfy.
ICANN's Registration Data Request Service (RDRS) standardizes how these requests are submitted for participating gTLD registrars. It's a pilot-turned-interim service — it launched in November 2023, completed a two-year pilot in November 2025, and ICANN's Board has extended it to keep running while a longer-term policy is finalized. It does not cover every TLD, and submitting a request does not guarantee disclosure — each one is evaluated under applicable law, policy, and evidence.
If something's wrong with your own registration — status codes you didn't set, unexpected nameserver changes, an update you can't make — contact your registrar's support directly rather than relying on the public lookup alone.
• Trademark ownership — a registered domain doesn't establish or override trademark rights.
• Beneficial ownership — the listed registrant may not be the party who actually controls or benefits from the domain.
• Website control — DNS, hosting, and registration are separate layers; registration data doesn't confirm who runs the live site.
• First use of a mark — commercial or trademark priority is a separate legal question with its own evidence standards.
• Legal entitlement to use the name — being the registrant doesn't automatically clear every use of the name in every context.
• Historical ownership — current records don't reliably reconstruct who held the domain in the past.
• Guaranteed availability after expiry — see the note above on why the listed expiration date isn't a release date.
Registration data is a starting point, not final proof of ownership.
These are EPP (Extensible Provisioning Protocol) status codes — standardized labels that appear in registration-data results. The full official reference is ICANN's EPP status codes page; a code being present is routine, not automatically a sign of fraud or a dispute.
| Status code | Plain-English meaning | Who typically applies it | What to do next |
|---|---|---|---|
| clientTransferProhibited | The registrar has blocked outgoing transfers | The registrar, often at the registrant's request or by default | Log in to the registrar account and remove it before attempting a transfer |
| clientUpdateProhibited | The registrar has blocked changes to the record | The registrar, similarly to the transfer lock | Check the registrar account for an unlock option or contact the registrar — availability and removal requirements vary by provider and circumstance |
| serverTransferProhibited | The registry has blocked transfers at its level | The registry operator, often for policy or dispute reasons | Contact the registrar, since this can't be changed by the registrant directly |
| pendingTransfer | A transfer request is currently in progress | Set automatically during an active transfer | Wait for the transfer window to complete or contact the losing registrar with questions |
| redemptionPeriod | The registrar has requested deletion and the registry is holding the domain in a limited recovery period. This often follows expiration, but the status itself reflects a registry-level deletion and recovery process. | Set automatically once the registry receives a delete request, most commonly after expiration and an initial grace period | Contact the registrar immediately if you want to restore the domain — this window is time-limited and often carries a restoration fee |
| pendingDelete | The domain is in its final pre-release phase | Set automatically at the end of the redemption period | If this appears without redemptionPeriod or pendingRestore, restoration is generally no longer possible and the domain is scheduled for deletion; confirm the full status combination with the registrar |
• Assuming the registrar is the owner — it's the service provider, not the registrant.
• Treating redacted data as suspicious — it's the default outcome for most individual registrants today, not a red flag on its own.
• Confusing the website host with the registrar — hosting and domain registration are separate services, even when the same company provides both.
• Reading the updated date as the original acquisition date — an update can be routine and unrelated to a change of ownership.
• Assuming an expiration date means immediate public availability — grace periods and redemption windows usually extend the real timeline.
• Contacting the wrong organization for abuse — the registrar's abuse contact handles this, not the redacted registrant field.
• Using bulk lookup data for unsolicited marketing — this is a misuse of registration data and a fast way to trigger abuse complaints against you.
• Treating a lookup printout as legal proof — courts and dispute processes require more than a registration-data screenshot.
☐ Confirmed the exact domain spelling before running the lookup
☐ Identified the registrar and registry separately from any registrant field
☐ Reviewed creation, updated, and expiration dates without assuming the expiration date is a release date
☐ Checked current status codes and what they actually restrict
☐ Noted whether contact details are public, redacted, or handled by a privacy service
☐ Matched the situation to the right next action — buying, reporting abuse, legal research, or your own troubleshooting
☐ Used the registrar abuse contact for abuse reports, not a private message to a redacted field
☐ Avoided treating the record as legal proof of ownership
☐ For an acquisition, kept first contact brief and did not disclose a maximum budget
☐ For a real purchase, planned to use escrow and a documented transfer process
No. Whether registrant details are visible depends on the extension, the applicable privacy policy, and whether the registrant uses a privacy or proxy service. For most individual registrants on gTLDs today, personal contact data is redacted by default, and you'll see a registrar or privacy-service contact instead.
ICANN Lookup and many registrar lookup tools provide free public registration-data searches without requiring an account. Bulk, historical, or specialized data services may use different access terms. Formal disclosure requests for nonpublic data, such as through RDRS, are also free to submit but aren't guaranteed to result in disclosure.
Only in limited form for gTLDs — since January 28, 2025, RDAP is the definitive source, with narrow exceptions (.com, .name, .post). Many ccTLDs still run their own WHOIS services independently. "WHOIS lookup" remains the everyday term either way — see the comparison above for the full detail.
They can pull from different underlying sources, reflect different update timing, or apply different display and redaction rules — this is more likely for ccTLDs still running independent WHOIS services alongside gTLD RDAP data. If the two disagree, treat the RDAP result as more current for gTLDs.
Often, yes — check whether it's listed for sale, use an available contact route, or work through a domain broker. Finding the registrant doesn't obligate them to sell, and a redacted or unresponsive record doesn't mean the domain is unavailable forever.
Not automatically. A registrar evaluates disclosure requests — including legal demands, abuse reports, and RDRS submissions — against applicable law, policy, and the specific evidence provided. No single request type guarantees that protected data will be released.
Current registration-data lookups generally don't reconstruct historical ownership. Some third-party historical WHOIS archives exist, but their coverage and accuracy vary, and none of them substitute for a verified legal record.
No — see the note on expiration dates earlier in this guide. The listed date ends the current term, not availability; grace and redemption periods usually follow first.
Yes. You do not need to know the registrant's identity to submit an abuse report. Use the registrar's published abuse contact and, where relevant, also notify the hosting provider or platform controlling the harmful content.
No — see "What a WHOIS or RDAP Record Does Not Prove" above. It's a public registration record, not a legal title.
Check the current registration record first. Atak Domain, an ICANN-accredited registrar, provides a lookup tool for exactly this — from there, register the name if it's genuinely available, use an approved contact route if it's registered and you want to reach the owner, or submit a documented abuse report when that's what the situation calls for.
NEXT STEP
Check the current registration record, then register the name if it is available, use an approved contact route if it is registered, or submit a documented abuse report when necessary.
Search Available Domains · View Domain Prices · Domain Broker Service