Por qué los accesos se recogen antes del primer cambio
El primer reflejo de una agencia que se hace cargo de un cliente es conectarse a algún sitio y corregir. Es también el momento en que más se rompe: un registro MX borrado por error corta el correo, un cambio de servidores de nombres hace desaparecer una zona que nadie exportó, una renovación falla porque el correo del titular ya no responde.
El cliente no siempre sabe dónde están sus accesos. El dominio lo compró un proveedor anterior, el DNS lo sirve un tercero, el hosting es un cPanel cuya contraseña duerme en un mensaje de hace dos años. La agencia conoce ese estado real tocando algo, que es el peor momento para conocerlo.
Una checklist de onboarding fija un orden sencillo: se releva el estado público, se exporta lo que se pueda, se obtienen solo los permisos necesarios, se registra todo y solo después se modifica. Cuando la cartera supera lo que una persona retiene en la cabeza, este ritual se convierte en la única memoria fiable de la agencia.
Lo que el inventario de accesos le ahorra
- El correo cortado — un registro MX, SPF o DKIM borrado o sobrescrito sin copia previa interrumpe el correo del cliente en una hora.
- La zona perdida — cambiar de servidores de nombres sin exportar la zona completa hace desaparecer subdominios que nadie recordaba.
- El dominio caducado — el titular inscrito es un proveedor anterior y los avisos de renovación van a una dirección muerta.
- La transferencia bloqueada — un bloqueo activo o un correo de contacto inválido impide validar una transferencia justo cuando la necesita.
- El acceso demasiado amplio — una contraseña root enviada por correo sigue siendo válida años después de acabar el encargo.
- El expediente inencontrable — sin una tabla de accesos, nadie más en la agencia puede retomar al cliente durante una ausencia.
Quién es propietario: el cliente sigue siendo titular y la agencia recibe accesos delegados
La objeción reaparece en cada onboarding: quién lleva la relación y quién es dueño del dominio. La respuesta es la misma para todos los clientes. El cliente sigue siendo titular del dominio, es el registrante inscrito, y la agencia recibe accesos delegados. Usted gestiona la relación y las operaciones corrientes; la infraestructura de hosting corresponde a la plataforma; el cliente conserva la propiedad de lo que lleva su nombre.
Este reparto protege a ambas partes. Si el encargo termina, el cliente se va con su dominio sin negociar. Si el cliente cambia de interlocutor, la agencia no responde de un nombre que nunca poseyó.
Queda el argumento que oirá: pedir accesos parece pesado. Responda con una lista mínima y un mensaje tipo (más abajo). Pida solo lo que el encargo necesita, capa por capa, con el permiso más bajo que baste. La tabla siguiente sirve de base.
Nivel de permisos que hay que pedir por capa
Desplace la tabla
| Capa | Permiso que pedir | Forma de transmisión |
|---|---|---|
| Registrador | Acceso delegado o contacto técnico, lectura del estado, desbloqueo puntual para una transferencia | Invitación desde la consola del registrador, nunca la cuenta compartida del cliente |
| Zona DNS | Edición de registros y exportación completa de la zona | Cuenta nominativa en el proveedor DNS, o delegación de zona |
| Hosting cPanel / WHM | Cuenta cPanel del sitio; WHM solo si la agencia administra el servidor | Usuario dedicado, contraseña en el gestor compartido |
| Buzones de correo | Acceso de administrador a la consola de correo, sin leer los buzones | Cuenta admin dedicada, nunca la contraseña de un buzón personal |
| Aplicación (CMS) | Cuenta de administrador nominativa | Creación de una cuenta a nombre del colaborador |
| Contacto de renovación | Dirección de contacto leída por la agencia, medio de pago en manos del cliente | Alias de grupo en lugar de una dirección individual |
| Copias de seguridad | Acceso a la última copia completa | Enlace o almacenamiento cifrado, de duración limitada |
Relevar el estado real antes de tocar nada
Antes de pedir una sola contraseña ya puede leer mucho de forma pública. Ejecute estos comandos desde su equipo y guarde la salida en un archivo con fecha: es su estado de referencia.
dig +short NS example.com devuelve los servidores de nombres que sirven la zona, normalmente de dos a cuatro líneas. Indican quién lleva el DNS, que puede ser distinto del registrador. dig +short A example.com devuelve la dirección IP del sitio: compárela con el hosting que el cliente dice usar. dig +short MX example.com devuelve una prioridad seguida de un nombre de servidor; una respuesta vacía significa que ningún correo se enruta por este dominio.
dig +short TXT example.com muestra el registro SPF, que empieza por v=spf1, y los tokens de verificación de servicios de terceros. La política DMARC se lee con dig +short TXT _dmarc.example.com. Una clave DKIM se lee con dig +short TXT selector._domainkey.example.com, pero hay que conocer el selector: aparece en la cabecera de un mensaje enviado por el cliente.
Después, whois example.com da el registrador, la fecha de expiración y los estados. Para una extensión .ma la salida pública es más limitada: la documentación de la ANRT es la referencia, y no debe suponerse que siga las reglas de un .com.
La checklist de onboarding, paso a paso
Identificar al titular y al registrador
Pida al cliente el nombre del titular del dominio y el registrador donde se compró, antes de cualquier acceso. Anote la respuesta aunque sea aproximada: se comparará con el whois.
Relevar el DNS público
Ejecute
dig +short NS,A,MXyTXTsobre el dominio, y luego_dmarcen TXT. Guarde la salida sin editar en un archivo con la fecha del día.Relevar el whois
Ejecute
whois example.comy copie el registrador, la fecha de expiración, los estados y el correo de contacto. Compárelo con lo que dijo el cliente.Exportar la zona completa
Desde la consola del proveedor que sirve la zona, expórtela entera. Una transferencia de zona AXFR casi siempre se rechaza, así que la exportación pasa por la interfaz. Guarde aparte una captura de los registros MX, SPF, DKIM y DMARC.
Pedir los accesos por capa, con el permiso mínimo
Tome la tabla de permisos y pida solo lo que el encargo exige: registrador, DNS, hosting, correo, aplicación.
Hacer que se transmitan sin contraseñas en claro
Cree una bóveda por cliente en un gestor de contraseñas compartido y haga depositar ahí los accesos. Active la doble autenticación en cada cuenta nominativa.
Probar cada acceso en solo lectura
Conéctese a cada capa, compruebe que el acceso funciona y desconéctese sin modificar nada. Anote la fecha de la prueba.
Registrar y planificar los vencimientos
Rellene la tabla resumen y traslade las fechas de expiración a su seguimiento de renovaciones. En el espacio de agencia de ServOrbit.com, la vista de cartera centraliza estos vencimientos.
Leer el whois: bloqueo, titular y correo de contacto
El whois contiene cuatro datos que deciden lo que sigue. El primero es el registrador, que dice dónde vive realmente el dominio. El segundo es la fecha de expiración: un dominio cercano al vencimiento pasa por delante de todo lo demás.
El tercero es el estado. clientTransferProhibited es el bloqueo de transferencia: el registro rechaza cualquier solicitud de mover el dominio a otro registrador. Es normal y protector, pero hay que pedir al registrador que lo retire antes de una transferencia. clientUpdateProhibited bloquea las modificaciones. clientHold detiene la resolución DNS, y redemptionPeriod o pendingDelete señalan un dominio en proceso de eliminación: es una urgencia, no un punto de onboarding. La definición de cada estado la publica ICANN.
El cuarto es el titular y su correo de contacto. Si el titular es un proveedor anterior o un empleado que se fue, anótelo: el cliente debe regularizarlo. Un correo de contacto muerto impide validar una transferencia o una renovación, porque los mensajes de confirmación van a una dirección que nadie lee. El código de transferencia no aparece en el whois: se pide al registrador, y la política de transferencia de ICANN enmarca las reglas aplicables.
Transmisión de los accesos
Ninguna contraseña por correo, mensajería instantánea ni en un ticket. Use una bóveda compartida, una cuenta nominativa por colaborador y doble autenticación, y revoque cada acceso al terminar el encargo. Un acceso sin fecha de fin se convierte en deuda de seguridad.
El mensaje tipo para enviar al cliente
El mensaje debe ser corto y previsible. Aquí tiene un modelo para adaptar: «Hola, para empezar el encargo necesitamos cinco elementos: el nombre del titular de su dominio, el acceso a la gestión del dominio en su registrador, el acceso a la zona DNS, el acceso al hosting y el de la consola de correo. Solo pedimos el permiso necesario en cada capa y le proponemos depositar los accesos en una bóveda compartida que creamos a su nombre. Usted sigue siendo titular del dominio y no modificamos nada antes de haber relevado y exportado lo existente.»
Este texto dice qué se pide, por qué, cómo transmitirlo y qué conserva el cliente. Responde a la objeción antes de que se formule. Envíelo con el enlace a su bóveda, no con los accesos en sí.
Tabla resumen de accesos
Desplace la tabla
| Capa | Propietario y permiso concedido | Fecha y vencimiento |
|---|---|---|
| Registrador | Cliente titular; acceso delegado de lectura y desbloqueo | Concedido el DD/MM; revisión en la renovación |
| Zona DNS | Proveedor DNS; edición y exportación | Concedido el DD/MM; cuenta nominativa |
| Hosting cPanel | Agencia; cuenta del sitio, sin acceso root | Concedido el DD/MM; termina con el encargo |
| Correo | Cliente; consola admin, buzones sin leer | Concedido el DD/MM; termina con el encargo |
| Aplicación (CMS) | Cliente; cuenta de administrador a nombre del colaborador | Concedido el DD/MM; termina con el encargo |
| Contacto de renovación | Agencia; alias de grupo | Actualizado el DD/MM; vencimiento del dominio registrado |
Solución de problemas: los errores que reaparecen en el onboarding
status: NXDOMAIN en la salida de dig significa que el nombre no existe en el DNS público. Compruebe primero la ortografía y luego el whois: un dominio caducado o en clientHold responde así. El remedio está en el registrador, no en la zona.
status: SERVFAIL indica casi siempre servidores de nombres inalcanzables o un DNSSEC roto. Repita con dig +cd example.com: si la respuesta vuelve con esa opción, la causa es la validación DNSSEC y hay que revisar el registro DS en el registrador.
Un whois que responde No match for indica un nombre no registrado, o una extensión que su cliente whois no sabe consultar. Pruebe el servicio whois del registro correspondiente antes de concluir.
Un inicio de sesión cPanel rechazado con la contraseña correcta suele venir del cortafuegos del hosting, que bloquea la IP de la agencia tras algunos intentos fallidos, o de una cuenta suspendida. Pida al proveedor que levante el bloqueo y no multiplique los intentos.
Por último, una transferencia rechazada cuando todo parece listo remite casi siempre a clientTransferProhibited aún activo, o a un correo de contacto que no recibe la confirmación.
Convertir la checklist en un gesto de rutina
El valor de esta lista viene de su repetición. Guárdela en su base de conocimiento, versiónela y aplíquela igual a cada cliente, incluido el que parece simple. Tras una decena de onboardings, los pasos se vuelven reflejo y la tabla de accesos pasa a ser la primera página del expediente del cliente.
Una vez registrados los accesos, el seguimiento de vencimientos toma el relevo: el artículo sobre la gestión de renovaciones de dominios de clientes describe las alertas que hay que poner, y el de la migración de un sitio WordPress detalla lo que sigue cuando el cliente cambia de proveedor. Para elegir entre hosting compartido y VPS, el último artículo enlazado compara ambos según el perfil del sitio.
Recuerde el orden: relevar, exportar, pedir el permiso mínimo, probar en lectura, registrar y solo después modificar.
