whois inaccuracy complaint: report false data to ICANN

If you need to report false registration details for a domain, the route you are looking for is a whois inaccuracy complaint. In plain terms, this is a report to ICANN that asks for suspected inaccurate registration data for a gTLD domain to be reviewed. The key practical point today is that, for gTLDs, you should base your complaint on the RDAP record you can retrieve now, because RDAP became the definitive source for gTLD registration data on 28 January 2025.

A whois inaccuracy complaint is useful when you can point to specific registration fields that appear false, misleading, or non-functional. It is not the right tool for website content complaints, trade mark disputes, hacked accounts, registrar billing problems, or arguments over who really owns a name. If you approach it as a narrow data accuracy report, gather the right evidence, and focus on exact fields rather than assumptions, you are far more likely to submit something clear and useful.

What a whois inaccuracy complaint is, and when to use one

A whois inaccuracy complaint is a report about suspected false or inaccurate domain registration data. Despite the name many people still use, for gTLDs the practical record to assess now is the RDAP record, not the old WHOIS port 43 output. ICANN’s RDAP became the definitive source for gTLD registration data on 28 January 2025.

Use this process when you believe a registration field is wrong in a meaningful way. That might be an address that cannot exist, an entity name that conflicts with the rest of the record, or a contact route that appears non-functional where the field is meant to work.

Do not use it for broader disputes. It is not designed to decide rights, liability, or bad behaviour on a website.

Typical cases where this process is appropriate include:

• Suspected false registrant, admin, or technical contact details
• Contact information that appears fabricated or internally inconsistent
• Registration data that cannot plausibly identify or reach the registrant as required

Cases where it is the wrong tool include:

• Complaints about website content
• Trade mark or brand disputes
• Hacking, phishing, malware, or account compromise reports
• Billing disputes with a registrar
• Ownership fights between former partners, employees, or clients

Think of it as a data quality complaint, not a general domain complaint. That distinction matters.

RDAP versus WHOIS: where to check registration data now

Many searchers still type “WHOIS” because that was the standard label for years. That habit is understandable, but for gTLD registration data the record you should review now is the RDAP output. ICANN’s RDAP became the definitive source for gTLD registration data on 28 January 2025, when WHOIS port 43 obligations for gTLD registries and registrars ended.

In practical terms, that means older guides can mislead you. A tutorial may tell you to copy a WHOIS result, but if it was written before the change, it may not reflect the current source of record for a gTLD complaint. The safer approach is simple: pull the RDAP record and work from that.

This shift can create confusion because the search intent has not changed. People still want to inspect registration data. They just need to use the newer protocol and output.

When checking a domain, look for core registration details such as:

• The registrar shown
• Registration and status information
• Contact objects or redaction notices
• Name server and related technical data where relevant

If a help page, blog post, or forum answer tells you to rely on legacy WHOIS alone, treat it cautiously. For gTLDs, the operative record for your review is now RDAP, even if people still casually call the process a whois inaccuracy complaint.

Before you file a whois inaccuracy complaint

A good complaint starts with a careful pre-flight check. First, confirm that the domain is a gTLD, because the ICANN process discussed here is aimed at gTLD registration data. Then gather the record cleanly and note exactly what you think is wrong. Vague reports tend to go nowhere.

At minimum, record the basics before you submit anything:

• The exact domain name
• The date you performed the lookup
• The registrar shown in the RDAP record
• Each specific field you believe is inaccurate
• Why you think each field is inaccurate

Be precise about the difference between redaction and falsity. Since GDPR took effect on 25 May 2018, most registrant personal data in WHOIS became redacted. Similar limits appear in RDAP outputs. That is normal. A redacted email, phone number, or street line does not, by itself, prove that the underlying registration data is false.

It also helps to sense-check timing. If a domain was very recently registered or recently moved to a new registrar, data changes may be recent too. A domain usually cannot be transferred to another registrar for 60 days after registration or a registrar transfer, which can matter if you are trying to understand a recent registrar change in the record.

Submit only after you can identify concrete fields and concrete reasons.

What counts as false or misleading registration data

False or misleading registration data is not just data you dislike or data you cannot see publicly. The question is whether a specific registration field appears inaccurate, fabricated, impossible, or materially inconsistent.

Clear warning signs often include impossible physical details, contact routes that do not function where they are meant to function, or combinations of fields that plainly do not fit together. For example, an organisation name may conflict with the jurisdictional details beside it, or an address may be structurally impossible on its face.

Common examples may include:

• An address that does not exist or cannot be validly formatted
• A contact route that fails in a way suggesting it is not genuinely usable
• Entity details that contradict one another within the same record
• Text that appears random, placeholder-like, or fabricated

What does not count, on its own, is the absence of public personal data because of privacy redaction. Since GDPR took effect on 25 May 2018, much registrant personal data has been withheld from public view. That can make a record feel incomplete, but incompleteness caused by lawful redaction is not the same thing as inaccuracy.

The best test is this: can you point to a particular field and explain, with reasons, why it appears wrong rather than merely hidden. If yes, you may have grounds for a whois inaccuracy complaint.

What evidence helps a whois inaccuracy complaint

Useful evidence is specific, relevant, and restrained. You do not need a long dossier. You need enough material to show exactly which field appears inaccurate and why. Start with the RDAP record itself, because that is the operative gTLD registration data source. Save a copy and take screenshots that clearly show the date and the fields you are relying on.

Good supporting material can include:

• Screenshots of the RDAP result
• A saved copy of the RDAP record
• A note of the lookup date
• Public records, if they directly bear on a claimed entity or address
• Bounced contact attempts, where a field is meant to function and you have a legitimate reason to test it
• A short explanation linking each item of evidence to each disputed field

Keep your explanation factual. If you believe an address is impossible, say why. If an entity name conflicts with public registration details, point to the conflict. If a contact route failed, note what happened without exaggeration.

Avoid speculation, pressure tactics, or repeated unwanted contact. Do not use the process to harass a registrant or to fish for private information. Accuracy matters on both sides. A concise, field-by-field complaint supported by clean evidence is usually stronger than an emotional or wide-ranging accusation.

How to submit a WHOIS inaccuracy complaint to ICANN

If you want to file a whois inaccuracy complaint, the aim is simple: point ICANN to specific registration data that appears false or incomplete for a gTLD domain. Keep it factual and narrow. Broad accusations are harder to assess than a clear report tied to named fields.

Since 28 January 2025, RDAP is the definitive source for gTLD registration data. That means you should review the domain’s current RDAP output before submitting anything, rather than relying on older WHOIS port 43 results.

A practical process is:

• Find ICANN’s inaccuracy reporting form or reporting channel for registration data issues.
• Enter the exact domain name.
• Identify the fields you believe are inaccurate.
• Explain, field by field, why each item appears false, incomplete, or internally inconsistent.
• Attach concise supporting material if the form allows.

Good complaints usually focus on concrete points such as an impossible postal address, a non-working contact route, or contradictory registry data. If a name, email address, phone number, or address is redacted, do not guess what sits behind the redaction. Report only what you can actually observe.

Use short, neutral language. For example, explain that a field appears invalid because it does not match the stated country format, or because the published contact route does not function. Clear, field-by-field reporting gives ICANN and the contracted party a much easier starting point for review.

What happens after a whois inaccuracy complaint is filed

Once a whois inaccuracy complaint is submitted, ICANN does not usually treat it as a public adjudication about ownership, bad faith, or website conduct. In general terms, it routes the report for review and follow-up under the applicable contractual framework for the relevant gTLD registrar or registry.

That distinction matters. A complaint about inaccurate registration data is primarily an accuracy and compliance issue. It is not, by itself, a shortcut to seize a domain, force a transfer, or suspend a website.

A typical path looks something like this:

• ICANN receives the complaint and checks whether it is within scope.
• The report is routed for review under the relevant contractual process.
• The registrar may be asked to review the named data and, where appropriate, seek clarification or verification from the registrant.
• Further action, if any, depends on what the contracted party finds and what the rules require.

Outcomes are often less dramatic than complainants expect. You may not receive a detailed narrative of what was checked. You may also not see an immediate public change in registration output.

Set realistic expectations. Filing a complaint does not automatically freeze the domain, stop a sale, block a transfer forever, or move the name into your control. It is a tool for reporting suspected inaccuracies in registration data, nothing more. If your real problem is infringement, fraud, impersonation, or a live security issue, another route may be more appropriate.

Why your complaint may not lead to visible public changes

A common source of confusion is that a whois inaccuracy complaint can trigger review without producing any obvious public difference in the record you can see. That is especially true in the post-GDPR environment.

GDPR took effect on 25 May 2018. After that date, most registrant personal data in WHOIS became redacted. In practice, many public outputs for gTLD domains now show limited contact information, even where the underlying registration has been reviewed or updated privately.

So, if you submit a complaint and later check the domain again, the lack of visible personal details does not necessarily mean nothing happened. It may simply mean the registrar is handling verification privately while continuing to publish only the data that can properly appear in public output.

Keep these points in mind:

• Public redaction after 25 May 2018 is normal for many gTLD registrations.
• A registrar can carry out private checks without revealing the results in public registration data.
• RDAP may show role-based or limited contact information rather than full personal details.

This is one reason field-by-field complaints matter. If the visible issue is a clearly malformed organisation name, country code, nameserver pattern, or technical inconsistency, that is easier to assess from the outside. By contrast, if the potentially inaccurate element is personal contact data that is no longer publicly displayed, the visible record may remain sparse even after review.

Common timing issues: transfers, expiry, and deletion cycles

People often file a whois inaccuracy complaint because they are watching a domain closely and hope the complaint will alter its timetable. Usually, it will not. Registration lifecycle rules and transfer timing are separate from accuracy reporting.

First, a domain usually cannot be transferred to another registrar for 60 days after registration or a registrar transfer. That timing issue often causes confusion when a domain has changed hands, moved registrar, or appears to be in flux. The inability to transfer in that window is not, by itself, evidence of false registration data.

Secondly, if the domain has expired, many gTLDs follow a common path after expiry:

• An auto-renew grace period of up to 45 days.
• A 30-day redemption period.
• 5 days of pending delete.

These stages matter if your real concern is whether the name may drop, be renewed, or still be recoverable by the existing registrant. They are operational lifecycle stages, not enforcement stages arising from an inaccuracy complaint.

That means you should not assume that filing a complaint will accelerate deletion, interrupt redemption, or create a transfer opportunity. In many cases, the better approach is to monitor the domain’s status carefully through RDAP and registrar signals, while keeping your expectations grounded in the ordinary lifecycle of the name rather than in the complaint process.

When a whois inaccuracy complaint is the wrong tool

A whois inaccuracy complaint is useful when the problem is the registration data itself. It is the wrong tool when your actual issue is something else. Using the right route from the start is usually faster and more effective.

If the problem is website abuse, malware, phishing, spam, or hosting misconduct, use the relevant abuse reporting channels. Those issues are usually handled through registrar, registry, host, network, or platform abuse desks rather than through an accuracy complaint.

If the issue is a trade mark conflict, ownership dispute, or a disagreement over who should control the domain, you will usually need the relevant dispute process or tailored legal advice. Accuracy reporting is not designed to decide competing rights.

If the domain has simply expired, monitor its lifecycle instead of trying to use an inaccuracy complaint as leverage. The normal post-expiry sequence for many gTLDs is separate from any complaint you file.

As a quick rule:

• Use an inaccuracy complaint for specific, supportable registration data issues.
• Use abuse channels for harmful site or email activity.
• Use the appropriate dispute route for trade mark or ownership conflicts.
• Use lifecycle monitoring for expiry, redemption, and pending delete situations.

A whois inaccuracy complaint works best when it is narrow, evidenced, and used for the purpose it was built for. If you need a quieter strategic view on a sensitive domain situation, Westmore can review it confidentially.