BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
The EPP Protocol Explained: How Registries and Registrars Provision Every Domain
EPP, the Extensible Provisioning Protocol, is the standard machine language a registrar speaks to a registry to register, manage, and transfer a domain. Every time a name is created, locked, unlocked, renewed, or moved between registrars, an EPP message carries the instruction. It is defined by the IETF in RFC 5730, the base specification, and a family of companion RFCs.
This guide explains the protocol in plain terms and at the level a domain buyer needs. It covers what EPP is, the command set, the object mappings, the status codes that lock or release a name, and the one point of confusion the whole search query carries: the difference between EPP the protocol and the EPP code, the transfer authorization string registrars hand to buyers.
That distinction matters at the moment of acquisition. When a domain moves from a seller to a buyer, an EPP transfer command and an authorization code do the work. SEO Domains operates the curated marketplace where aged and expired domains are sourced and transferred through that exact mechanism, so understanding EPP is understanding how a name lands in your account.
What is the EPP protocol?
The EPP protocol, or Extensible Provisioning Protocol, is an XML-based standard that lets a registrar communicate with a registry to provision and manage domain names. The registrar sends structured commands, the registry acts on them and replies, and the protocol governs registration, updates, renewals, transfers, and deletions. It is specified by the IETF in RFC 5730 and a set of companion RFCs.
The word provisioning is the key. EPP is not how a browser reaches a website, and it is not the DNS that resolves a name to an address. It is the back-office channel through which the registrar that sold a domain instructs the registry that holds the master record. The registry is the authoritative database for a top-level domain, the registrar is the retailer, and EPP is the wire between them.
The plain-English definition
Picture the registry as the central land registry for a country, the single book that records who holds every plot. The registrar is the estate agent the public deals with. When a buyer registers, renews, or transfers a name, the agent does not edit the master book by hand. It sends a formatted instruction, and EPP is the format of that instruction and the reply that confirms it.
Why a domain buyer should care about a registrar-registry protocol
EPP looks like pure plumbing, yet three things a buyer touches directly are EPP outputs. The status codes that show whether a name is locked or transferable are EPP statuses. The authorization code needed to move a domain is exchanged through EPP. The transfer itself is an EPP command. A buyer who understands the protocol reads those signals correctly instead of guessing.
This is the lens the rest of this guide keeps. The technical detail is grounded in the standards, and every section returns to what the mechanic means for someone acquiring a name. The broader context of who sets these rules sits in ICANN’s role in the domain system.
A short history: from RRP to RFC 5730
EPP grew out of the need for an open, multi-registrar provisioning standard. It replaced the older Registry Registrar Protocol, was first published by the IETF as RFC 3730 in 2004, and reached its current form as RFC 5730 in 2009, which the IETF designated internet standard STD 69. A family of companion RFCs maps the objects EPP manages.
The Registry Registrar Protocol came first
Before EPP, the dominant tool was the Registry Registrar Protocol, RRP, defined in RFC 2832 and used by the early shared-registry system for .com and .net. RRP worked, but it was narrow. It handled a limited object set and was tied closely to one registry’s model, which did not suit a world of competing registries and layered extensions.
EPP as the extensible replacement
The IETF developed EPP to be extensible by design, which is the first word in its name. Where RRP was fixed, EPP was built so that new object types and new data attach through a defined extension mechanism without breaking the base protocol. That flexibility is why registries running divergent rules, from legacy generic TLDs to new ones, all speak the same core language.
The Registry Registrar Protocol, RRP, is documented in RFC 2832 for the shared-registry system. It is the narrow predecessor EPP was built to replace. Source: IETF RFC 2832.
The IETF publishes the first EPP standard as RFC 3730, alongside the domain, host, and contact mappings, establishing the extensible model. Source: IETF datatracker.
RFC 5730 supersedes RFC 3730 as the current base specification, and the EPP suite is designated internet standard STD 69. Source: IETF RFC 5730.
RFC 9154 adds a secure authorization-information model for transfers, hardening how the EPP transfer code is set and used. Source: IETF RFC 9154.
Work on a RESTful successor, discussed by APNIC, AFNIC, and DENIC under the RPP name, explores a modern HTTP-based provisioning interface while EPP remains the deployed standard. Source: APNIC and AFNIC publications.
The RFC family that defines EPP today
EPP is not a single document. The base protocol is RFC 5730, and three mapping RFCs define the objects it manages: RFC 5731 for domain names, RFC 5732 for hosts, and RFC 5733 for contacts. RFC 5734 specifies how EPP runs over TCP. Together they form internet standard STD 69, the stable reference every registry and registrar implements.
How EPP works: client, server, port 700, and XML over TLS
EPP is a client-server protocol. The registrar runs the client, the registry runs the server, and they exchange XML documents over a secure connection. RFC 5734 specifies that EPP runs over TCP, protected by TLS, on IANA-assigned port 700. A session opens with a login, carries a series of command and response pairs, and closes with a logout.
The client-server relationship
The registrar is always the client that initiates. It opens a connection to the registry server, authenticates, and then issues commands. The registry server validates each command against its policy, performs the action on its authoritative database, and returns a structured response with a result code. The buyer sits one step further out, dealing with the registrar, never with EPP directly.
XML messages over TLS on port 700
Every EPP message is an XML document. A command is XML, the response is XML, and the schema for each is defined in the RFCs. The transport is TCP secured with TLS, and IANA has assigned TCP port 700 to EPP, which is why network references list EPP as a port-700 service. The TLS layer means the provisioning channel is encrypted in transit, a baseline the standard requires.
The session model: login, commands, logout
An EPP exchange is stateful. The registrar opens with a login command carrying its credentials, the registry greets it and confirms the session, and from there the two sides trade command-response pairs until the registrar sends a logout. This session structure, defined in RFC 5730, is what lets a registrar run a batch of operations efficiently inside one authenticated connection.
The EPP command set, with an example exchange
RFC 5730 defines a compact command set grouped into session, query, and transform commands. Session commands open and close a connection. Query commands read state without changing it: check and info. Transform commands change state: create, update, delete, renew, and transfer. A poll command retrieves queued messages such as a pending transfer notice.
The commands, grouped by what they do
The whole protocol runs on roughly ten verbs. Knowing the group each falls into makes the behaviour predictable: query commands are safe reads, transform commands write to the registry, and session commands bracket the conversation.
| Command | Group | What it does |
|---|---|---|
| login / logout | Session | Open an authenticated session and close it |
| check | Query | Test whether one or more names are available to register |
| info | Query | Read the full record of an object, including its status codes |
| poll | Query | Retrieve queued service messages, such as a pending-transfer notice |
| create | Transform | Register a new domain, host, or contact object |
| update | Transform | Change an object, including adding or removing status codes |
| renew | Transform | Extend a domain’s registration period |
| delete | Transform | Remove an object, subject to registry policy and grace periods |
| transfer | Transform | Request, approve, reject, or cancel moving a domain between registrars |
An example EPP exchange
A real exchange is two XML documents: the registrar’s command and the registry’s response. The example below is a simplified domain check, the query a registrar runs to tell a buyer whether a name is free, with the structure that the RFC 5731 domain mapping defines.
The response carries a numeric result code. Code 1000 means the command completed successfully, and the data shows the name is taken. Result codes in the 1000 range signal success, the 2000 range signals errors, and the registry returns one for every command. The buyer sees only the registrar’s plain-language verdict, available or taken, while EPP did the asking.
EPP object mappings: domains, hosts, and contacts
EPP separates the protocol from the things it manages. The base RFC 5730 defines how commands work, while three object mappings define what they act on: domain names in RFC 5731, hosts, meaning nameservers, in RFC 5732, and contacts, meaning registrant and admin records, in RFC 5733. This separation is what makes EPP extensible.
Three object types, three RFCs
A domain registration is not one record but three linked objects. The domain object is the name itself. The host objects are the nameservers that answer DNS for it. The contact objects hold the people: registrant, administrative, technical, and billing roles. Each object type has its own mapping RFC that defines its fields and how the generic EPP commands apply to it.
Domain object (RFC 5731)
The registered name itself, with its registration period, status codes, linked hosts and contacts, and the authorization information used for transfers.
Host object (RFC 5732)
A nameserver record, holding the hostname and its IP addresses, which the domain object references to direct DNS resolution.
Contact object (RFC 5733)
A person or organization record for the registrant, admin, technical, and billing roles, linked to one or more domains.
The extension model
New data and new object types attach through defined extensions, registered with IANA, so registries add policy without changing the base protocol.
Extensions: how registries add their own rules
Extensibility is more than a name. IANA maintains a registry of EPP extensions, the formal list of approved additions, which lets a registry layer in its own requirements, from registration data policy to launch-phase rules for a new TLD, while staying compatible with every registrar’s base implementation. A registrar that speaks core EPP can connect to a new registry and add only that registry’s extensions.
EPP status codes: what locks and unlocks a domain
EPP status codes are the labels on a domain that say what can and cannot be done to it. They come in two families: client codes set by the registrar and server codes set by the registry. A buyer reads them to know whether a name is locked, in a grace period, pending deletion, or free to transfer. ICANN documents the codes a registrant is likely to encounter.
Client codes versus server codes
According to ICANN’s published reference on EPP status codes, codes prefixed with client are set by the domain’s registrar, and codes prefixed with server are set by the registry. A registrar can apply and lift a client code itself. A server code is held at the registry and overrides the registrar, applied during disputes or for protected names. The prefix tells a buyer who has the power to change it.
The status codes that matter when acquiring a domain
For someone buying or transferring a name, a handful of codes decide whether the deal can proceed. The table below lists the ones that govern transferability and lifecycle, grounded in ICANN’s status-code documentation and the RFC 5731 domain mapping.
| Status code | Set by | What it means for a buyer |
|---|---|---|
| ok | Default | No restrictions are applied. The standard, unlocked state of a name with nothing pending. |
| clientTransferProhibited | Registrar | The registrar lock that blocks a transfer. It must be lifted before a domain can move to a new registrar. |
| serverTransferProhibited | Registry | A registry-level transfer block the registrar cannot remove. Common on protected or disputed names. |
| clientHold / serverHold | Registrar / Registry | The name is removed from DNS and will not resolve. A signal something is wrong or unpaid. |
| pendingTransfer | Registry | A transfer is in progress. The losing registrar has a window to approve or reject it. |
| pendingDelete | Registry | The name is scheduled for deletion and is heading toward the drop. Relevant to expired-domain buyers. |
| redemptionPeriod | Registry | The name has expired and sits in a recovery window before deletion, restorable by the prior registrant. |
These lifecycle codes connect directly to how an expired name moves toward becoming available. The pendingDelete and redemptionPeriod states are stages in the drop, a sequence covered in the expired domain fundamentals hub. Reading a name’s EPP status is the difference between a transfer that completes and one that stalls.
EPP the protocol vs the EPP code: the transfer authorization string
The pair this topic confuses above all others is EPP the protocol and the EPP code. They are not the same thing. EPP is the registrar-registry language. The EPP code, also called the authorization code, auth code, or auth-info, is a secret string tied to one domain that proves the right to transfer it. The code is a value exchanged through the protocol, not the protocol itself.
EPP the protocol
The Extensible Provisioning Protocol: the XML-over-TLS standard, defined in RFC 5730, that registrars and registries use to provision and manage all domains. A system, not a value.
The EPP code (auth code)
A per-domain secret string, the authorization information, that a buyer supplies to a new registrar to authorize a transfer. One password for one name, carried inside an EPP transfer request.
Why registrars call the auth code an EPP code
The authorization code is set on the domain object and transmitted in EPP transfer messages, which is why registrars label it the EPP code in their control panels. The name is shorthand for where the value lives. RFC 5731 defines the authInfo element on the domain object, and RFC 9154 later hardened how that authorization information is generated and used, so the secret is short-lived and unguessable instead of a static field.
How an inter-registrar transfer runs over EPP, step by step
A transfer is a defined EPP sequence. The losing registrar unlocks the name and releases the auth code, the buyer gives that code to the gaining registrar, and the gaining registrar sends an EPP transfer request carrying the code. The registry validates it, sets the pendingTransfer status, and the move completes after the losing registrar approves or a timeout passes. The step-by-step buyer view of that string is detailed in EPP code (auth code) explained, and the registrar-by-registrar differences in Registrar transfer policies compared.
The future: secure authorization, RESTful EPP, and RPP
EPP is stable but not frozen. RFC 9154, published in 2021, introduced a secure authorization-information model that makes the transfer code short-lived and harder to abuse. Separately, the registry community, through APNIC, AFNIC, and DENIC, is exploring a RESTful successor under the RPP name, a modern HTTP-based provisioning interface, while EPP remains the deployed worldwide standard.
RFC 9154 and secure transfer authorization
The original authorization model let a registrar set a static auth code that would sit unchanged for a domain’s life. RFC 9154 changed that, defining a secure model where the authorization information is set on demand, has a limited lifetime, and is not stored long term in plain form. For a buyer, this is why a registrar increasingly generates a fresh EPP code at transfer time instead of displaying a permanent one.
RESTful EPP and the RPP proposal
EPP predates the modern web-API era, and its XML-over-a-raw-TCP-session model is heavier than today’s HTTP interfaces. APNIC has published on a RESTful EPP direction, and AFNIC and DENIC have written about a Registration Provisioning Protocol, RPP, that would carry the same provisioning logic over REST. As of 2026 this is forward-looking standards work, not a replacement: EPP is what every registry and registrar runs in production.
EPP protocol frequently asked questions
The questions buyers and SEOs raise when they search for what the EPP protocol is, answered against the IETF standards and ICANN’s documentation.
Q1What does EPP stand for?
EPP stands for Extensible Provisioning Protocol. Extensible because new object types and data can be added through a defined extension mechanism. Provisioning because it manages the registration and lifecycle of domains. Protocol because it is a defined standard for how a registrar and a registry communicate, specified by the IETF in RFC 5730.
Q2Is the EPP code the same as the EPP protocol?
No, and this is the key distinction. The EPP protocol is the XML-based registrar-registry language defined in RFC 5730. The EPP code, also called the auth code or authorization code, is a per-domain secret string that authorizes a transfer. The code is a value carried inside an EPP transfer message. Registrars call it an EPP code because it travels on the EPP system, but the protocol and the code are different things.
Q3Is EPP an API?
EPP functions as a machine-to-machine interface, so it serves the same purpose as an API, but it predates modern REST conventions. It uses XML documents exchanged over a stateful TLS connection on port 700 instead of HTTP requests. The RPP and RESTful EPP work discussed by the registry community would bring provisioning closer to a conventional web API, but EPP itself is the older standard.
Q4What port does EPP use?
EPP uses TCP port 700, assigned by IANA, secured with TLS as specified in RFC 5734. The registrar acts as the client connecting to the registry server on that port. Buyers never connect to port 700 themselves, since they deal with the registrar’s front end, not the underlying provisioning channel.
Q5How do EPP status codes affect buying a domain?
EPP status codes tell a buyer whether a name can be transferred or is locked. A clientTransferProhibited code is a registrar lock that must be lifted before a move. A serverTransferProhibited code is a registry lock the registrar cannot remove. Lifecycle codes such as pendingDelete and redemptionPeriod show an expired name’s stage toward the drop. Reading these codes before a purchase prevents a stalled or impossible transfer.
EPP at the point of acquisition: transfers, locks, and the right domain
Every domain acquisition runs on EPP. The transfer command moves a name, the auth code authorizes it, and the status codes decide whether the move is even allowed. Understanding the protocol turns a buyer from someone hoping a transfer completes into someone who reads the signals. SEO Domains operates the curated marketplace where aged and expired domains are sourced and transferred through exactly this mechanism.
Why EPP is the mechanism behind every transfer
When a name moves from a seller to a buyer, nothing happens by hand. The losing registrar releases the EPP auth code and clears the clientTransferProhibited lock, the gaining registrar sends an EPP transfer request carrying that code, and the registry validates and completes it. The buyer’s experience is three or four clicks, but underneath, EPP is doing the work. Knowing that is knowing what to check before, during, and after a purchase.
What to check before acquiring a name
A clean acquisition reads the EPP signals first. The points below are the protocol-level checks that decide whether a transfer will complete smoothly:
- The status codes: the name should not carry serverTransferProhibited or a hold, and the registrar lock must be liftable.
- The auth code: a valid, current EPP code must be available, increasingly generated fresh at transfer time under RFC 9154.
- The lifecycle stage: for an expired name, the EPP status shows whether it is still in redemption, in pendingDelete, or fully available.
- The registry and registrar policy: transfer windows and grace periods differ, which is why provenance matters before money changes hands.
A name that passes these checks transfers cleanly. A name with a hidden server lock or a stale code stalls. Sourcing from inventory where the registration state has already been read removes that friction, which is the practical value of a screened catalogue over an unchecked drop list.
Source domains that transfer cleanly
The legitimate demand behind every EPP search is a name that lands in your account without friction. That is the product. SEO Domains operates the curated marketplace where aged and expired domains are screened across their backlink profiles, authority metrics, and registration state before they are listed, so the EPP transfer at the end is the easy part. Browse vetted aged and expired domains on the SEO Domains marketplace, sourced and transferred through the same registrar-registry protocol this guide explains.
