Domain Registrar WHOIS Privacy Comparison

Registrar privacy is a chain of collection, publication, disclosure, and control

A WHOIS privacy label alone does not answer what a domain path collects, what registration data it publishes or redacts, who can receive a disclosure, or which transfer controls apply.

This comparison keeps those questions separate. Its frozen roster contains four registrar paths and one custom-domain mail path that depends on an external registrar. The final row remains in the matrix because it represents a real way a reader may use an alias domain, but registrar-only fields stay documented as not applicable instead of being borrowed from whichever registrar supplies the domain. That boundary prevents a mail service from being presented as a registrar and prevents one provider's controls from being assigned to another.

The table follows the path from account entry to domain control. Signup identifiers, payment identifiers, and later verification triggers describe different collection moments. Operating entity, retention, and deletion describe a different layer: who publishes the relevant terms and what those documents say about defined records. WHOIS redaction, a privacy or proxy identity, and RDAP treatment describe related but non-equivalent registration-data mechanisms. Transfer locks describe control mechanics, while source availability, assessment records, and request reporting describe three distinct forms of accountability evidence.

Every displayed value comes from a current persisted cell for the named row and attribute. Product, plan, region, platform, claim type, source class, source URL, capture date, and observation version remain attached to that cell. A typed unknown therefore reports the evidence state for one field; it is not filled from another field and is not converted into a favorable or unfavorable product conclusion.

The privacy-tool comparison methodology explains the evidence labels, correction path, and alphabetical-by-operating-entity display order used here. The related email-alias comparison covers the address layer that may sit above an alias domain. Neither page turns masking or redaction into a claim that every underlying actor stops collecting identity information.

What each path collects at signup, purchase, and later verification

Signup identifiers, payment identifiers, and later verification triggers are three separate comparison fields because they describe different actors, workflows, and moments of collection.

The signup field reports only the identifiers and collecting actors tied by the captured source to account creation or initial use. The payment field separately reports the trigger, identifier type, requiredness, collecting actor, retained-by field, plan, region, and exceptions documented for a purchase or related review. The later-verification field reports a later event and the additional identifier requested when the source establishes both. A statement in one column never supplies a missing value in another.

This separation matters because a path can have more than one actor. The visible brand, legal operating entity, payment participant, registrar, registry, and mail provider are not assumed to be interchangeable. The matrix preserves the actor named by each cell. When a source does not identify the actor, plan, region, or platform, the missing element remains typed as unknown rather than being inferred from the surrounding product description.

The row for the custom-domain mail path keeps its own account and plan requirements in these columns. It does not inherit the signup or payment requirements of an external registrar. Conversely, the registrar rows do not inherit requirements from the mail path. The table records only what the exact current cell establishes for its own product tuple.

These columns document published evidence, not a walkthrough of account creation. No account was created, no payment was made, and no later-verification event was triggered for this page. A requirement described in a captured document remains a vendor-stated claim at the scope printed with the cell; it is not upgraded into an independently observed result.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Who operates the path and what its documents say about retention and deletion

Operating jurisdiction, retention, and deletion are separate fields, so an account-deletion statement does not establish that every registration, billing, legal, registry, or mail record is erased.

The operating-entity column identifies the legal name and the jurisdictional details supported by the current cell. Incorporation, governing law, hosting location, customer location, registry location, and top-level-domain policy are not treated as synonyms. If the source establishes one and not another, the table prints the supported field and preserves the other as unknown.

Retention is reported at the grain the cell supplies: data category, controller, trigger, stated duration, and exception. A duration tied to one category is not generalized to every record associated with the path. An exception stays connected to the rule it qualifies. When a document uses a relative or non-numeric period, the table preserves that wording instead of estimating a date or converting it into a universal schedule.

Deletion is also narrower than erasure of an entire domain history. The deletion column reports the initiation path, completed-erasure statement, exceptions, timeframe, and controller that the cell supports. A documented way to close an account does not answer whether a registry, billing provider, legal archive, mail system, or other actor retains a separate record. The matrix does not combine those actors unless the captured source does so.

A missing retention period or completion statement remains an evidence gap or verified absence under the stored marker. It is never rendered as immediate deletion, zero retention, or proof that a record does not exist. The result is a scoped reading of published terms rather than a promise about all data connected to a domain path.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

What WHOIS redaction, a privacy proxy, and RDAP each mean in the captured documents

WHOIS redaction, privacy or proxy identity, and RDAP treatment are different documented fields, and a value in one column does not determine either of the others.

The WHOIS-redaction column records the default treatment, protected fields, eligibility, top-level-domain scope, plan, included cost, and exceptions supported by the exact cell. It does not mean the registrar failed to collect the underlying registrant data. It also does not state what a registry, payment actor, dispute process, lawful request, or other access channel can obtain.

The privacy-proxy column records the service name, provider legal name, documented role, contact or forwarding fields, eligibility, top-level-domain scope, and terms locator supported by the captured evidence. Redacted output and substituted proxy data are not merged into one label. If the document does not establish a proxy actor or field, the comparison leaves that element unknown.

The RDAP column remains separate because it records whether RDAP is documented, displayed fields, redacted fields, eligibility, top-level-domain scope, the stated WHOIS distinction, and the documentation locator. The page does not assume that an RDAP response duplicates a WHOIS display. It reports the statement stored for each path and leaves an unsupported relationship between the two systems unresolved.

Registrar-only fields for the custom-domain mail path remain documented as not applicable because that path uses a separately obtained domain and an external registrar. The not-applicable label is a boundary, not a missing-research shortcut and not a claim about whichever registrar the reader may choose. Across all rows, a verified absence means the declared documents did not disclose the field under the capture method; it does not prove that no feature, artifact, disclosure route, or capability exists.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Transfer locks are control mechanisms, not privacy verdicts

A transfer lock describes a documented control state and its activation or removal path; it does not establish how much identity data a provider collects or exposes.

The transfer-lock field keeps the documented mechanism, default state, activation path, removal path, duration, top-level-domain scope, plan, and transfer restrictions together. Those elements answer how the captured document describes a control around domain movement. They are not combined with WHOIS, RDAP, proxy, retention, or reporting fields to produce an overall quality judgment.

A lock can be described at more than one scope or stage, so the cell's qualifiers remain load-bearing. A statement about a default does not establish every later state. A removal path does not establish that removal is immediate, costless, available for every domain, or free of another restriction unless the same cell supplies those details. An unspecified duration or exception remains unknown rather than being filled from a general transfer rule.

The custom-domain mail path keeps a documented not-applicable value here because the external registrar, not the mail path, supplies the domain-transfer controls. The comparison does not select an external registrar for that row or import a lock from another row. That keeps the table useful for comparing complete paths without assigning registrar capabilities to a service that does not provide them.

This column is therefore read independently. It can help identify the control mechanics described for a path, but it does not answer whether a path minimizes collection, prevents lawful disclosure, changes registry obligations, or reduces account linkage. Those questions remain in their own sourced columns.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Source availability, audit records, and request reporting answer different accountability questions

Public source artifacts, assessment records, and lawful-request reporting are three distinct evidence types, and none is an overall trust badge for a domain path.

Source availability records the component, repository or artifact locator, version or release locator, and license that the current cell establishes. A public repository for one component does not establish that every service component, registrar workflow, policy system, or infrastructure layer is public. The matrix preserves the named component and scope instead of broadening it into a product-wide claim.

The assessment-record column reports the assessment date, assessor, scope, access, and report locator stated in the captured evidence. A vendor-published assessment reference remains vendor-stated unless the cell carries a different admitted claim type. Its presence does not convert every product statement into an independently tested result, and its absence does not prove that no assessment exists.

Request reporting records the published period, jurisdiction, unit, scope, and counts only when the cell supplies them. Requests, orders, accounts, identifiers, disclosures, and challenged matters are not assumed to be interchangeable units. A process statement is not a count, and a count does not fully describe a process. When a report is not disclosed under the declared document search, the comparison preserves that verified absence instead of printing zero.

The two verified absences in these evidence fields retain their exact typed labels and explanations. They describe what the declared primary documents did not disclose under the capture method. They do not establish a closed source base, the nonexistence of an assessment, or the absence of lawful requests. The private phone-number comparison applies the same separation to another identifier layer.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

How to read this matrix without turning it into a ranking

Read each cell as a dated, scoped record of vendor-published or public-repository evidence, not as a score, rank, preferred path, product test, or prediction of current behavior.

The roster and thirteen attributes were fixed before the comparison was written. Rows appear in alphabetical order by the operating entity recorded in the cells. Inclusion, order, detail, or source availability does not express an endorsement. The page supplies no score, rank, best label, highlight, shortlist, or recommendation, and it carries no affiliate parameter.

Each cell should be read with its product, plan, region, platform, claim type, source class, source URL, capture date, and observation version. The capture date states when the document was collected; it does not promise that a policy, interface, product, or repository remains unchanged. A vendor-stated cell describes the captured vendor document. A public-repository cell describes the bounded artifact it names. Neither label silently becomes independent performance evidence.

Unknown and not-applicable values preserve different boundaries. A gap means the captured evidence did not settle the field. A verified absence means the declared primary documents did not disclose it under the capture method. Documented not applicable means the field does not belong to the described path at that scope. None of those labels should be rewritten as no, none, unsupported, zero, or proof that the underlying thing cannot exist.

The matrix does not establish that WHOIS redaction prevents registrar collection, registry processing, RDAP access, lawful disclosure, payment processing, or account linkage. It does not establish that closing an account erases every registration or billing record. It also does not treat the custom-domain mail path as a registrar; registrar-only controls remain with the external registrar a reader actually uses.

The privacy-tool comparison methodology and corrections hub is the canonical location for the evidence labels and correction channel. This matrix remains bounded to the five-row, sixty-five-cell evidence set described by this version.

Related research

• Private Phone-Number Apps: Identity, Retention, Porting, and LimitsAn adjacent comparison separating provider collection from the identifier shown to a counterparty
• Email-Alias Services: Identity, Retention, Replying, and LimitsAn adjacent comparison for the email-address layer used with an alias domain