Whois / RDAP Lookup

Free, no signup. Registry data, without old WHOIS parsing: registrar, dates, nameservers, domain locks, and clear privacy-redaction context.

Built by Patrick Stox

Checks run from our server; we fetch the URL you enter and don't keep the results. This queries IANA's RDAP bootstrap and the relevant registry. Results may be cached for up to 24 hours; registry privacy policies can redact contacts. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Whois Lookup? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
  
 
Sample report
Illustrative example — documentation-domain fixture
example.com
  • Created: 1995-08-14
  • Registrar: published by registry response
  • Registrant: redacted by registry privacy policy
  • Nameservers: observed RDAP values
  • Status: clientTransferProhibited — transfer is locked at the registrar
Dates and parties in a real report are displayed only when the registry publishes them; missing values remain “Not published.”
 
 
How to use it
  1. Enter a root domain and choose Look up domain.
  2. Review registry dates and registrar separately from registrant contact data.
  3. Read each EPP status explanation and confirm actionable locks in the registrar account.
  4. Use the DNS handoff when nameserver publication needs a resolver-level check.
 
 
     
     
     
How to read the result
Registration dates are normalized registry events. Parties are registry-published roles and may be redacted. Nameservers are RDAP registration data, not a live DNS resolution test. Statuses are EPP codes with plain explanations, not independent diagnoses.
Data sources & freshness
The endpoint normalizes the domain, follows IANA’s RDAP bootstrap to the responsible registry service, and returns structured events, entities, nameservers, and statuses. The browser formats dates, calculates days to published expiry, and explains supported EPP status codes. Responses may be cached for 24 hours.
Features
  • Structured registrar, date, nameserver, and status fields.
  • Privacy-redaction context instead of blank-owner assumptions.
  • Plain-language EPP status explanations.
  • Prefilled handoff to DNS Checker.
Limitations
Some ccTLDs lack complete RDAP service, registries redact data, and published dates or parties can be absent. The tool does not bypass privacy, guarantee deletion timing, manage renewals, or replace the registrar account. Cached dataCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. may lag a recent change.
 
Frequently asked questions
Why is registrant information missing?
Many registries redact registrant data under privacy policy or GDPR. Missing data is not proof the domain has no registrant.
Is this WHOIS?
It provides the same practical lookup information via RDAP, the structured successor to traditional WHOIS. Some ccTLD registries do not yet publish RDAP data.
What do clientTransferProhibited and other domain statuses mean?
They are EPP status codes published by the registry. The report explains common locks and holds, but your registrar is the authority for why a status is set and how to change it.
Is the expiry date a guarantee that the domain will be deleted then?
No. Expiry, grace, redemption, auction, and deletion policies vary by registrar and registry. Treat the published date as an operational reminder and confirm renewal in the registrar account.
Next stepDNS Checker — verify it with a direct check.

Explore more
ToolHTTP Header CheckerToolHosting CheckerToolWebsite Down CheckerArticleHTTPS for SEOArticleSSL/TLS CertificatesArticleHSTS: HTTP Strict Transport Security for SEO
 
 
 
Feature requests for Whois Lookup
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
   
       
 
Common issues & how to fix them
 
 
 
 
 
Whois / RDAP Lookup · one finding
 
Domain has serverHold status
 
Recommended action: Contact the registrar or registry to resolve the serverHold cause before expecting DNS publication to resume.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
 
 
 
Whois / RDAP Lookup · one finding
 
Domain has clientHold status
 
Recommended action: Resolve the registrar’s clientHold condition, then confirm the status clears and authoritative DNS answers return.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
 
 
 
Whois / RDAP Lookup · one finding
 
Domain is in redemption period
 
Recommended action: Request domain restoration through the registrar and pay any redemption fee before the redemption period ends.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
 
 
 
Whois / RDAP Lookup · one finding
 
Domain is pending deletion
 
Recommended action: Confirm whether restoration is still possible; otherwise monitor the registry drop because ordinary renewal is no longer available.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
 
 
 
Whois / RDAP Lookup · one finding
 
Domain registration expires soon
 
Recommended action: Renew the domain now, enable auto-renew with valid payment details, and verify the updated RDAP expiration date.
 
Fix principle: Resolve availability failures from the outside in: registry status and expiry, authoritative delegation, DNS answers, network/TLS reachability, and finally the HTTP application. Change only the first confirmed failing owner, and treat SPF/DMARC hygiene as mail-domain policy rather than a web-availability fix.
 
 
 
 Implementation for your setup 
 
Confirm first: The domain has a registry hold, redemption, pending-delete, or near-expiry state requiring registrar action. Authoritative DNS returns SERVFAIL, inconsistent answers, or lacks a record required for the intended service. DNS resolves but the origin cannot connect, returns persistent server errors/maintenance, or enters a broken redirect path. A domain that sends mail lacks the intended SPF or DMARC policy.
 
Do not apply when: The failure occurs only at one recursive resolver while authoritative DNS and multiple independent resolvers agree. The queried record is intentionally absent because the domain does not provide that service. A temporary application maintenance response is approved, bounded, and not a domain/DNS failure.
 
Likely control points: server · edge-cdn · content-data · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Registrar, authoritative DNS provider, origin/edge, and mail sender configuration
 
Steps
  1. Check the registry status and expiration first. Resolve holds, redemption, payment, verification, or nameserver problems with the registrar before changing application configuration.
  2. Query the authoritative nameservers directly and compare multiple recursive resolvers. Correct delegation, DNSSEC, missing/incorrect A/AAAA/CNAME records, or provider outages at the authoritative owner.
  3. Once DNS is stable, test TCP/TLS and the origin/edge response. Correct connection failures, persistent 5xx/maintenance states, or redirect loops at the layer emitting them.
  4. For a domain that sends mail, inventory every legitimate sender before publishing or tightening one SPF record and a DMARC record at `_dmarc`; begin DMARC enforcement only after reports show legitimate sources align.
  
Verify on this platform
 
  • Confirm the registry status is active and the intended nameservers are delegated.
  • Confirm authoritative and independent recursive answers converge after the relevant TTL.
  • Request the site through the public hostname and confirm a successful, stable response without a redirect loop.
  • Validate SPF and DMARC syntax and test legitimate mail flows before increasing enforcement.
 
Rollback
  1. Restore the prior DNS record set from an export if a change removes a working service; remember that cached answers persist until TTL expiry.
  2. Relax a newly tightened SPF/DMARC policy if verified legitimate senders fail, then inventory and align those senders before retrying.
 
Caveats
  • DNS changes are not instant; cached records can make resolvers disagree until TTLs expire.
  • SPF permits one policy record and has processing limits; blindly combining vendor snippets can create a permanent error.
  • DMARC enforcement can reject legitimate mail when SPF/DKIM alignment is not ready. Start with reporting and measured rollout.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Registrar, DNS host, commerce/CMS host, or email vendor
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to identify the authoritative layer, exact failing status, active configuration, propagation TTL, and rollback path.
  • Verify registry, authoritative DNS, public HTTP, and mail policy independently after the vendor change.
  
Caveats
  • Escalate immediately for redemption/pending-delete status or when no one controls the registrar account.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Verify registry, delegation, authoritative DNS, recursive DNS, connection/TLS, and HTTP in that order.
  2. Wait through documented TTLs before treating recursive disagreement as a persistent failure.
  3. Test legitimate mail senders before tightening SPF or DMARC.
  4. Rerun DNS Checker and Website Down Checker after public propagation.
 
Escalate when
 
Escalate immediately for registry redemption or pending delete, lost registrar/DNS access, DNSSEC failures without a key owner, persistent multi-resolver SERVFAIL, or a mail-policy change whose legitimate sender inventory is unknown.
 
 
 
 
  
 
 
     
  •  Information Registration identity is redacted Fix: Use authenticated registrar records for ownership verification because public RDAP redaction is normal and cannot be repaired on the website. 
  •  Information DNSSEC is not indicated Fix: Enable DNSSEC at the DNS provider, publish the DS record through the registrar, and verify the chain of trust. 
    •