Nel lavoro digitale il dominio non è un dettaglio amministrativo: è spesso il punto in cui si incrociano identità del brand, posta aziendale e continuità operativa. Qui chiarisco che cosa indica davvero EPP nel contesto dei domini, perché molti lo confondono con il codice di autorizzazione e come leggere correttamente i blocchi o gli stati che possono rallentare un trasferimento. Per un’impresa, capire questi passaggi significa evitare fermi inutili, errori di configurazione e dipendenze tecniche poco visibili.
In breve, EPP riguarda protocollo, autorizzazione e stato del dominio
- EPP significa Extensible Provisioning Protocol, lo standard usato da registrar e registry per gestire i domini.
- Nel linguaggio comune, però, molti chiamano “codice EPP” il codice AuthInfo o Auth-Code usato per i trasferimenti.
- I codici di stato EPP dicono se un dominio è libero, bloccato o in lavorazione.
- Per i domini .it l’Authinfo è un valore alfanumerico di 8-32 caratteri e il registrar deve comunicarlo al registrante.
- Il trasferimento non si blocca quasi mai per un solo motivo: di solito c’entrano status, contatti o conferme mancanti.
Che cosa indica davvero EPP nel mondo dei domini
Quando si parla di domini, EPP non è un semplice acronimo tecnico da pannello di controllo. È il protocollo che permette a registrar e registry di scambiarsi richieste strutturate per registrare, aggiornare, trasferire o cancellare un nome a dominio. Nella mia lettura pratica, è il livello “di macchina” che sta sotto l’interfaccia che vede il cliente: l’utente clicca un pulsante, ma dietro c’è uno scambio EPP.
In termini semplici, il protocollo mette ordine tra le operazioni, perché ogni richiesta ha una forma precisa e un significato preciso. RFC 5730 lo definisce come un protocollo client-server applicativo per la gestione di oggetti in un repository condiviso; per i domini questo vuol dire che il registrar non inventa il flusso, ma si appoggia a uno standard comune.
| Elemento | Cosa significa | Dove lo incontri |
|---|---|---|
| Protocollo EPP | Lo standard tecnico per gestire oggetti come domini e contatti | Nei sistemi di registrazione, nei backend dei registrar e nei registry |
| AuthInfo / Auth-Code | Il codice di autorizzazione legato al dominio | Quando chiedi un trasferimento o una modifica che richiede conferma |
| Stati EPP | I flag che descrivono il blocco o la fase operativa del dominio | In WHOIS, nei pannelli registrar e nei controlli di migrazione |
Io distinguo sempre questi tre livelli, perché è qui che nascono gli equivoci: chi chiede “l’EPP” spesso non sta chiedendo il protocollo, ma il codice che sblocca il passaggio verso un altro provider. Da qui nasce la confusione più comune, e il passaggio successivo serve proprio a separare le due cose.
Perché il codice AuthInfo viene spesso chiamato codice EPP
Nel mercato dei domini, soprattutto in Italia, Authinfo è il nome più corretto per il codice che identifica il dominio e consente operazioni specifiche. Il Registro .it lo descrive come un codice alfanumerico comunicato dal registrar al registrante; nelle linee tecniche il campo domain:authInfo è la password di autorizzazione per certe operazioni sul nome a dominio e, per il ccTLD .it, la lunghezza varia da 8 a 32 caratteri.
In ambito gTLD, ICANN usa spesso termini come Auth-Code, Auth-Info Code o transfer code. Il punto pratico è lo stesso: quel codice serve a identificare il titolare e a prevenire trasferimenti non autorizzati. Se il registrar non offre una gestione autonoma del codice, ICANN prevede che lo renda disponibile entro 5 giorni di calendario dalla richiesta del registrante.
Vale la pena chiarire anche ciò che non è questo codice:
- non è la password dell’account del registrar;
- non è il nome dei server DNS;
- non sblocca da solo il dominio se esiste un lock attivo;
- non è un dettaglio puramente burocratico, perché incide sulla portabilità del dominio.
Secondo il Registro .it, il registrar deve comunicare al registrante anche l’eventuale nuovo Authinfo quando lo modifica. È un obbligo importante, perché il codice non è un segreto da tenere in una pratica interna: è una chiave operativa che il titolare deve poter usare quando cambia fornitore o gestore tecnico. Da qui si capisce perché il trasferimento abbia bisogno di un flusso ordinato, non di una semplice e-mail con un codice allegato.
Quando questo punto è chiaro, diventa molto più leggibile anche il trasferimento vero e proprio, che è il passaggio più delicato per chi gestisce un sito o un’infrastruttura di posta.
Come si muove un dominio da un registrar all’altro
Il trasferimento di un dominio sembra spesso un’operazione di routine, ma in pratica funziona bene solo se alcuni passaggi sono in ordine. Nei flussi gestiti da ICANN, il registrar ricevente deve ottenere l’autorizzazione del titolare, mentre il registry verifica la validità dell’AuthInfo prima di accettare la richiesta. Se il registrar uscente non risponde entro 5 giorni di calendario, la policy prevede in genere un’approvazione automatica del trasferimento.
- Controllo iniziale: verifico che il dominio non sia in uno stato che blocca il passaggio e che i contatti del registrante siano ancora raggiungibili.
- Recupero del codice: richiedo l’AuthInfo o Auth-Code al registrar attuale, oppure lo recupero dal pannello se è disponibile in autonomia.
- Apertura della pratica: avvio il trasferimento presso il nuovo registrar e confermo l’autorizzazione del titolare.
- Verifica di sicurezza: se compare un lock, lo rimuovo prima di procedere; se il dominio ha limiti specifici, li tratto prima del trasferimento.
- Conferma finale: aspetto la risposta del registry e controllo che DNS, posta e rinnovi siano allineati dopo il passaggio.
Un dettaglio che spesso viene ignorato: in diversi gTLD il trasferimento completato comporta un’estensione di un anno della registrazione, pur con un limite complessivo di 10 anni di durata residua. E ICANN ricorda anche che un dominio scaduto non è automaticamente “fermo” al trasferimento; il blocco dipende dalle regole del singolo caso, non solo dalla data di scadenza.
Se il processo è lineare, il cambio di provider si chiude in tempi ragionevoli. Se invece qualcosa si inceppa, quasi sempre il problema non è il protocollo EPP in sé ma uno stato di blocco o una conferma non completata. È qui che entrano in gioco i codici di stato.
Quali stati bloccano o rallentano una pratica
I codici di stato EPP servono a descrivere con precisione cosa sta succedendo al dominio. Per un tecnico o un responsabile digitale sono utilissimi, perché spiegano se il dominio è trasferibile, se è in attesa di elaborazione o se richiede un intervento del registrar. ICANN li usa proprio per rendere leggibile lo stato della registrazione.
| Stato | Effetto pratico | Cosa fare |
|---|---|---|
| clientTransferProhibited | Il registrar blocca il trasferimento verso un altro provider | Chiedere lo sblocco al registrar che gestisce il dominio |
| serverTransferProhibited | Il blocco arriva dal registry ed è più forte del precedente | Passare dal registrar per capire come intervenire lato registry |
| pendingTransfer | La richiesta di trasferimento è già in lavorazione | Attendere l’esito o verificare se serve una conferma |
| clientUpdateProhibited | Gli aggiornamenti sul dominio sono temporaneamente bloccati | Rimuovere il lock prima di modificare dati o configurazioni |
| redemptionPeriod | Il dominio è in fase di recupero dopo una cancellazione | Segui la procedura di restore, se prevista dal registry |
La differenza più utile, per chi lavora sul campo, è tra stati client e stati server. I primi di solito si gestiscono con il registrar; i secondi segnalano una restrizione più strutturale, spesso legata al registry o a una protezione particolare. Se il trasferimento si ferma, quindi, la domanda non dovrebbe essere “perché EPP non funziona?”, ma “chi ha imposto il blocco e con quale logica?”.
Questa distinzione è importante anche per le aziende, perché un dominio bloccato non è soltanto un problema tecnico: può diventare un problema di continuità di business, di posta e di reputazione online.
Perché questo dettaglio conta per un'impresa digitale
Nel contesto aziendale il dominio è un asset operativo, non un accessorio. Regge il sito, i sottodomini, le campagne, gli indirizzi e-mail e spesso anche parte dell’identità pubblica dell’impresa. Se il controllo su EPP, Authinfo e stati di blocco è debole, il risultato non è solo un trasferimento più lento: può esserci un ritardo nel rebranding, nel cambio di fornitore o nella migrazione di servizi critici.
Io vedo tre casi in cui questa materia pesa davvero:
- migrazioni di provider, quando un’azienda vuole lasciare un fornitore e portare con sé dominio e posta;
- operazioni straordinarie, come fusioni, acquisizioni o ristrutturazioni;
- governance del portafoglio, quando si gestiscono più domini, mercati o brand e serve un controllo centralizzato.
Ci sono anche effetti meno visibili ma concreti: se il dominio governa la posta aziendale, un errore di trasferimento può rallentare le conferme, i reset password e perfino i flussi di lead. In altre parole, l’acronimo EPP sembra piccolo, ma tocca punti molto sensibili della catena digitale.
Quando una squadra marketing o IT tratta bene questa parte, il dominio diventa un elemento di fiducia e non un collo di bottiglia. E prima di chiedere un trasferimento, ci sono alcune verifiche che io farei sempre, senza eccezioni.
Le verifiche che farei prima di chiedere il trasferimento
Prima di aprire una pratica, conviene fare un controllo essenziale e molto concreto. Nella pratica, questi passaggi evitano la maggior parte dei rallentamenti e riducono il rischio di ritrovarsi con una richiesta sospesa per un dettaglio banale.
- Controllare chi è il registrar attuale e chi ha accesso al pannello amministrativo.
- Verificare lo stato EPP del dominio e rimuovere eventuali lock che bloccano il passaggio.
- Recuperare o richiedere l’AuthInfo prima di avviare la procedura.
- Confermare che l’e-mail del registrante o del contatto autorizzato sia ancora attiva e presidiata.
- Esportare o annotare la configurazione DNS, soprattutto se il sito usa record personalizzati, MX o DNSSEC.
- Pianificare il trasferimento in una finestra di basso traffico, così da limitare gli effetti di eventuali ritardi.
Se questi punti sono chiari, EPP smette di essere un acronimo opaco e diventa quello che è davvero: un meccanismo di controllo, sicurezza e portabilità. Nella mia esperienza, quasi mai il problema è il protocollo in sé; molto più spesso è un lock dimenticato, un contatto non più valido o un codice non recuperato in tempo. Curare questi aspetti significa gestire il dominio come un’infrastruttura strategica, non come una voce secondaria di amministrazione.
