Academia Web

Tema

Escenarios reales ​

La teoría ya la tienes. Ahora, recetas: los ocho casos que vas a encontrar una y otra vez con clientes reales. Cada uno trae los pasos en orden y la tabla exacta de registros que debe quedar en Cloudflare. Guárdala como referencia: cuando un cliente te diga "tengo mi dominio en GoDaddy y el correo en Google", vas a saber qué hacer en 20 minutos.

En todas las tablas:

  • 🟠 = Proxied (nube naranja), ⚪ = DNS only (nube gris), — = el tipo de registro no tiene proxy.
  • @ = mitienda.com. Los valores p=MIIB... y los códigos de verificación son ejemplos: copia siempre los que te dé tu proveedor.
  • Hosting cPanel actual: 203.0.113.10. Nameservers de Cloudflare: ana.ns.cloudflare.com y bob.ns.cloudflare.com.

Concepto: la receta universal ​

Todos los escenarios siguen el mismo esqueleto:

txt
1. INVENTARIO   → ¿Dónde está el dominio? ¿el sitio? ¿el correo? ¿qué registros existen hoy?
2. PREPARAR     → Zona completa en Cloudflare ANTES de mover nameservers. Bajar TTL si habrá cambios de IP.
3. CAMBIAR      → Nameservers en el registrador (o registros puntuales).
4. VERIFICAR    → dig / Resolve-DnsName, abrir el sitio, enviar y recibir correo, revisar SSL.
5. ASEGURAR     → Full (strict), Always Use HTTPS, SPF/DKIM/DMARC, documentar.

Si te saltas el paso 1, tarde o temprano romperás el correo de alguien.

Escenario 1: GoDaddy + hosting cPanel + Cloudflare + correo del hosting ​

El caso más común en México y Latinoamérica: dominio comprado en GoDaddy, hosting compartido con cPanel, buzones ventas@mitienda.com en el mismo hosting.

Pasos

  1. En cPanel → Zone Editor, exporta o copia todos los registros. En Email Deliverability (Entregabilidad del correo), copia el registro DKIM y el SPF sugerido.
  2. Agrega mitienda.com en Cloudflare (plan Free) y compara la zona importada con la original (ver Cloudflare desde cero).
  3. Ajusta la nube de cada registro según la tabla.
  4. GoDaddy → Dominio → DNS → Servidores de nombres → Cambiar → "Usaré mis propios servidores" → ana.ns.cloudflare.com, bob.ns.cloudflare.com. Si GoDaddy tenía DNSSEC, desactívalo antes.
  5. Cuando Cloudflare diga Active: SSL/TLS en Full (strict) (AutoSSL ya da el certificado del origen) y Always Use HTTPS.
  6. En cPanel → Email Routing (Enrutamiento de correo): deja Local Mail Exchanger (el correo vive en este servidor).

Zona final

txt
Tipo   Nombre                Contenido                                   Proxy  Prioridad
────────────────────────────────────────────────────────────────────────────────────────
A      @                     203.0.113.10                                🟠
CNAME  www                   mitienda.com                                🟠
A      mail                  203.0.113.10                                ⚪
A      webmail               203.0.113.10                                ⚪
A      cpanel                203.0.113.10                                ⚪
A      ftp                   203.0.113.10                                ⚪
A      autodiscover          203.0.113.10                                ⚪
A      autoconfig            203.0.113.10                                ⚪
MX     @                     mail.mitienda.com                           —      0
TXT    @                     v=spf1 ip4:203.0.113.10 mx ~all             —
TXT    default._domainkey    v=DKIM1; k=rsa; p=MIIBIjANBgkqh...          —
TXT    _dmarc                v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com   —
SRV    _autodiscover._tcp    0 0 443 cpanelemaildiscovery.cpanel.net     —

El SPF con Cloudflare

No uses +a en el SPF: con @ en naranja, a apunta a IPs de Cloudflare. Usa ip4: con la IP de salida del correo (en cPanel → Email Deliverability aparece; a veces es distinta a la del sitio). Detalles en SPF.

Escenario 2: igual, pero el correo en Google Workspace ​

El sitio sigue en cPanel, pero los buzones son de Gmail empresarial (Google Workspace).

Pasos

  1. En la consola de Google (admin.google.com) agrega el dominio y obtén el TXT google-site-verification=....
  2. En Cloudflare crea la tabla de abajo. Borra el MX viejo que apuntaba a mail.mitienda.com (si conviven MX de cPanel y de Google, la mitad del correo se va a cada lado).
  3. Activa DKIM en Google: Apps → Google Workspace → Gmail → Autenticar correo electrónico → Generar registro (2048 bits) → crea el TXT google._domainkey → vuelve y pulsa Iniciar autenticación.
  4. Paso que casi todos olvidan: en cPanel → Email Routing elige Remote Mail Exchanger. Si lo dejas en "Local", los correos que el sitio web envíe a ventas@mitienda.com (formularios de contacto, pedidos de WooCommerce) se entregan en el buzón local de cPanel, que nadie revisa, y nunca llegan a Gmail.
  5. Si el sitio envía correos (formularios) desde el hosting, incluye la IP del hosting en el SPF, o mejor, configura el sitio para enviar por SMTP de Google.

Zona final

txt
Tipo   Nombre              Contenido                                                 Proxy  Prioridad
──────────────────────────────────────────────────────────────────────────────────────────────────
A      @                   203.0.113.10                                              🟠
CNAME  www                 mitienda.com                                              🟠
A      cpanel              203.0.113.10                                              ⚪
A      ftp                 203.0.113.10                                              ⚪
MX     @                   smtp.google.com                                           —      1
TXT    @                   google-site-verification=a1B2c3D4e5...                    —
TXT    @                   v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all      —
TXT    google._domainkey   v=DKIM1; k=rsa; p=MIIBIjANBgkqh...                        —
TXT    _dmarc              v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com           —
CNAME  correo              ghs.googlehosted.com                                      ⚪   (opcional: correo.mitienda.com abre Gmail)

¿Un MX o cinco?

Las configuraciones antiguas de Google usaban cinco MX (aspmx.l.google.com prioridad 1, alt1... 5, etc.). Desde 2023 Google recomienda un solo smtp.google.com con prioridad 1. Ambas funcionan; no mezcles las dos. Ver MX y cómo funciona el correo.

Escenario 3: sitio en Vercel o Netlify + correo en Zoho ​

Proyecto en Next.js/Astro desplegado en Vercel (o Netlify), correo gratuito o barato con Zoho Mail. No hay hosting cPanel.

Pasos

  1. En Vercel: proyecto → Settings → Domains → Add → mitienda.com (y www). Vercel te muestra los registros exactos (pueden ser específicos de tu proyecto).
  2. En Zoho Mail: agrega el dominio, crea el TXT de verificación, luego los MX, SPF y DKIM que Zoho indique (el selector DKIM lo eliges tú, por ejemplo zmail).
  3. Pon los registros de Vercel/Netlify en nube gris: estas plataformas ya tienen su propia CDN y emiten su propio certificado; con el proxy de Cloudflare encima, la emisión del certificado y la caché pueden fallar, y ambas plataformas recomiendan no proxear.

Zona final (Vercel)

txt
Tipo   Nombre             Contenido                                         Proxy  Prioridad
─────────────────────────────────────────────────────────────────────────────────────────
A      @                  76.76.21.21    (o la IP que muestre tu panel)     ⚪
CNAME  www                cname.vercel-dns.com  (o el que muestre)          ⚪
TXT    @                  zoho-verification=zb12345678.zmverify.zoho.com    —
MX     @                  mx.zoho.com                                       —      10
MX     @                  mx2.zoho.com                                      —      20
MX     @                  mx3.zoho.com                                      —      50
TXT    @                  v=spf1 include:zohomail.com ~all                  —
TXT    zmail._domainkey   v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3...             —
TXT    _dmarc             v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com   —

Variante Netlify: CNAME @ misitio.netlify.app ⚪ (Cloudflare permite CNAME en la raíz gracias al CNAME flattening) y CNAME www misitio.netlify.app ⚪. Ver CNAME y el apex.

Zoho tiene regiones

Si tu cuenta de Zoho está en el centro de datos de Europa o India, los MX son mx.zoho.eu o mx.zoho.in. Copia los valores de tu panel de Zoho, no de un tutorial.

Escenario 4: migrar de un hosting a otro sin perder correo ni tener caída ​

mitienda.com se muda del hosting viejo (203.0.113.10) a uno nuevo (203.0.113.50), ambos con cPanel, correo incluido.

La ventaja de Cloudflare: los registros en naranja cambian casi al instante para los visitantes, porque ellos siempre ven las IPs de Cloudflare; solo Cloudflare necesita saber la IP nueva. Los registros en gris (el correo) sí dependen del TTL.

Línea de tiempo

txt
Día -2   Bajar TTL a 5 min (300 s) en todos los registros GRISES (mail, ftp...).
Día -1   Hosting nuevo: restaurar respaldo completo (archivos, BD, buzones vacíos con las mismas cuentas).
         Instalar certificado en el nuevo origen (Origin Certificate de Cloudflare: no necesita DNS).
         Probar el sitio nuevo con el archivo hosts (ver abajo).
Día 0    (horario de poco tráfico)
         1. Poner el sitio viejo en modo mantenimiento o congelar cambios (pedidos, comentarios).
         2. Copiar la base de datos final al hosting nuevo.
         3. Cloudflare: cambiar A @ (y lo que apunte al hosting) a 203.0.113.50.
         4. Cambiar A mail → 203.0.113.50, actualizar SPF (ip4:203.0.113.50) y DKIM (¡clave nueva del cPanel nuevo!).
         5. Probar: sitio, formularios, enviar y recibir correo.
Día 0–2  Migrar el contenido de los buzones viejos (herramienta del hosting o imapsync).
Día +14  Cancelar el hosting viejo. Subir TTL de nuevo a Auto / 1 h.

Probar el servidor nuevo antes del cambio (archivo hosts)

txt
# Windows: C:\Windows\System32\drivers\etc\hosts  (abrir el Bloc de notas como administrador)
# Mac/Linux: /etc/hosts
203.0.113.50   mitienda.com
203.0.113.50   www.mitienda.com

Tu computadora irá directo al servidor nuevo (saltándose Cloudflare). Al terminar, borra esas líneas.

Cambios en la zona

txt
ANTES                                            DESPUÉS
A    @                 203.0.113.10   🟠          A    @                 203.0.113.50   🟠
A    mail              203.0.113.10   ⚪ TTL 300  A    mail              203.0.113.50   ⚪ TTL 300
TXT  @    v=spf1 ip4:203.0.113.10 mx ~all         TXT  @    v=spf1 ip4:203.0.113.50 mx ~all
TXT  default._domainkey  p=CLAVE_VIEJA            TXT  default._domainkey  p=CLAVE_NUEVA

Tres cosas que rompen una migración

  1. Olvidar la clave DKIM nueva: cada cPanel genera la suya. Si dejas la vieja, los correos enviados desde el nuevo servidor fallan DKIM.
  2. Full (strict) sin certificado en el servidor nuevo: error 526 en cuanto cambias la IP. Instala el certificado antes.
  3. Cancelar el hosting viejo el mismo día: los servidores de correo remotos que tenían cacheado el MX viejo siguen entregando ahí un rato. Espera al menos una semana y migra lo que llegó.

Escenario 5: un subdominio a otro servidor ​

mitienda.com sigue en cPanel, pero:

  • tienda.mitienda.com → tienda en Shopify.
  • app.mitienda.com → aplicación Node/Laravel en un VPS (198.51.100.20).

Shopify

  1. Shopify Admin → Configuración → Dominios → Conectar dominio existente → tienda.mitienda.com.
  2. En Cloudflare: CNAME tienda shops.myshopify.com en gris. Shopify ya usa su propia CDN y emite su certificado; con proxy, la verificación falla.
  3. Vuelve a Shopify y pulsa Verificar conexión.

VPS

  1. En Cloudflare: A app 198.51.100.20. Ponlo gris mientras obtienes el certificado.
  2. En el VPS: Nginx con server_name app.mitienda.com y Certbot (ver SSL con Let's Encrypt):
bash
sudo certbot --nginx -d app.mitienda.com
  1. Ya con certificado, cambia a naranja. Full (strict) funciona porque el VPS tiene Let's Encrypt válido. Las renovaciones posteriores pasan por el proxy sin problema, o usa el plugin DNS de Cloudflare para no depender del puerto 80.

¿Por qué gris al principio? Con naranja y Always Use HTTPS, el reto de Let's Encrypt en http:// se redirige a https://, Cloudflare intenta conectar al VPS por 443 en strict… y el VPS todavía no tiene certificado: el reto falla con 526.

Zona final (además de la del escenario 1)

txt
Tipo   Nombre   Contenido               Proxy
─────────────────────────────────────────────
CNAME  tienda   shops.myshopify.com     ⚪
A      app      198.51.100.20           🟠

Escenario 6: dominio .mx en Akky hacia Cloudflare ​

mitienda.mx está registrado en Akky (registrador de NIC México). Cloudflare Registrar no vende .mx, así que el dominio se queda en Akky (ahí se renueva) y solo movemos el DNS.

  1. Agrega mitienda.mx a Cloudflare y revisa la zona importada (si el DNS estaba en Akky, copia lo que tengas ahí: MX, TXT...).
  2. Entra a Akky → Mis dominios → mitienda.mx → Administrar → Servidores DNS / Delegación.
  3. Reemplaza los servidores actuales por ana.ns.cloudflare.com y bob.ns.cloudflare.com y guarda. Algunos cambios en .mx piden confirmación por correo al contacto administrativo: revisa la bandeja.
  4. Espera el estado Active (los .mx suelen reflejarse en pocas horas).
  5. Configura SSL y correo igual que en los escenarios 1–3.

.mx y .com.mx son dominios distintos

mitienda.mx y mitienda.com.mx se registran por separado. Si el cliente tiene ambos, usa uno como principal y redirige el otro (escenario 7).

Escenario 7: varios dominios apuntando al mismo sitio ​

El cliente compró mitienda.com (principal), mitienda.mx, mitienda.com.mx y mi-tienda.com para que nadie se los gane.

Mala idea: que todos muestren el mismo sitio (contenido duplicado para Google y cookies/sesiones separadas por dominio). Buena idea: redirección 301 de todos al principal.

  1. Agrega cada dominio secundario como una zona en Cloudflare (Free) y cambia sus nameservers.
  2. En cada uno, registros de relleno en naranja y una Redirect Rule (ver Cloudflare a fondo). Con muchos dominios, una lista de Bulk Redirects a nivel de cuenta es más cómoda.
  3. Como no envían correo, protégelos contra suplantación (que un estafador no mande correos "de" mitienda.mx).

Zona de cada dominio secundario (ej. mitienda.mx)

txt
Tipo   Nombre    Contenido                                   Proxy  Prioridad
──────────────────────────────────────────────────────────────────────────────
AAAA   @         100::                                       🟠
AAAA   www       100::                                       🟠
MX     @         .                                           —      0     (MX nulo: "este dominio no recibe correo")
TXT    @         v=spf1 -all                                 —            (no envía correo)
TXT    _dmarc    v=DMARC1; p=reject;                         —            (rechazar cualquier correo falso)

Redirect Rule:
  (http.host eq "mitienda.mx" or http.host eq "www.mitienda.mx")
  → concat("https://mitienda.com", http.request.uri.path)   301, conservar query

Escenario 8: transferir el dominio del cliente a su propia cuenta ​

Hiciste todo desde tu cuenta de GoDaddy y tu Cloudflare. El proyecto terminó y el dominio debe quedar a nombre del cliente. (Lo ideal es que desde el inicio el cliente sea dueño de las cuentas y te dé acceso.)

Parte A: el registro del dominio

SituaciónCómo se hace
Mismo registrador (GoDaddy → GoDaddy del cliente)Configuración del dominio → Transferir a otra cuenta de GoDaddy (cambio de cuenta). Namecheap y otros tienen "Push / cambio de propietario". No cambia nameservers ni DNS.
Otro registrador (ej. a Cloudflare Registrar o Namecheap del cliente)1) Desbloquear el dominio. 2) Pedir el código EPP/autorización. 3) El cliente inicia la transferencia en su registrador y paga 1 año. 4) Aprobar el correo de confirmación. Los nameservers normalmente se conservan.

Al cambiar el titular, muchos registradores aplican un bloqueo de 60 días para transferencias a otro registrador. Actualiza los datos de contacto (titular, correo administrativo) con los del cliente: si el correo de contacto es el tuyo, los avisos de renovación te llegarán a ti.

Parte B: la zona de Cloudflare

Cloudflare no "pasa" una zona de una cuenta a otra con un botón. Opciones:

  1. Mantenerla en tu cuenta pero agregar al cliente como miembro (Manage Account → Members). Simple, pero sigue siendo tuya.
  2. Moverla (recomendado al cerrar el proyecto):
txt
1. Tú:       DNS → Registros → Importar y exportar → Exportar (archivo BIND).
2. Cliente:  crea su cuenta de Cloudflare (con 2FA) y agrega mitienda.com.
3. Cliente:  importa el archivo BIND; revisa nubes naranja/gris y SSL Full (strict).
4. Cliente:  Cloudflare le asigna nameservers (pueden ser distintos a los tuyos).
5. Registrador: cambiar a los nameservers de la cuenta del cliente.
6. Cuando la zona del cliente esté Active: tú eliminas la zona de tu cuenta.
7. Repetir reglas (redirecciones, WAF, caché), tokens de API y Origin Certificates
   (los Origin Certificates de tu cuenta no se mueven: crea uno nuevo en la cuenta del cliente).

Si hay DNSSEC activo, desactívalo antes del cambio de nameservers y vuelve a activarlo en la cuenta del cliente.

Ejercicios ​

  1. Un cliente tiene dominio en Namecheap, sitio en cPanel (203.0.113.10) y correo en Google Workspace, pero los formularios del sitio no le llegan a Gmail. Los MX están bien. ¿Qué ajuste en cPanel revisas primero?
  2. Escribe la zona completa para: sitio en Netlify (misitio.netlify.app), correo en Zoho (región .com) y una API en un VPS 198.51.100.20 en api.mitienda.com.
  3. Vas a migrar de hosting el viernes a las 23:00. Escribe qué haces el miércoles, el jueves y el viernes.
  4. El cliente tiene mitienda.com.mx sin uso. ¿Qué cuatro registros le pones para que nadie pueda enviar correo falso en su nombre?
Ver solución
  1. cPanel → Email Routing debe estar en Remote Mail Exchanger. En "Local", el servidor entrega los correos del sitio en el buzón local de cPanel en vez de mandarlos a Google.
txt
CNAME  @                 misitio.netlify.app                          ⚪
CNAME  www               misitio.netlify.app                          ⚪
A      api               198.51.100.20                                🟠  (con certificado en el VPS)
MX     @                 mx.zoho.com                                  10
MX     @                 mx2.zoho.com                                 20
MX     @                 mx3.zoho.com                                 50
TXT    @                 zoho-verification=zb...zmverify.zoho.com
TXT    @                 v=spf1 include:zohomail.com ~all
TXT    zmail._domainkey  v=DKIM1; k=rsa; p=...
TXT    _dmarc            v=DMARC1; p=none; rua=mailto:dmarc@mitienda.com
  1. Miércoles: TTL de registros grises (mail, ftp) a 300 s; inventario de buzones y registros. Jueves: restaurar respaldo en el hosting nuevo, crear buzones, instalar Origin Certificate, probar con archivo hosts. Viernes 23:00: congelar el sitio, copiar BD final, cambiar A @ y A mail a la IP nueva, actualizar SPF y DKIM, probar sitio y correo; los días siguientes migrar buzones y mantener el hosting viejo dos semanas.
txt
MX     @        .                      0
TXT    @        v=spf1 -all
TXT    _dmarc   v=DMARC1; p=reject;
(y sin registros DKIM: no hay nada que firmar)

Más un AAAA @ 100:: en naranja con una Redirect Rule si quieres que la web redirija al dominio principal.

Resumen ​

  • Receta universal: inventario → preparar zona → cambiar NS → verificar → asegurar.
  • Correo del hosting: mail en gris, SPF con ip4: y DKIM copiado de cPanel.
  • Correo externo (Google, Zoho): borra el MX viejo y pon Email Routing → Remote en cPanel.
  • Vercel, Netlify y Shopify: registros en gris; ellos ponen su CDN y su certificado.
  • Migraciones: baja TTL antes, certificado en el nuevo origen antes del cambio, DKIM nuevo, no canceles el hosting viejo de inmediato.
  • Dominios extra: 301 al principal + MX nulo, v=spf1 -all y DMARC p=reject.
  • El dominio y el Cloudflare deben quedar a nombre del cliente.
  • Siguiente: Diagnóstico y errores.

Academia Web — aprende, copia y construye.

© 2026