El correo venía incluido con el hosting. Un plan, un panel, un sitio web y cinco buzones, y durante dos años nadie pensó en el tema. Hasta que un cliente dice que nunca le llegó la cotización, la encuentras en su carpeta de spam, y las facturas que manda tu sistema contable empiezan a rebotar con un mensaje sobre autenticación.
El correo en hosting compartido falla de una forma específica y repetible. La solución son casi siempre los mismos tres registros DNS que publica todo el mundo. Lo que cambia es dónde los esconde el panel y cuánto de tu zona DNS controla ese panel de verdad. Esta es la versión práctica para los dos paneles que más vemos en América Latina: el hPanel de Hostinger y cPanel en cualquier hosting que lo revenda.
Por qué el hosting compartido es un problema aparte
Tu sitio web y tus buzones están en una máquina que compartes con cientos de sitios más. El correo sale desde una IP que es del proveedor, y su reputación es la suma del comportamiento de todos, no solo del tuyo. Si otro cliente en ese servidor manda una campaña mala, tu correo se mueve con él.
Esa parte no la controlas. Hay dos que sí controlas y pesan más de lo que la gente cree.
- La autenticación. SPF, DKIM y DMARC son tuyos, viven en tu zona DNS, y en hosting compartido casi siempre falta o está roto por lo menos uno de los tres.
- Quién envía en realidad. Un formulario de contacto que usa la función mail de PHP y un buzón que envía por SMTP autenticado son dos remitentes distintos, y los receptores los juzgan por separado.
Las directrices para remitentes de Gmail marcan la vara con la que te están midiendo. Quien envía más de 5,000 mensajes diarios a cuentas de Gmail debe tener SPF y DKIM configurados, un registro DMARC en el dominio remitente (se acepta una política de aplicación none), DNS directo e inverso válidos en la IP que envía, conexión TLS para transmitir el correo, y una tasa de spam en Postmaster Tools por debajo de 0.30 por ciento. Los remitentes pequeños no quedan fuera de la lógica, solo del umbral. Ojo con el DNS inverso: en hosting compartido el registro PTR es del proveedor, así que si está mal, eso es un ticket de soporte y no una edición de DNS.
Primero: averigua qué zona lee realmente internet
Esta sola verificación ahorra más tardes perdidas que todo lo demás en este artículo. Tu panel tiene un editor de DNS. Ese editor solo sirve si los nameservers del dominio apuntan a ese panel.
Si el dominio está registrado en otro lado y sus nameservers apuntan a Cloudflare, a tu registrador o a un hosting anterior, los registros que agregues en hPanel o en cPanel se van a ver perfectos y nadie los va a consultar nunca. Revisa los nameservers primero y edita la zona a la que apuntan. Todo lo que sigue asume que ya hiciste eso.
Hostinger: hPanel, la zona DNS y el camino automático
En hPanel los registros DNS están en Dominios, luego el dominio, luego Zona DNS. Ahí van los registros MX, SPF, DKIM y DMARC.
Usa el camino automático cuando esté disponible. Si el dominio usa los nameservers de Hostinger, la recomendación del propio Hostinger es usar la opción de conexión en la página del dominio en lugar de escribir los registros a mano, y la pantalla de configuración del dominio de Hostinger Email publica el juego completo de MX, SPF, DKIM y DMARC por ti.
Si los vas a agregar manualmente, hay dos detalles que deciden si funciona o no.
SPF es un único registro TXT en la raíz. El valor que Hostinger documenta para Hostinger Email es:
Tipo Nombre Valor
TXT @ v=spf1 include:_spf.mail.hostinger.com ~all
Si otra plataforma también envía con tu dominio, no agregas un segundo registro. Agregas su include al que ya tienes, dejando un solo mecanismo all al final:
v=spf1 include:_spf.mail.hostinger.com include:_spf.google.com ~all
Tener dos registros TXT que empiezan con v=spf1 en el mismo nombre es una falla dura, no una advertencia. Los receptores obtienen un resultado ambiguo y pueden rechazar el mensaje.
El DKIM de Hostinger Email es un CNAME, no un TXT. Este es el error más común que vemos en Hostinger. La gente conoce DKIM como un valor TXT larguísimo por otros proveedores, elige TXT por costumbre, y la firma simplemente nunca funciona. Copia el host y el destino exactamente como los muestra el panel, y pon el tipo en CNAME.
El sitio web también es un remitente
Un formulario de contacto de WordPress, la confirmación de pedido de WooCommerce o un plugin de reservas normalmente envían por la función de correo local del servidor y no por tu buzón. Ese camino no queda necesariamente cubierto por el include de arriba, y por eso las confirmaciones de pedido caen en spam mientras las respuestas de una persona no. Haz que el sitio se autentique como un buzón real: instala un plugin de SMTP y apúntalo a tu propia cuenta de correo. Así un solo juego de registros cubre todo.
cPanel: la pantalla Email Deliverability hace casi todo
En cPanel entra a la sección Correo electrónico y abre Email Deliverability (Capacidad de entrega). Lista cada dominio de la cuenta con su estado, y es bastante mejor que editar la zona a mano porque genera los registros por ti.
cPanel crea un par de llaves DKIM de 2048 bits, guarda la privada en el servidor, donde Exim firma con ella, y publica la pública como un registro TXT en default._domainkey bajo tu dominio. El selector es default salvo que alguien lo haya cambiado.
Nombre default._domainkey
Tipo TXT
Valor v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...
Junto a cada problema la interfaz muestra un botón Reparar. Al presionarlo, cPanel escribe los registros sugeridos dentro de la zona DNS, y la documentación advierte que eso puede tardar unos minutos según el servidor.
Cuando el botón Reparar está deshabilitado
Reparar solo funciona cuando el sistema controla tu DNS, es decir, cuando el dominio apunta a los nameservers de ese servidor. Si tu DNS vive en Cloudflare, en tu registrador o en cualquier otro lado, cPanel puede generar un registro correcto pero no puede publicarlo, así que el botón no está disponible.
No es un callejón sin salida. La misma pantalla sigue mostrando los valores sugeridos de SPF y de DKIM. Cópialos y crea los registros donde sí vive la zona. Un detalle que cuidar: una llave pública DKIM de 2048 bits es más larga que el límite de 255 caracteres de una sola cadena TXT, así que pégala en una sola línea, sin saltos agregados. cPanel ofrece el valor completo y también una versión partida para proveedores que necesitan la cadena en trozos. Elige la que tu proveedor de DNS espera.
DMARC: el registro que le da sentido a los otros dos
SPF y DKIM producen resultados. DMARC es lo que le dice al receptor que compare esos resultados contra el dominio del campo De que ve tu destinatario, y qué hacer cuando no coinciden. Sin DMARC, un SPF que pasa en un dominio completamente distinto sigue contando como aprobado, y por ese hueco exacto se cuela la suplantación.
Empieza en modo reporte. Agrega un registro TXT:
Nombre _dmarc
Tipo TXT
Valor v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com; fo=1
En hPanel el campo Nombre lleva _dmarc solo, y la zona le agrega tu dominio. Si pegas el hostname completo creas un registro un nivel más abajo que nadie va a leer jamás.
Déjalo en p=none dos o tres semanas y lee lo que llega. Los reportes agregados vienen en XML, así que pega uno en nuestro analizador DMARC en vez de leerlo a ojo. Cuando los reportes muestren alineados a todos tus remitentes legítimos, aprieta la política por pasos. La secuencia completa está en cómo pasar DMARC de p=none a p=reject, y saltarse la fase de reportes es exactamente así como el sistema de facturación y el escáner de la oficina dejan de entregar un lunes por la mañana.
El presupuesto de consultas SPF, que en hosting compartido se agota rápido
El RFC 7208 limita una evaluación de SPF a diez términos que consultan DNS. Cada include, a, mx, redirect y exists cuenta, incluidos los que vienen anidados dentro del include de alguien más. Si te pasas, el resultado es permerror, que la mayoría de receptores trata como si no tuvieras SPF. Los mecanismos ip4, ip6 y all no cuestan nada, y la misma sección limita a dos las consultas vacías.
Un dominio en hosting compartido llega al límite más rápido de lo que uno espera: el include del hosting, el de un proveedor de correo, un CRM, una herramienta de newsletters y una plataforma de facturación ya son cinco includes, y cada uno puede expandirse en varios más. El método para contarlos y las cuatro salidas están en SPF: demasiadas consultas DNS. Fusionar dos registros no ayuda, porque el límite aplica a la evaluación y no al registro.
Lo que nada de esto arregla, y cuándo mover el correo
La autenticación hace que tu correo sea demostrablemente tuyo. No te da una IP de envío limpia. Si la dirección compartida de tu proveedor está limitada o filtrada por culpa de otros inquilinos, lo vas a ver como retrasos intermitentes y como spam que ningún cambio de DNS mejora, y aparece en Postmaster Tools como reputación de IP y no de dominio.
Las señales honestas de que el correo en hosting compartido ya dejó de ser la herramienta correcta:
- Rechazos que mencionan la IP de envío en lugar de tu dominio o tu autenticación.
- Sin bitácora de auditoría útil, sin control de dispositivos y sin forma de recuperar una cuenta cuando alguien se va de la empresa.
- Entrega que cambia de una semana a otra sin que tú hayas cambiado nada.
En ese punto la solución es separar el correo del hosting web. Google Workspace es la ruta que más tomamos, y la mecánica de mover sin perder mensajes está en nuestra guía de migración. El sitio web se queda donde está. Solo se mueven los registros MX y la autenticación.
Verifica antes de darlo por hecho
Los paneles se reportan a sí mismos, lo que los vuelve el lugar equivocado para confirmar tu propio trabajo. Tres revisiones, en orden.
- ¿El registro resuelve donde crees? Consulta el hostname exacto, con selector incluido, y confirma que hay exactamente un registro TXT
v=spf1en la raíz. - ¿El lado del proveedor está encendido? Un registro DKIM publicado no firma nada hasta que la plataforma de correo firma de verdad. En cPanel eso es Email Deliverability mostrando estado válido, no solo un registro en la zona.
- ¿Pasa un mensaje real? Manda uno a una dirección externa, abre el código fuente y lee la cabecera Authentication-Results. Nuestro analizador de cabeceras la lee por ti, y es la única revisión que prueba el camino que recorre de verdad el correo de tus clientes.
Después dale tiempo. Los cambios de DNS en cualquiera de los dos paneles pueden tardar hasta 24 horas en llegar a todos los resolvers, así que una falla cinco minutos después de guardar todavía no es evidencia de nada.
Cómo ayuda Guanacos Tech
Somos una consultoría independiente con ingenieros certificados por Google, y la entregabilidad de correo es el trabajo que más hacemos. Los casos de hosting compartido suelen ser rápidos: los registros están a medias, un remitente nunca se autorizó, y el panel lleva meses reportando éxito sobre una zona que nadie consulta. El primer paso útil es un diagnóstico, no una reescritura. Nuestro diagnóstico de correo y el analizador DMARC son gratis y te dicen casi todo en un minuto. Si prefieres delegarlo, mira cómo trabajamos la entregabilidad o agenda una llamada corta, y trae un mensaje de rebote contigo.
Fuentes
- cPanel Docs: Email Deliverability
- Hostinger: ¿Cuál es el registro SPF de Hostinger Email?
- Hostinger: ¿Cuáles son los registros DKIM de Hostinger Email?
- Hostinger: configurar un dominio para Hostinger Mail manualmente
- Ayuda de Gmail: directrices para remitentes de correo
- RFC 7208: Sender Policy Framework (SPF), versión 1
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)