Puedes poner Cloudflare delante del hosting para que la web entre por su red, con caché y protección ante tráfico abusivo. Las casillas y el panel siguen en el servidor. Se cortan si un nombre de correo o del panel queda en nube naranja, o si el modo SSL no conversa con el certificado del origen.
MX, SPF, DKIM y DMARC se copian del proveedor que ya te los dio.
Qué queda delante y qué sigue en el hosting
Cloudflare puede publicar el DNS y, en algunos nombres, interponerse en el tráfico web. En la documentación del estado del proxy, la nube naranja (Proxied) responde con direcciones anycast de Cloudflare. La visita entra a esa red y sigue al hosting, con protección ante DDoS, caché y reglas. La nube gris (DNS only) responde con la IP real y el tráfico no entra a la red. La guía de casos de uso la reserva para correo, verificaciones y servicios que no hablan HTTP.
Solo se proxyean A, AAAA y CNAME. MX y TXT quedan en Solo DNS. El correo falla si el nombre al que apunta el MX quedó en naranja. Archivos, base, casillas y panel siguen en el servidor, también si el correo está en Google Workspace. En planes Free y Pro el camino es el full setup: Cloudflare pasa a ser el DNS autoritativo. El escaneo no trae todo, y al dar de alta el dominio el proxy viene activado. Un A de mail puede entrar en naranja: revísalo antes de cambiar los nameservers. La web queda en naranja; el correo y el panel, en gris.
Cambia los nameservers, también en un .cl
El full setup asigna dos nameservers. Cloudflare los elige y hay que copiarlos tal cual. Los ves en el alta y, después, en Overview de la zona.
Apaga DNSSEC en el registrador si está activo. Cambiar los nameservers con DNSSEC encendido puede dejar el dominio inalcanzable. Cuando la zona figure como Active, puedes activarlo de nuevo desde Cloudflare.
- Exporta o anota la zona en el panel del hosting.
- Agrega el dominio en Cloudflare y compara el escaneo con esa copia.
- Pasa a nube gris el correo, el panel y las verificaciones.
- Reemplaza los nameservers.
- Espera el estado Active. Cloudflare avisa por correo.
En el registrador quitas los anteriores y pegas los dos nuevos. La documentación pide esperar hasta 24 horas. Comprueba con dig ns tudominio.cl @1.1.1.1. Si la zona sigue en Pending Nameserver Update, la delegación todavía no coincide y se revisa en el registrador.
En un dominio .cl
En un .cl el registro lo lleva NIC Chile. Para cambiar de hospedaje hay que pedir los servidores de nombre y actualizarlos en su sistema de inscripción y gestión de dominios. Procesa esos cambios cada media hora. En algunos lugares la información puede tardar hasta un par de días. Esa nota es de un cambio de proveedor: aquí el alojamiento sigue contratado. Mantén al día los contactos técnico y administrativo. Quién entra a la cuenta está en la guía del dominio .cl; un cambio de servidor, en la guía de migración.
Replica A, AAAA, CNAME, MX y TXT
Activar la zona sin los registros correctos puede mostrar DNS_PROBE_FINISHED_NXDOMAIN. Compara tipo, nombre, contenido y prioridad con la zona del hosting.
| Tipo | Uso | Nube |
|---|---|---|
| A | IPv4 del sitio, de mail o de un subdominio | Naranja solo si ese nombre es la web |
| AAAA | IPv6, si el hosting lo publica | Igual que el A del mismo nombre |
| CNAME | www, una verificación o un servicio externo | Gris si no es tráfico HTTP |
| MX | Destino del correo | Siempre Solo DNS |
| TXT | SPF, DKIM, DMARC y verificaciones | Siempre Solo DNS |
Si un nombre tiene varios A o AAAA y uno está en naranja, Cloudflare trata todos como proxied. El apex y www suelen ir en naranja. Un CNAME de verificación, y también FTP o SSH, van en gris: el proxy solo transporta HTTP y HTTPS.
MX, SPF, DKIM y DMARC
La guía de registros de correo pide los valores de tu proveedor, no unos genéricos:
- Un A o AAAA de
mail, en Solo DNS, hacia la IP del servidor de correo. - Un MX hacia ese nombre, con la misma prioridad de antes.
- Un TXT de SPF (quién puede enviar), el DKIM del proveedor y el DMARC, si ya existe.
Debe haber un solo SPF. La guía de Google Workspace advierte que dos TXT con v=spf1 hacen fallar la comprobación: otros envíos se agregan como include: en el mismo registro. Si el correo sale del hosting, conserva ese SPF. Un rechazo posterior se lee con la guía de correos a spam.
DKIM va en selector._domainkey, en TXT o en CNAME. Si ese CNAME tiene aplanado (CNAME flattening), puede volverse un A y dejar de servir: la guía de problemas de correo indica apagarlo. Si no hay DMARC y el correo es Google Workspace, parte en p=none. Si ya tienes _dmarc, cópialo. Conserva un NS que delegue el correo a otro proveedor.
El correo va en nube gris
SMTP, IMAP y POP3 no atraviesan el proxy HTTP. Si mail resuelve a una IP de Cloudflare, el cliente no conecta.
El MX no se puede proxyear. El hostname al que apunta sí, y queda en Solo DNS: mail, cualquier nombre usado por el MX, webmail, autodiscover, autoconfig, y smtp, imap o pop si existen como registros propios.
Si el MX apunta al nombre de la web y ese nombre está en naranja, Cloudflare inserta un _dc-mx hacia la IP de origen. No sale en la tabla y sí en un dig. Sirve para la recepción. IMAP, el webmail y el envío de la casilla siguen el A de su nombre y en naranja resuelven en Cloudflare. Deja mail en gris y apunta el MX ahí. Si comparten IP con la web, ese nombre muestra la IP del servidor.
En el puerto 25 no hay proxy de correo, salvo Spectrum para SMTP. Si Email Routing está encendido y las casillas están en otro proveedor, apágalo: sus MX chocan con los tuyos, y con Google Workspace no conviven.
Comprueba con dig tudominio.cl mx +short. Tiene que coincidir con Cloudflare y con lo que te entregó el hosting. Si mail responde una IP de Cloudflare, sigue en naranja.
El panel en directo y el SSL sin bucles
cPanel y DirectAdmin se abren por el hostname del servidor, por la IP o por un subdominio (cpanel, webmail u otro). Ese nombre va en Solo DNS: llegas al servidor, el panel no entra a la caché y el modo SSL de la zona no interviene. La comparación de paneles explica para qué sirve cada uno.
El proxy solo lleva HTTP y HTTPS, en los puertos documentados: 80, 443, 8080, 8880, 2052, 2053, 2082, 2083, 2086, 2087, 2095, 2096 y 8443. Salvo 80, 443 y 8080, en esos puertos la caché viene desactivada. El panel igual conviene en gris: un puerto fuera de la lista ni siquiera entra. Si la URL trae otro puerto, usa nube gris, la IP o el hostname del servidor.
Full (strict) en el sitio
El sitio público sí va en naranja. Full (strict) cifra hasta el hosting y exige un certificado vigente, de una CA pública o del Origin CA, con el nombre del hostname, y HTTPS en el puerto 443. Si no cumple, puede aparecer un error 526.
Flexible habla con el hosting por HTTP. Si el servidor manda ese HTTP a HTTPS, aparece ERR_TOO_MANY_REDIRECTS: quita la redirección o pasa a Full o superior. Con Full o Full (strict) el bucle es el inverso, el origen devolviendo el HTTPS a HTTP. Always Use HTTPS actúa solo en los nombres que pasan por Cloudflare; el panel en gris sigue con el certificado del servidor. Si el navegador marca la web, separa certificado y contenido mixto con la guía de web no segura. En WordPress, Cloudflare recomienda su plugin en el origen y la reescritura automática a HTTPS.
Lista de comprobación con la zona Active
- Abre el dominio y
www: el sitio carga, con candado y sin bucle. - Entra al panel por hostname, IP o subdominio en gris. Tiene que pedir usuario.
- Envía un correo desde una casilla del dominio hacia afuera y responde hacia esa casilla.
- Abre el webmail por el nombre de siempre.
- Compara MX, SPF, DKIM y DMARC con la copia anterior.
- Confirma
mail,webmail, autodiscover y el panel en gris, y el apex ywwwen naranja.
Si un envío cae en spam, la guía de casillas separa un DNS incompleto de una casilla llena.
Errores frecuentes
| Qué ves | Qué suele pasar | Qué revisar |
|---|---|---|
| La zona sigue Pending | Los nameservers no están publicados | Los dos de Cloudflare, copiados tal cual |
| Bucle de redirecciones | El modo SSL y el origen se contradicen | Flexible, Full y las redirecciones HTTP/HTTPS |
| Error 526 | El certificado del origen no calza o venció | Nombre, vigencia y HTTPS en el puerto 443 |
| El cliente de correo no conecta | mail o el destino del MX está en naranja | dig tudominio.cl mx +short |
| El panel no abre | Subdominio en naranja, o puerto fuera del proxy | Nube gris, IP o hostname del servidor |
Aparece _dc-mx | El MX apunta a un nombre proxied | Un mail en Solo DNS |
El TTL automático de un registro proxied es de 300 segundos; si tu red sigue viendo el dato viejo, consulta con @1.1.1.1. Un _acme-challenge que no está en la tabla lo crea Cloudflare para el certificado del borde. Registros de más tras el import suelen venir de un comodín * del DNS anterior.
Cuándo pedirle ayuda al hosting
Escribe al hosting si la zona ya coincide con lo entregado y sigue el fallo: te falta la zona anterior, Full (strict) responde 526, el panel filtra tu IP o el correo rebota con los MX iguales. Manda dominio, hora, texto del error y si el registro está en naranja o en gris. Quien administra el correo distingue un rechazo de DNS, del servidor o de la entrega. Si el registro está bien, sigue con el soporte de Cloudflare.
En Bitsur puedes ver el hosting para empresas, los certificados SSL y el correo corporativo. Escríbenos con el dominio, dónde está el correo y si el panel es cPanel o DirectAdmin.
Preguntas frecuentes
¿Puedo dejar la nube naranja en todos los registros?
En la web, sí. En el correo y en el panel, gris. mail en naranja impide SMTP, IMAP y POP3.
¿Tengo que mover las casillas a Cloudflare?
Puedes dejarlas donde están. Email Routing, encendido sin usarlo para reenviar, puede ocupar los MX. Siguen valiendo los registros del correo del hosting o de Google Workspace.
¿Cuánto tarda un .cl?
Media hora en los sistemas de NIC Chile, hasta 24 horas para que el registrador publique, y hasta un par de días en algunos puntos de la red. Mientras tanto el hosting sigue contratado.