← Volver al blog

SPF, DKIM y DMARC en Hostinger (hPanel) y cPanel: guía para el correo con hosting compartido

SPF, DKIM y DMARC en Hostinger (hPanel) y cPanel: guía para el correo con hosting compartido

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.

  1. ¿El registro resuelve donde crees? Consulta el hostname exacto, con selector incluido, y confirma que hay exactamente un registro TXT v=spf1 en la raíz.
  2. ¿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.
  3. ¿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

Preguntas frecuentes

¿Por qué el botón Reparar de Email Deliverability en cPanel está deshabilitado?

Porque cPanel no controla tu zona DNS. Reparar escribe los registros directamente en la zona, así que solo está disponible cuando el dominio apunta a los nameservers de ese servidor. Si tu DNS está en Cloudflare, en tu registrador o en otro proveedor, copia los valores sugeridos de SPF y DKIM de esa misma pantalla y crea los registros allá a mano.

¿Por qué falla DKIM en Hostinger aunque ya agregué el registro?

La causa más común es el tipo de registro. Los registros DKIM predeterminados de Hostinger Email son de tipo CNAME, no TXT, y la gente los agrega como TXT por costumbre, porque así publican DKIM otros proveedores. La firma entonces falla y los receptores pueden tratar el mensaje como inseguro. Borra la versión TXT, agrega el CNAME con el host y el destino exactos que muestra el panel, y vuelve a probar.

¿Necesito los tres registros si solo mando unos pocos correos a la semana?

Sí. Los requisitos publicados por Gmail ponen la vara más estricta a quienes envían más de 5,000 mensajes diarios, pero el volumen bajo no te libra del filtrado, y en hosting compartido estás usando prestada la reputación de todos los demás inquilinos del servidor. SPF, DKIM y DMARC son la única parte de esa ecuación que es tuya, y no cuestan más que tres registros DNS.