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

If you sign in only after the domain is in the cart, the code does not come along to your account. Take the domain out of the cart and add it again with the code before you check out.

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. If the registry refuses the request outright, the order is retried a few times over about 20 minutes, then fails and is refunded. If it accepts the request and the transfer fails later, the order is undone as described below. Either way, 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.

While the transfer is pending

Once the order goes through, the domain appears under Domains marked Transfer pending, and you get an email saying the transfer has been requested. The losing provider and the registry still have to complete it. That usually takes a few days, and the losing provider may ask you to confirm it.

You can already:

• edit DNS records and DynDNS, so the zone is ready when the domain arrives
• remove delegates

Not until the transfer completes:

• name servers, contacts and the other domain settings
• adding or changing delegates, for the domain or for its mailboxes
• setting up the mail DNS records
• using the domain as a hostname or redirect of a hosting site

The transfer is checked every 15 minutes. When the registry reports it complete, the domain switches to active and you get a confirmation email.

A failed transfer is undone automatically

If the registry reports the transfer as failed or cancelled, the domain is removed from your account, its subscription ends and what you paid for the domain is refunded. A DNS zone the order set up is removed too, so if you already pointed the name servers at ours, switch them back at the losing provider. An email plan bought in the same order stays active, and the email you get explains what it needs. A transfer that the registry drops without completing it is handled the same way after 14 days.

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 when you click approve, valid for 10 minutes and good for one use

Five wrong codes end approval for that request

After five wrong codes the request can no longer be approved, and you get an email saying so. Rejecting still works. Do it if you did not start the transfer: a transfer out that is left unanswered can still complete automatically at the registry's deadline.

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. The emailed code names the buyer's email address, and five wrong codes end approval for that request here too.

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