El dominio es el nombre. El hosting es la máquina que responde. Juntarlos en la misma cuenta parece pereza; partirlos sin querer es cómo se pierde el correo un lunes. El síntoma tiene nombre de red: split brain de MX. La web ya apunta al plan nuevo; el MX sigue en el viejo —o al revés, la zona nueva publicó un MX vacío y las facturas cayeron en un buzón que nadie abre. En Conexcol puedes tener dominio y sitio elástico en el mismo portal. Cuando puedas, déjalos juntos.
Esto no es «nunca separes». Google Workspace y Microsoft 365 existen. Es: sepáralos a propósito, con la zona a la vista, no porque el registrador barato y el hosting barato salieron en facturas distintas. El mapa de líneas —sitio elástico, cloud, cluster, Windows— está en sitios elásticos, cloud, cluster o Windows. Elegir origen: cómo elegir hosting en Colombia.
Qué vas a tener al terminar
Qué hace el registrador, qué hace el hosting, qué es un nameserver y qué es un MX. Cuándo conviene una sola cuenta. Cuándo sí partir. Y el orden para no partir el correo el día de la mudanza.
Dos productos, dos facturas (aunque salgan juntas)
El dominio se registra (o se transfiere) en un registrador. Pagas el derecho a usar tudominio.com.co. Ahí se cambian los nameservers: quién tiene autoridad sobre la zona. El hosting es disco, PHP, correo, bases, SSL. En Conexcol, Cloud Web Hosting trae cPanel y una zona DNS lista cuando los nameservers apuntan aquí. Puedes registrar el dominio con nosotros al contratar, o traer uno que ya existe. El carrito: Cloud Web Hosting. Cómo se agrega un nombre en el panel: añadir dominio y subdominio en cPanel.
Transferir el .co o el .com.co es otro trámite (código EPP, desbloqueo, 60 días). Eso no mueve archivos. Artículo: transferir un dominio .co o .com.co. Cambiar de hosting sin transferir el dominio es lo normal: solo cambias DNS. Mezclar las dos mudanzas el mismo día es el clásico.
Nameservers, zona, A y MX
Los nameservers dicen dónde está el cuaderno. La zona es el cuaderno: registros A (IPv4 del web), AAAA si hay, CNAME, MX (correo), TXT (SPF, DKIM, verificación de Google). Si apuntas los NS al hosting, cPanel es el cuaderno. Si los dejas en el registrador o en un DNS de terceros, el cuaderno está allá y el hosting solo recibe lo que el A le mande. El gesto en cPanel: registros DNS en cPanel. Qué son los NS: qué es el DNS y cómo cambiar nameservers.
TTL es cuánto cachean los resolvers ese cuaderno. Un TTL de un día hace que un cambio de A se sienta eterno. Bájalo el día anterior a una mudanza. Detalle: TTL, registro A y CNAME. www o sin www: elige uno y redirige el otro; no dejes dos casas canónicas.
El lío: split brain de MX
Split brain, aquí, no es un cluster. Es que dos zonas distintas creen ser la verdad del mismo nombre. Caso típico: cambias NS al hosting nuevo. El hosting publica una zona por default: A a la IP nueva (bien) y MX a tudominio local (mal, si el correo vivía en Workspace o en el origen). Durante horas, según el resolver, unos clientes entregan al Google y otros al buzón vacío del cPanel nuevo. Nadie «hackeó» nada. Tú publicaste dos historias.
El otro sentido: la web ya está en Conexcol (A nuevo, probado por hosts) y alguien cambia solo el A en una zona vieja, pero un CNAME o un MX huérfano sigue al origen. Formularios que envían por SMTP local fallan. SPF del TXT viejo no cubre la IP nueva. Gmail te manda a spam el día que más necesitas el correo. SPF/DKIM: SPF, DKIM y DMARC.
Cuándo sí separarlos (a propósito)
Correo en Google Workspace o Microsoft 365, web en el hosting: es un patrón sano. Los NS pueden quedarse en Conexcol; en la zona, MX y TXT apuntan a Google, A apunta al sitio elástico. Receta: apuntar el correo a Google Workspace. Cuándo cada uno: Google Workspace o el correo del hosting.
Otro caso: la empresa ya tiene un DNS corporativo (Cloudflare, un Active Directory con split DNS interno, un proveedor que no vamos a nombrar). Entonces el hosting no debe «robarse» los NS. Pides la IP, publicas el A allá, y el correo se toca en ese mismo cuaderno. El ticket de Conexcol no puede editar una zona que no vive aquí; eso no es un fallo del LVE, es el diseño que elegiste.
Cuándo dejarlos juntos
Pyme, agencia, un WordPress, correo @tudominio en Roundcube, nadie de sistemas en nómina: una cuenta, un portal, un huso. Renuevas dominio y hosting en el mismo lugar. El soporte ve la zona y el disco. AutoSSL encuentra el nombre. JetBackup cubre archivos y, según el plan, correo. Desde 1999 ese es el paquete que menos tickets de «se partió el MX» genera. No es romanticismo: es menos superficies de login y menos TTL ajenos.
El hosting Linux de esta línea es sitio elástico (cPanel, LVE, LiteSpeed), no un pasillo sin techo. Windows con Plesk es la otra fila. Requisitos WordPress: siete requisitos. Latencia del visitante en Bogotá: latencia en Colombia.
Mudanza: el orden para no partir el cerebro del MX
- Contrata el hosting. No toques NS.
- Copia el sitio. Prueba por
hosts. Checklist: cómo cambiar de hosting. Si es WordPress: migrar WordPress. - Inventario de MX, TXT, CNAME. Captura de pantalla de la zona vieja.
- Si el correo se muda al hosting nuevo: recrea buzones antes de NS. Si el correo se queda en Workspace: la zona nueva debe nacer con esos MX, no con el default.
- NS o A, al final. Mira bandejas desde fuera de la oficina.
- No canceles el origen ni el dominio viejo el mismo día.
Si no quieres armar esa tabla un sábado, abre un ticket de migraciones. Nosotros copiamos; tú decides si el MX se mueve o se queda. Landing: migrar a Conexcol.
Contratar Cloud Web Hosting · /hosting/ · /cloud/ · /hosting/cluster/ · Windows · DNS y nameservers · ticket
