A public domain lookup is no longer an internet phone book. For a typical generic top-level domain, it can still identify the registrar, registration dates, status codes, nameservers, and a way to contact the registrant without exposing the underlying address. It usually will not publish a person's name, street address, direct email address, or phone number. That missing data is often described as WHOIS privacy, but the label hides several different arrangements. Redaction under registration-data policy is not the same as buying a privacy service, and neither is the same as using a proxy that becomes the registrant of record.
The distinction matters in an investigation and in ordinary portfolio management. A redacted field says that a value is withheld from the public response. A privacy service can leave the customer as the registered holder while publishing alternative contact details. A proxy service places the provider in the registration record and licenses use of the domain to its customer. None of these arrangements proves that a domain is safe, malicious, anonymous, or controlled by the person named on a website. Registration data is one evidence source with a defined scope.
The current gTLD policy
ICANN's Registration Data Policy took effect on 21 August 2025 for ICANN-accredited registrars and gTLD registry operators. It replaced the Interim Registration Data Policy that had carried forward the post-2018 temporary framework. Describing the Temporary Specification as the current rule is now wrong. The policy sets requirements for collection, transfer, public publication, disclosure requests, logs, and retention. It also allows contracted parties to account for applicable data-protection law rather than pretending one publication rule fits every registrant and jurisdiction.
ICANN revised the policy on 12 May 2026 to add language about urgent lawful-disclosure requests. ICANN also stated that the new 24-hour urgent-response requirement will not take effect until a law-enforcement authentication mechanism is implemented. The covered situations are narrow, such as an imminent threat to life, serious bodily injury, critical infrastructure, or child exploitation where disclosure is necessary to address the threat. A routine trademark, fraud, or security investigation should not be relabelled urgent merely to obtain a faster answer.
Public and nonpublic registration data
The public response normally contains operational registration data: the domain name, registrar information, registry creation date, expiration and update events where supplied, domain status, nameservers, and DNSSEC information. The exact response varies with the registry, registrar, top-level domain, and whether a value exists. A registrar that redacts personal data must still provide a non-identifying email address or web form that can forward communication to the relevant contact under the policy's conditions. A relay address is a contact path, not the registrant's real mailbox.
The remaining fields need careful interpretation. The creation date refers to creation of the domain object in the registry database, not necessarily the date the current customer acquired it. An updated event can reflect a change to any covered registration element and does not prove a transfer. An expiration event does not show whether the customer's billing arrangement will renew the domain. Nameservers identify delegated DNS infrastructure, which is often shared by millions of unrelated customers. Status codes describe registry or registrar state. They do not establish ownership, intent, or organizational relationships on their own.
Publication of the registrant organization
The Registrant Organization field now has an explicit consent path. If the registered name holder agrees to publication of that value, the registrar must publish it. If the holder does not agree, the registrar may redact it. For older registrations that already contained an organization value, the implementation rules required registrars to ask the holder to review the value and choose whether it should be published. A missing organization can therefore reflect a publication choice, deletion of an older value, or the absence of a collected value. It is not evidence that the registrant is an individual.
A published organization value is still a registration field, not proof that the organization owns the website, wrote its content, or controls every service under the domain. Registrants are responsible for accurate data under their agreements, but investigators should verify an organization through primary corporate records and direct control tests when the conclusion matters. Businesses deciding whether to consent should use an accurate legal organization value and understand that publication makes it broadly accessible. They should not place an employee's personal details in the organization field as a shortcut.
Redaction, privacy services, and proxy services
Redaction is an output rule. The registrar may still collect and hold nonpublic registration data while the public RDAP response marks selected values as redacted. The policy also requires an opportunity for a registered name holder to consent to publication of certain values where the registrar applies those redaction rules. Redaction does not mean the registrar never collected the data, that the value has been erased, or that a requester with a legitimate purpose will receive it. Collection, public publication, retention, and lawful disclosure are separate processing questions.
ICANN defines a privacy service as an arrangement in which the customer remains the registered domain-name holder, while the service publishes alternative, reliable contact information instead of the customer's personal contact details. A proxy service is legally different. The proxy provider is the registrant of record and licenses use of the domain to the customer. That distinction affects contractual rights and recovery, so a customer should read the service agreement, termination rules, forwarding process, and account-recovery terms rather than treating proxy as a cosmetic switch.
The 2013 Registrar Accreditation Agreement places specific requirements on privacy and proxy services affiliated with accredited registrars. They must publish service terms, business and abuse contacts, and procedures covering matters such as communication, abuse reports, termination, and conditions for publication of registration data. This is not a universal rule that every proxy must reveal its customer whenever a third party asks. Provider terms, the applicable ICANN requirements, due process, and relevant law govern the response. ICANN is still implementing a broader privacy and proxy accreditation program, so articles should not write as if that future program is already fully operative.
Disclosure requests and RDRS
The Registration Data Policy requires each covered registrar and registry operator to publish a process for reasonable requests for lawful disclosure. A properly formed request identifies the requester, lists the data elements sought, explains the legal rights and specific basis for the request, affirms good faith, and agrees to process any disclosed data lawfully. The contracted party must assess the request on its merits. It may provide all or part of the data, or deny the request with a reasoned explanation. A legitimate interest starts the balancing exercise; it does not guarantee disclosure.
For requests that meet the published format, the current policy requires acknowledgement without undue delay and no later than two business days. A response is due without undue delay and no later than 30 calendar days after acknowledgement, absent exceptional circumstances. A response can still be a denial. Repetitive, incomplete, or abusive requests can lead to corrective measures. Requesters should ask only for the data needed for the stated purpose and preserve the registrar's instructions, submitted materials, and decision. This is a disclosure workflow, not a search endpoint.
The Registration Data Request Service gives requesters a centralized, standardized route to participating registrars for nonpublic gTLD data. It can carry supporting documents, templates, and request tracking. It does not cover country-code domains, compel a nonparticipating registrar to join, decide whether the requester should receive data, or turn nonpublic registration data into a central ICANN database. ICANN continued RDRS beyond the pilot that ended in November 2025 while longer-term policy work continues. SSAD remains policy work, not a production replacement that users should plan around today.
Country-code domains follow different rules
The ICANN Registration Data Policy applies to ICANN-accredited registrars and contracted gTLD registry operators. Country-code top-level domains are run under their own registry policies and national frameworks. One ccTLD may publish organization data, another may distinguish individuals from businesses, and another may offer a local disclosure or dispute process. RDRS does not accept ccTLD requests. Check the registry's current policy for the exact domain instead of transferring a `.com` assumption to `.uk`, `.ca`, `.us`, `.ai`, or any other country-code space.
RDAP is now the definitive gTLD source
On 28 January 2025, RDAP became the definitive service for gTLD registration data as the relevant contractual obligations to provide port 43 and web WHOIS ended. The traditional WHOIS protocol in RFC 3912 returns unstructured text and has no standard access-control model. RDAP uses HTTP, structured JSON, standard query forms, and bootstrap discovery defined across RFC 7480, RFC 7482, RFC 7483, and RFC 9224.
People still say WHOIS lookup because the term is familiar, but the underlying response may be RDAP. RDAP can support differentiated access and notices, yet a public RDAP query does not authenticate the requester or unlock nonpublic fields by itself. The server decides what to return under its policy and access context. Structured output improves parsing and provenance; it does not make every field complete or comparable across all registries. Keep the source URL, notices, events, entity roles, and query time when using a response as evidence.
Certificates do not undo registration privacy
Publicly trusted TLS certificates answer a different question. A domain-validated certificate shows that the certification authority completed an approved domain-control validation method. It does not identify the domain registrant or the operator's legal entity. An organization-validated certificate can contain verified subject identity information, and an EV certificate must contain the subject's verified legal organization name under the CA/Browser Forum guidelines. The CA can verify identity using approved corporate and reliable data sources. Public WHOIS publication is not a prerequisite, and redacted registration data does not by itself block OV or EV issuance.
Certificate Transparency records certificates and precertificates, including the exact subject and domain fields that are present. Many ordinary domain-validated certificates contain domain names but no organization identity. An EV certificate contains organization information, but that identifies the validated certificate subject at issuance, not necessarily the current registrant, hosting provider, site author, or operator of every covered hostname. CT is useful for discovering names and reviewing issuance. It should not be described as a permanent registry of domain ownership or as a guaranteed route around registration-data redaction.
Investigating a redacted domain
Begin with the question the investigation needs to answer. Registration age, current registrar, status, nameservers, DNS, certificates, redirects, mail configuration, and public website statements can describe a domain's history and technical environment. They rarely identify a person by themselves. Shared nameservers and hosting addresses connect unrelated customers. An SPF include shows an authorized mail service, not which company controls the domain. A privacy policy or copyright notice is a self-published claim until another source confirms it. Label each connection as observed, inferred, or verified.
For fraud, phishing, malware, or abuse, preserve the specific page, URL, message headers, certificate, DNS response, and collection time before reporting it. Contact the provider responsible for the observed service and use the registrar's published abuse or disclosure path where appropriate. Do not publish a suspected identity based on a shared IP, analytics identifier, or historical organization field without independent confirmation. Registration data can support a chronology and route a request. It does not replace legal process or prove who committed an act.
What DomScan returns
- WHOIS Lookup returns structured WHOIS or RDAP registration data for a domain, including registrar, dates, nameservers, and status when the source supplies them.
- RDAP Lookup returns the raw RDAP response for a domain, IP address, or autonomous system number. Domain is the default query type; IP and autnum queries require the matching type.
- Domain Profile normalizes RDAP registration data into registrar, date, nameserver, DNSSEC, and related registration fields. It is not a combined hosting, web-content, or ownership report.
- WHOIS History returns normalized observations recorded by DomScan from qualifying fresh, successful, RDAP-backed single-domain WHOIS lookups. At most one snapshot per domain per UTC day is recorded.
- Domain Monitor tracks portfolio availability, expiry, and registration-status changes. It does not monitor every registration-data field, DNS record, or certificate change.
WHOIS History has deliberate limits. Cached responses, bulk lookups, history reads, and traditional WHOIS-only fallbacks do not create snapshots. The endpoint can show changes in normalized registrar name, expiry value, nameservers, status, DNSSEC, transfer lock, and privacy or redaction detection inside the returned window. It is not a global historical WHOIS archive, does not retrieve pre-DomScan records, and never provides registrant name, email, phone, address, or contact-identity history. A change does not prove a sale or transfer, and a missing observation does not prove a field stayed unchanged.
Choosing a registration-data privacy arrangement
Individuals generally have little reason to publish a home address, personal phone number, or direct mailbox in a public registration directory. Use accurate information in the registrar account, review what the registry publishes, and keep the forwarding address working. A business can decide whether publication of an accurate registrant organization helps its administrative process, but customer trust should rest on the website's legal disclosures, verified support channels, contracts, and consistent security controls rather than a public registration field.
Before using a proxy service, read who becomes the registrant of record, how communication is forwarded, which conduct can end the service, how the domain is transferred back, and which law and dispute terms govern the agreement. A proxy reduces public exposure; it does not make the customer unknown to the registrar or provider, prevent lawful disclosure, defeat a domain dispute, or erase payment and access records. For sensitive work, build a threat model that includes account security, hosting, logs, content, communications, and personal safety. WHOIS privacy is only one control in that model.
A practical reading checklist
- Identify whether the domain is a gTLD or ccTLD before applying an ICANN policy assumption.
- Use RDAP as the definitive gTLD source and retain the server notices and query time.
- Separate a redacted value from a privacy-service contact and from a proxy listed as registrant.
- Treat registrar, event, status, nameserver, and DNSSEC fields as technical observations with limited meaning.
- Do not treat an organization field, certificate subject, nameserver, IP address, or web-page claim as ownership proof.
- Use the registrar's disclosure process or RDRS only when the request has a lawful, specific, documented basis.
- Describe DomScan history as a limited observation log and never as contact-identity history.
When a report depends on registration data, state exactly what the source returned and what was withheld. Name the policy scope, distinguish public facts from inference, and record the collection time. If nonpublic data is necessary, use the published request process and expect the holder to balance the request against applicable rights and law. This article explains current technical and policy structure; it is not legal advice and no lookup result proves domain ownership or liability.