Transfers

Three different things are called a transfer here, and they behave differently. Work out which one you are doing before you start.

You want to	Read
Bring a domain here from another provider	Transferring in
Move a domain away to another provider	Transferring out
Take over a domain held by another ITSH customer	Between two ITSH accounts

Transferring in

Search the domain under Domains → Register domain. A domain that is already registered comes back as Taken, and the row grows an Auth code box and a transfer button. Fill in the code, add it to the cart, check out.

The auth code (also called an EPP code or a transfer code) comes from your current provider. In Multi-check you can supply it inline instead, one domain per line:

example.com:AUTHCODE

Whether a code is needed at all is a property of the extension. Where it is not, the box is replaced by:

No auth code needed – approval via email to admin contact (up to 15 days)

That approval goes to the domain's admin contact at the losing provider, not to your ITSH account, which is why step 3 below matters.

Before you start, at the losing provider:

1. Unlock the domain. A locked domain rejects the transfer at the registry.
2. Get the auth code.
3. Check the contact email on the domain still reaches you, because the registry confirmation goes there.

A wrong auth code costs you the order, not just the attempt

The transfer is attempted when the order is fulfilled, after payment. A code the registry rejects is a permanent failure, not something you can correct in place: the order is retried a few times over about 20 minutes, then fails and is refunded. Get a fresh code from the losing provider and order again.

A transfer does not carry your DNS with it

The zone is not copied from the losing provider. Once the domain arrives here its records are whatever the new zone contains, so any site or mailbox that depended on the old zone stops resolving. Write the records down first, or export the zone file at the old provider and paste it into the zone file import here.

Transferring out

Domain Actions → Transfer → Request AuthCode. The portal shows the code and the three steps:

1. Request AuthCode here
2. Set up domain with the new provider
3. Enter AuthCode there

Requesting the code unlocks the domain

The same action that gives you the auth code lifts the transfer lock. That is what makes the transfer possible, and it is also what leaves the domain open to anyone else holding the code. Do not request a code you are not about to use, and if you change your mind, switch Transfer lock back on under Domain Actions.

After the transfer completes the domain is no longer managed here, including its DNS and any mailboxes attached to it. The portal says as much before you start:

After the transfer, the domain will no longer be managed through this portal.

Somebody else started a transfer of your domain

When another registrar asks for one of your domains, you get an email and the request appears under Transfer-Out Requests. Requests are picked up every 5 minutes, so a request will show up shortly after it is made rather than instantly.

The portal is blunt about the risk, and it is right to be:

If you did NOT initiate this transfer, reject it immediately!

Action	What it needs
Reject transfer	Nothing. Rejecting is protective, so it is never gated
Approve transfer	A 6-digit code: from your authenticator app if you have TOTP on, otherwise one emailed to you

No deadline is shown on these requests

The portal lists a detection time and the gaining registrar, but nothing tells you how long you have. Treat the notification email as the clock and respond to it, rather than leaving the request sitting in the list.

Between two ITSH accounts

A domain held by another ITSH customer does not go out to the registry and come back. It moves directly, and how it moves depends on whether you have the auth code.

Because the registration period is already paid for, you are charged pro rata for what is left of it rather than a full year. Where 7 days or less remain there is nothing meaningful to pro-rate and you pay the normal price.

With the auth code, it behaves like any other transfer in: add it to the cart with the code and it completes at checkout.

Without the auth code, the seller has to agree. Checking out creates an Internal Transfer Request on their side, and your purchase waits. They get an email and see it under Internal Transfer Requests, with the same approve-needs-a-code, reject-needs-nothing split as a transfer out.

Unanswered requests expire after 14 days

An internal transfer request that the seller neither approves nor rejects expires 14 days after it was created, and the transfer does not happen. The portal shows the expiry date on the request.

Two things are checked at the moment the transfer completes, and either one stops it:

• The seller must still hold the domain and the registration must not have lapsed. A domain past its registration period cannot be transferred, only restored.
• A cancellation the seller had scheduled is undone as part of the transfer, so you do not inherit a registration that is set to lapse.

What's next

• DNS records to rebuild the zone after a transfer in
• Renewal, cancellation and restore for what a cancellation does to a transfer