What the TDRP is
The Registrar Transfer Dispute Resolution Policy — TDRP — is ICANN's adjudication procedure for transfers that should not have happened. It sits underneath the Transfer Policy, the consensus policy governing how a domain moves between registrars, and exists to answer one question: was this particular inter-registrar transfer executed in accordance with that policy?
It is narrow by design. The TDRP does not ask who ought to own a domain, whether a trademark was infringed, or whether anyone behaved dishonestly in a general sense. It asks whether the transfer complied with the rules, and its remedies follow from that framing.
The current text was updated on 21 February 2024 to reflect changes required to implement the Registration Data Policy. Contracted parties may implement the updated policy from 21 August 2024 and must implement it no later than 21 August 2025. ICANN also records that this version applies to complaints filed on or after 1 December 2016.
Understanding the TDRP matters even if you will never file one, because it is the backstop that gives a losing registrar a reason to take an unauthorized transfer seriously.
You cannot file it — and that changes everything
This is the fact that surprises registrants, and occasionally attorneys, most reliably. Under the published policy the parties to a TDRP are registrars. The complainant is either a Losing Registrar alleging that a domain was transferred away fraudulently, or a Gaining Registrar contesting a transfer it says was improperly denied. The registrant is not a party.
Practically, the registrant's route runs through the registrar the domain was taken from. Where a transfer was wrongly denied rather than wrongly executed, ICANN also operates a transfer complaint form for registrants, which is a different mechanism with a different purpose.
The consequence deserves stating bluntly. Your access to the purpose-built ICANN remedy depends on persuading a company that has already failed to protect you to act as your advocate, at its own cost, against another registrar. That is why the tone and content of the first contact with the losing registrar matters so much — you are not filing a complaint about them, you are recruiting them. In my experience, the cases that go nowhere are usually the ones where the registrant spent the first week telling the losing registrar it was to blame.
The twelve-month clock
The policy is explicit: a dispute must be filed no later than twelve months after the alleged violation of the Transfer Policy. Depending on the complaint type, that period runs from the date the transfer completed or from the date a NACK — a transfer denial issued by the losing registrar — was received.
Twelve months sounds generous. It is not, for two reasons. The first is detection: perl.com was compromised around September 2020 and the change was not noticed until 27 January 2021, consuming four months of any applicable window before anyone knew there was a problem. The second is that the twelve months must accommodate everything that comes before a filing — discovering the loss, assembling ownership evidence, getting the losing registrar's attention, getting its compliance or legal function to agree to file, and preparing the complaint itself.
Letting the twelve-month clock expire is one of the recurring mistakes in this area, and it is uniquely unforgiving because no other ICANN procedure substitutes for it.
What a panel can and cannot order
The remedies are limited to two: approve the transfer, or deny the transfer — potentially ordering the return of already-transferred domains. That return power is the whole point of the procedure, and it is genuinely useful. But note what is absent.
- No damages. Nothing compensates for lost traffic, lost mail, or the cost of the incident.
- No findings against individuals. The dispute is between registrars about a transfer, not about the person who executed it.
- No reach into a sale. Where a name has been sold onward, the commercial position of a purchaser claiming good faith is not something the panel is structured to resolve.
- No injunctive relief beyond the transfer. Nameserver changes, content, and certificates are outside its scope.
Where any of those matter — and where a domain has real value they usually do — the TDRP is one component of a response rather than the whole of it, and counsel qualified in the relevant jurisdiction should be involved in deciding what runs alongside it.
Where a TDRP is filed
ICANN's approved-providers page lists two dispute-resolution providers for the TDRP: the Asian Domain Name Dispute Resolution Centre (ADNDRC), effective 28 February 2002, and the National Arbitration Forum (NAF), effective 23 December 1999, both listed until further notice. ICANN announced the approval of providers for the TDRP on 8 November 2004.
There is a second route that is easy to miss. ICANN's page states that complaints under the TDRP may be submitted either to the appropriate registry operator or to an approved dispute-resolution service provider. For a first-level, registry-level dispute the complaint can therefore go to the registry operator rather than to an external provider — a materially different path, since the registry is the party that actually holds the authoritative record.
This site does not quote fees, which change; the providers publish their own. ICANN maintains the current provider list, and it is worth checking rather than assuming, because provider arrangements have shifted over the policy's life.
TDRP against UDRP and URS
Three ICANN procedures are routinely confused, and picking the wrong one wastes time you may not have.
TDRP polices the transfer mechanism. It asks whether a specific inter-registrar transfer complied with the Transfer Policy, is filed by registrars, and can order a domain returned.
UDRP — the Uniform Domain-Name Dispute-Resolution Policy — polices trademark abuse. It asks whether a registrant registered and is using a name in bad faith to exploit a complainant's mark, and it is filed by the trademark owner. Its applicability to theft is disputed, which makes sense once you see the mismatch: a thief holding your exact domain is not the confusingly-similar-name scenario UDRP was built for.
URS — Uniform Rapid Suspension — is a fast trademark-based suspension procedure. It suspends; it does not transfer.
The Transfer Policy ties them together in one respect worth knowing: a registrar must deny a transfer where UDRP proceedings, TDRP proceedings, a court order, a URS suspension, or a 60-day Change of Registrant lock apply. A pending proceeding is therefore also a freeze.
How registrants actually reach a TDRP
The sequence that works looks like this, and each step exists to make the next one possible.
- Preserve the record. Capture WHOIS and RDAP output, DNS answers and registrar notification emails before anything else changes.
- Notify the losing registrar in writing, immediately, stating that the transfer was unauthorized and objecting expressly. Express written objection by the authorized transfer contact is itself a ground on which a transfer may be denied.
- Ask for TEAC escalation by name. The Transfer Emergency Action Contact is the registrar-to-registrar emergency channel carrying a four-hour response obligation under the Transfer Policy.
- Supply ownership evidence proactively — invoices, historical registration records, correspondence — rather than waiting to be asked.
- Ask the losing registrar, explicitly, to file a TDRP, and to confirm in writing if it declines and why.
- Escalate in parallel. Where the loss is material, counsel and, where appropriate, a report to law enforcement should run alongside rather than after.
The blunt version: the TDRP is a good remedy that you are not allowed to invoke. Everything above is about getting someone who can invoke it to want to.
The weak points, and what may change
The TDRP's structural weakness is the one already stated — the party with the loss is not the party with standing. Its second weakness is timing: twelve months is measured from the violation, not from discovery, so a hijack designed to go unnoticed eats the window while the registrant sleeps. SAC007 recognized the enforcement gap as far back as 2005, recommending that ICANN investigate whether stronger and more publicly visible enforcement mechanisms were needed for registrars that fail to comply with the transfer policy.
Change is in progress but not in force. ICANN's Public Comment Summary Report of 2 July 2025 on the Transfer Policy Review Working Group's Final Report records 47 policy recommendations, including reducing the 60-day post-creation and post-transfer restrictions to 30 days and eliminating the 60-day post-Change-of-Registrant restriction. The GNSO record shows the Final Report submitted on 5 February 2025, Council adoption on 12 March 2025, and the Council's report to the Board on 10 April 2025, with Board resolution and implementation both listed as TBD. Public comment ran from 28 April to 16 June 2025.
Until the Board acts, the 21 February 2024 text is what governs.