Skip to content

Knowledgebase

Investigate a rejected domain transfer using the actual registry reason

domains-dns

Resolve a rejected transfer using its actual failure reason. A wrong authorisation code, an ownership restriction and a payment problem require different actions. A new order with the same unresolved condition usually fails again.

01 Collect the evidence from the failed request

  1. Record the exact domain, request time, order or job reference and current transfer state.
  2. Copy the error code and message without exposing the authorisation code, API key or personal documents.
  3. Read the current registrar and full domain status list.
  4. Ask whether the failure occurred before registry submission or was a registry or losing-registrar rejection.
  5. Confirm the billing treatment of the existing order before submitting another paid request.

02 Match the remedy to the reason

  • Invalid authorisation: obtain the current code from the authorised provider workflow. Check accidental spaces and whether a newer code replaced it.
  • Transfer prohibited: identify an ordinary lock, timed restriction or registry condition before trying to unlock.
  • Pending or duplicate request: inspect the existing transfer; do not start another while it remains unresolved.
  • Contact or approval issue: recover authorised access and complete the actual required confirmation.
  • Lifecycle or eligibility issue: resolve restoration, documentation or extension-specific requirements with the provider.

Can support simply force the transfer through?

Support can investigate the request, correct a recoverable issue and explain the registrar's reason. It cannot assume authority to override a valid dispute, registry restriction or missing holder approval. Provide evidence showing why a rejection is mistaken if you want it reviewed.

For a generic domain, the registrar's transfer policy constrains permissible denials. If a policy dispute remains after contacting the registrar, use the current ICANN complaint process for the relevant issue. Keep the original correspondence and dates; an isolated screenshot without the domain or request context is difficult to assess.

When the cause is corrected, agree whether the original order can be retried or a new request is needed. API integrations should distinguish a transport retry from a new business operation and use the documented idempotency rules. Verify completion through the resulting status and new sponsoring registrar.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support