Guides

Auth codes explained

The authorisation code is the single credential that allows a domain to move between registrars. Handing one over is the point of no return in most deals, so the checks around it matter more than the code itself.

On this page

  1. What the code is for
  2. Where sellers get one
  3. Why codes expire
  4. Checks before a seller sends a code
  5. Checks before a buyer submits one
  6. Handling codes safely

What the code is for

An authorisation code, also called an EPP code, auth code, AuthInfo or transfer code depending on the registry, is a short string held against the domain record. The gaining registrar submits it with the transfer request. If the string matches, the registry accepts that the request came from someone with control of the name.

The code proves control, not ownership. A registry has no view on who paid for the domain or what was agreed. Anyone holding a valid code and facing an unlocked domain can start a transfer, which is why a code should never travel ahead of the payment arrangement.

Where sellers get one

For generic extensions such as .com, .net and .org, the code is generated on request in the registrar control panel and is usually shown on screen or emailed to the registrant address. Registrars that hide it behind a support ticket exist, and that adds a day or two.

Country code registries differ:

  • .de: DENIC calls it an AuthInfo. It is set through the current provider and is between eight and sixteen characters long.
  • .be: DNS Belgium issues a transfer code to the registrant, who passes it to the gaining registrar.
  • .eu: EURid codes come from the current registrar or from the registrant account at the registry.
  • .nl: SIDN uses a token, which the losing registrar must supply on request within five days.
  • .co.uk: no code exists. The name moves by changing the registrar tag instead, which is covered in the transfer rules by extension.

Why codes expire

Registries limit how long a code stays usable so that an old string leaked from an email archive cannot be used years later. The window is short and it varies.

DENIC expires an AuthInfo automatically after thirty days, after which a new one has to be requested. DNS Belgium sets a transfer code valid for seven days and allows it to be resent, each resend starting a fresh seven day window. Generic extension registrars set their own validity, and many rotate the code whenever the registrant regenerates it or changes account credentials.

The practical rule is to treat every code as short lived. Request it when the buyer is ready to submit the transfer, not weeks in advance while the price is still being discussed.

Checks before a seller sends a code

  1. Confirm the money is in a position the seller controls or an escrow holds. A bank transfer that is still in progress is not a received payment.
  2. Confirm the buyer identity matches the paying account. A payment from a third party name that nobody explained is a reason to pause, not to proceed.
  3. Remove the registrar lock first. A correct code against a locked domain produces a failed transfer and a support ticket.
  4. Check the registrant email on file is still reachable. Confirmation messages go there, and a dead address stalls the whole transfer.
  5. Send the code through the agreed channel only. If an escrow service is in the flow, the code goes to the escrow, never directly to the buyer.

Checks before a buyer submits one

Verify the code against the actual domain rather than trusting the message it arrived in. A transfer request that returns an authorisation error tells the buyer nothing useful about who is at fault, so eliminate the obvious causes first: the lock is still on, the name is inside a waiting period, or the code has been regenerated since it was sent.

Screenshot the transfer request and its status page. If the seller later claims the code was never used, the timestamped record settles it. Keeping that trail is part of the documents worth archiving.

Handling codes safely

A code in a chat window, a shared inbox or a support ticket is a code that several people can read. Send it in a single channel, ask for confirmation of receipt, and regenerate it if a deal falls apart after the code was disclosed.

A code that has been shared and then abandoned should always be regenerated. The old string may still be valid until the registry window closes.

Sellers who list names on a marketplace should also check what the platform does with codes. Some hold the code and release it on payment confirmation, which removes the worst of the timing risk. A deal that runs through escrow works the same way: the code sits with a party who has no interest in either side keeping both the money and the name.