La entregabilidad del correo electrónico es uno de esos aspectos técnicos que muchas veces no reciben atención hasta que aparece un problema. Creamos una cuenta, enviamos un mensaje de prueba y, como el servidor no devuelve ningún error, damos por hecho que todo funciona correctamente.
Sin embargo, enviar un correo no significa necesariamente que ese mensaje haya llegado a la bandeja de entrada.
Un correo puede salir aparentemente bien del servidor y terminar en la carpeta de spam, ser rechazado por el proveedor del destinatario o no superar las comprobaciones de autenticación. En ocasiones, ni siquiera recibiremos una notificación clara que nos permita identificar lo sucedido.
En mi experiencia, este tipo de incidencias suele descubrirse en el peor momento: cuando un cliente asegura que no ha recibido un presupuesto, cuando una factura no llega a su destinatario o cuando una respuesta de soporte parece haber sido ignorada.
Para evitar estas situaciones, cPanel incorpora la herramienta Email Deliverability, desde la que podemos revisar algunos de los registros DNS más importantes para la autenticación del correo electrónico.
Esta función permite comprobar la configuración de SPF, DKIM, DMARC y, en determinados casos, el registro PTR o DNS inverso. Si detecta alguna incidencia, muestra información sobre el registro afectado y propone los valores que deberían utilizarse para corregirla.
Aun así, conviene tener clara una idea desde el principio: Email Deliverability es una excelente herramienta de diagnóstico, pero no garantiza por sí sola que todos nuestros mensajes lleguen a la bandeja de entrada.
La reputación de la dirección IP, el contenido del mensaje, el volumen de envíos, la calidad de las listas de destinatarios y las quejas por spam también influyen en la entrega.
En esta guía explicaré cómo utilizar Email Deliverability en cPanel, qué significa cada registro, cuándo podemos reparar los problemas automáticamente y qué deberíamos revisar si todo aparece como válido, pero nuestros mensajes continúan llegando a spam.
Qué es Email Deliverability y por qué debería preocuparte
Email Deliverability es una herramienta de cPanel diseñada para analizar la configuración relacionada con la autenticación y la entrega del correo electrónico de los dominios alojados en una cuenta.
Su objetivo principal es ayudarnos a detectar si existen errores en los registros DNS que permiten a otros servidores comprobar que nuestros mensajes son legítimos.
Cuando enviamos un correo desde una dirección como contacto@midominio.com, el servidor receptor no se limita a leer el remitente que aparece en pantalla. También puede realizar distintas comprobaciones para determinar si el servidor que está enviando el mensaje tiene autorización para utilizar ese dominio.
Entre otras cosas, puede comprobar:
- Qué servidores están autorizados mediante SPF.
- Si el mensaje contiene una firma DKIM válida.
- Qué política DMARC ha definido el dominio.
- Si la dirección IP de envío dispone de una resolución DNS inversa coherente.
- Si la IP o el dominio tienen una buena reputación.
- Si el contenido presenta características habituales del correo no deseado.
Email Deliverability se concentra principalmente en la parte relacionada con la autenticación DNS.
Enviar un correo no significa que haya llegado
Uno de los errores más frecuentes consiste en pensar que, si el correo aparece en la carpeta de enviados, el destinatario lo ha recibido.
En realidad, la carpeta de enviados únicamente confirma que la aplicación o el servidor ha procesado el mensaje. A partir de ese momento, todavía debe ser aceptado por el servidor receptor y superar sus filtros.
El mensaje puede encontrarse con varios resultados:
- Llegar correctamente a la bandeja de entrada.
- Terminar en promociones, correo no deseado o spam.
- Ser rechazado durante la comunicación entre servidores.
- Ser aceptado inicialmente y filtrado después.
- Generar un rebote inmediato o diferido.
- Desaparecer sin que el usuario identifique fácilmente la causa.
En mi caso, siempre recomiendo comprobar la entregabilidad cuando una empresa depende del correo para comunicarse con clientes. No basta con verificar que la cuenta puede enviar y recibir un mensaje de prueba entre dos direcciones propias.
También conviene probar envíos hacia proveedores diferentes, como Gmail, Outlook o Yahoo, y revisar cómo interpretan la autenticación del dominio.
Cómo puede afectar al negocio una mala entregabilidad
Una configuración incorrecta no es únicamente un problema técnico. Puede tener consecuencias comerciales.
Imaginemos que enviamos una propuesta y el cliente nunca la recibe. Nosotros podemos interpretar su silencio como falta de interés, mientras que el cliente piensa que no hemos respondido.
Algo parecido puede ocurrir con:
- Facturas.
- Confirmaciones de pedidos.
- Recuperaciones de contraseña.
- Respuestas de soporte.
- Avisos de renovación.
- Notificaciones de reservas.
- Comunicaciones internas.
- Formularios enviados desde una página web.
Además de provocar retrasos, estos fallos pueden generar una imagen poco profesional. El cliente no sabe que existe un problema de autenticación, reputación o filtrado. Simplemente percibe que la empresa no responde o que sus sistemas no son fiables.
Por esta razón, considero que revisar Email Deliverability debería formar parte del mantenimiento habitual de cualquier dominio que utilice el correo como canal de comunicación.
Qué analiza la herramienta Email Deliverability de cPanel
La herramienta de cPanel revisa distintos elementos relacionados con la identidad del remitente. Los más importantes son SPF, DKIM, DMARC y PTR.
Aunque sus nombres puedan parecer complicados, cada uno cumple una función relativamente sencilla.
SPF: qué servidores pueden enviar correos por tu dominio
SPF, siglas de Sender Policy Framework, es un registro DNS que indica qué servidores están autorizados para enviar correos en nombre de un dominio.
Por ejemplo, un dominio puede enviar mensajes desde:
- El servidor de hosting.
- Una plataforma de marketing.
- Un sistema de facturación.
- Google Workspace.
- Microsoft 365.
- Un servicio externo de atención al cliente.
Todos los servicios legítimos que necesiten utilizar el dominio deben estar contemplados en la política SPF.
Cuando el servidor receptor recibe un mensaje, puede comparar la dirección IP de envío con la información publicada en el registro. Si la IP no está autorizada, la comprobación SPF puede fallar.
Esto no significa que el mensaje vaya a ser rechazado automáticamente. Cada proveedor aplica sus propias políticas y combina distintas señales. No obstante, una comprobación SPF fallida puede aumentar la posibilidad de que el correo sea filtrado o marcado como sospechoso.
Un error habitual consiste en crear varios registros SPF separados. Lo correcto es mantener una única política SPF y combinar dentro de ella todos los mecanismos necesarios.
Antes de modificar este registro, recomiendo revisar qué servicios envían realmente correos utilizando el dominio. Eliminar una plataforma legítima podría solucionar un problema y crear otro.
DKIM: cómo verifica la autenticidad de los mensajes
DKIM, siglas de DomainKeys Identified Mail, añade una firma digital a los mensajes salientes.
El servidor de correo firma determinados elementos del mensaje utilizando una clave privada. Después, el servidor receptor consulta una clave pública publicada en el DNS del dominio y verifica la firma.
Esta comprobación permite confirmar dos aspectos importantes:
- Que el mensaje está relacionado con el dominio indicado por DKIM.
- Que las partes firmadas no han sido modificadas durante el envío.
DKIM no cifra el contenido del correo y tampoco impide por sí solo la suplantación. Su función es permitir que el receptor valide la firma.
Cuando la configuración DKIM es incorrecta, cPanel puede mostrar el registro recomendado. Si la zona DNS se administra desde el mismo servidor, la herramienta puede intentar repararlo automáticamente.
Si el DNS se gestiona desde otra plataforma, tendremos que copiar el nombre y el valor sugeridos para añadirlos en el proveedor correspondiente.
DMARC: qué hacer cuando un correo no supera la autenticación
DMARC, siglas de Domain-based Message Authentication, Reporting and Conformance, se apoya en SPF y DKIM.
Permite indicar a los servidores receptores qué deberían hacer cuando un mensaje no supera correctamente las comprobaciones o no existe una alineación adecuada con el dominio visible para el usuario.
Las políticas más habituales son:
p=none: supervisar sin solicitar una acción estricta.p=quarantine: recomendar que los mensajes sospechosos sean tratados como spam.p=reject: recomendar el rechazo de los mensajes que no cumplan la política.
DMARC también puede utilizarse para recibir informes sobre los servidores que están enviando correos en nombre del dominio.
No recomiendo aplicar directamente una política estricta sin haber comprobado antes todos los servicios legítimos de envío. Si configuramos reject demasiado pronto y olvidamos una plataforma, podemos provocar el rechazo de correos válidos.
Una estrategia prudente consiste en comenzar con supervisión, analizar los informes, corregir los servicios no alineados y endurecer progresivamente la política.
PTR o DNS inverso: la relación entre la IP y el servidor
El registro PTR permite realizar una consulta inversa: en lugar de obtener una dirección IP a partir de un nombre, relaciona una dirección IP con un nombre de servidor.
Por ejemplo, la IP de un servidor de correo puede resolver hacia un hostname como servidor.ejemplo.com.
Los proveedores receptores suelen valorar que exista coherencia entre:
- La dirección IP de envío.
- El hostname del servidor.
- El saludo HELO o EHLO.
- La resolución DNS inversa.
- La resolución directa del hostname.
El PTR presenta una diferencia importante respecto a SPF, DKIM o DMARC: normalmente no se administra desde la zona DNS del dominio.
La modificación suele depender del proveedor que controla la dirección IP. En un hosting compartido, un servidor virtual o una infraestructura administrada, tendremos que solicitar el cambio al proveedor responsable.
Por eso, cuando cPanel detecta un problema de PTR, no siempre puede ofrecer una reparación automática.
Cómo acceder a Email Deliverability en cPanel
El acceso es sencillo:
- Inicia sesión en cPanel.
- Localiza la sección Correo electrónico.
- Abre la herramienta Email Deliverability.
- Busca el dominio que quieras revisar.
- Consulta su estado.
- Utiliza Administrar para ver los detalles o Reparar cuando la opción esté disponible.
La interfaz puede mostrar varios dominios y subdominios asociados a la cuenta. Conviene revisar el dominio desde el que se envían realmente los mensajes.
Cómo interpretar el estado de cada dominio
Cuando la configuración no presenta problemas detectables, cPanel puede mostrar el dominio como válido.
Esto significa que, según las comprobaciones realizadas por la herramienta, los registros analizados parecen correctos.
No significa necesariamente que:
- Todos los mensajes lleguen a la bandeja de entrada.
- La dirección IP tenga buena reputación.
- El dominio no esté en una lista de bloqueo.
- El contenido sea adecuado.
- DMARC esté configurado con una política estricta.
- Todos los proveedores interpreten los mensajes de la misma manera.
El estado válido debe entenderse como una confirmación de que la parte básica de la autenticación revisada por cPanel no presenta errores evidentes.
Qué significa que la configuración aparezca como válida
Cuando veo un dominio marcado como válido, lo interpreto como un buen punto de partida, no como el final del diagnóstico.
La autenticación correcta ayuda a generar confianza y permite que el proveedor receptor identifique mejor el origen del mensaje. Sin embargo, la decisión de colocarlo en la bandeja de entrada puede depender de muchas otras señales.
Por tanto, si los correos continúan llegando a spam, deberemos ampliar la revisión.
Qué información muestra cPanel cuando detecta un problema
Cuando encuentra una incidencia, cPanel puede indicar:
- El registro afectado.
- La configuración actual.
- El valor recomendado.
- El motivo del problema.
- Las acciones disponibles.
- Si el servidor tiene autoridad para modificar la zona DNS.
Esta información resulta especialmente útil porque evita tener que construir desde cero los registros.
Aun así, antes de aplicar cualquier cambio recomiendo comprobar si el dominio utiliza servicios externos. El valor sugerido puede ser correcto para el servidor de hosting, pero el registro final debe contemplar todas las plataformas legítimas.
Cómo reparar problemas de entregabilidad desde cPanel
Cuando cPanel detecta un registro incorrecto, normalmente ofrece las opciones Reparar y Administrar.
Ambas son útiles, pero no cumplen la misma función.
Diferencia entre Reparar y Administrar
La opción Reparar intenta instalar automáticamente la configuración recomendada.
Es una alternativa cómoda cuando:
- El servidor controla la zona DNS.
- El dominio utiliza los nameservers del hosting.
- No existen configuraciones externas que deban conservarse.
- cPanel tiene permisos para modificar los registros.
La opción Administrar permite revisar los detalles antes de hacer cambios.
Desde ahí podemos consultar:
- El registro actual.
- El registro sugerido.
- El nombre o host que debe utilizarse.
- El valor completo.
- Posibles personalizaciones.
- Información sobre el error.
Personalmente, prefiero revisar primero Administrar, especialmente cuando el dominio utiliza varias plataformas de correo. Una reparación automática puede ser correcta, pero conviene entender qué se está modificando.
Cuándo utilizar la reparación automática
La reparación automática es apropiada cuando estamos seguros de que el DNS se gestiona desde el propio servidor y la configuración propuesta corresponde con el uso real del dominio.
Por ejemplo, puede ser útil después de:
- Crear una nueva cuenta de hosting.
- Migrar un dominio.
- Cambiar los nameservers.
- Eliminar accidentalmente un registro.
- Detectar que DKIM no se ha publicado.
- Encontrar un error en la política SPF.
Después de reparar, deberíamos volver a cargar la herramienta y comprobar el estado. También puede ser necesario esperar a que los cambios DNS se propaguen.
Cómo revisar los registros recomendados antes de modificarlos
Antes de copiar o instalar un registro, recomiendo seguir esta secuencia:
- Identificar qué registro presenta el problema.
- Copiar la configuración actual.
- Anotar los servicios externos que envían correos.
- Comparar el registro actual con el sugerido.
- Confirmar dónde se administra la zona DNS.
- Aplicar el cambio.
- Esperar la propagación.
- Volver a comprobar el dominio.
- Realizar pruebas de envío.
Guardar una copia del valor anterior facilita la recuperación si descubrimos que algún servicio ha dejado de autenticar correctamente.
Qué hacer si tu dominio utiliza DNS externos
Una de las situaciones que más confusión genera aparece cuando cPanel muestra los registros recomendados, pero no puede instalarlos.
Esto suele ocurrir cuando el dominio utiliza nameservers externos.
La página web puede estar alojada en un servidor con cPanel, mientras que la zona DNS se administra en:
- Un registrador de dominios.
- Una plataforma CDN.
- Un servicio especializado de DNS.
- Otro proveedor de hosting.
- Una infraestructura corporativa.
En esos casos, realizar el cambio únicamente dentro de cPanel no tendrá efecto si esa zona no es la autoritativa.
Por qué cPanel no siempre puede instalar los registros
Para que cPanel pueda modificar un registro efectivo, el servidor debe controlar la zona DNS que responde públicamente por el dominio.
Si los nameservers apuntan hacia otro proveedor, cPanel puede mostrar una recomendación, pero no dispone de autoridad para publicarla.
En mi experiencia, este es uno de los motivos más frecuentes por los que un usuario pulsa Reparar y después comprueba que el problema continúa.
La herramienta no está fallando. Simplemente está intentando modificar una zona que no controla la resolución pública del dominio.
Cómo copiar SPF, DKIM y DMARC al proveedor DNS
Cuando utilizamos DNS externos, debemos abrir la opción Administrar y copiar los datos sugeridos.
Normalmente necesitaremos:
- Tipo de registro.
- Nombre o host.
- Valor.
- TTL, cuando sea necesario.
Después tendremos que acceder al panel del proveedor DNS y crear o modificar el registro correspondiente.
Al copiarlo, conviene prestar atención a cómo interpreta cada panel el nombre del dominio. Algunos proveedores esperan únicamente el prefijo; otros permiten escribir el nombre completo.
También debemos evitar:
- Duplicar SPF.
- Crear dos registros DKIM con el mismo selector.
- Añadir comillas incorrectas.
- Introducir espacios o saltos de línea.
- Copiar el dominio dos veces en el campo del host.
- Sustituir un registro que incluía otros servicios legítimos.
Cómo comprobar dónde se gestiona realmente la zona DNS
La forma más sencilla consiste en revisar los nameservers del dominio.
Los nameservers indican qué proveedor responde de forma autoritativa por la zona DNS.
También podemos comprobar:
- El panel del registrador.
- La configuración del dominio en el hosting.
- Los datos de una consulta DNS.
- La información proporcionada durante una migración.
- Si se está utilizando una plataforma CDN.
Una vez localizado el proveedor autoritativo, todos los cambios efectivos de SPF, DKIM y DMARC deberán realizarse allí.
Cómo resolver problemas con el registro PTR
Los problemas de PTR no se corrigen como un registro TXT normal.
La razón es que la zona de resolución inversa pertenece al propietario del bloque de direcciones IP, no al propietario del dominio que utiliza la IP.
Por qué el PTR no se configura como un registro DNS normal
Cuando administramos un dominio, controlamos normalmente registros como:
- A.
- AAAA.
- MX.
- TXT.
- CNAME.
Sin embargo, el PTR pertenece a la zona inversa asociada a la dirección IP.
Por esta razón, añadir un registro llamado PTR en el editor DNS habitual no suele solucionar nada. El cambio debe realizarse en la infraestructura del proveedor que controla la IP.
Cuándo debes contactar con tu proveedor de hosting
Deberíamos contactar con el proveedor cuando:
- El PTR no existe.
- La IP resuelve hacia un hostname incorrecto.
- El hostname no tiene resolución directa.
- El HELO del servidor no coincide con la configuración esperada.
- cPanel muestra un problema que no permite reparar.
- El servidor utiliza una IP compartida administrada por el hosting.
En HostingTG, este tipo de incidencias deben analizarse desde el lado del servidor, ya que el usuario normalmente no dispone de permisos para modificar la resolución inversa de una IP compartida.
Relación entre PTR, hostname y HELO
Una configuración coherente suele presentar esta relación:
- La IP dispone de un PTR hacia un hostname.
- El hostname resuelve nuevamente hacia la IP.
- El servidor utiliza un HELO o EHLO razonablemente relacionado.
- El nombre utilizado no es genérico ni inconsistente.
Esta coherencia no garantiza la entrega, pero elimina una señal negativa que algunos proveedores pueden utilizar durante sus comprobaciones.
Errores frecuentes al configurar Email Deliverability
Muchas incidencias no se deben a la ausencia total de registros, sino a pequeñas decisiones incorrectas.
Crear más de un registro SPF
Un dominio no debería publicar varios registros SPF independientes.
Si necesitamos autorizar distintos servicios, tendremos que combinarlos dentro de una sola política.
Antes de modificar SPF, debemos identificar todos los remitentes legítimos. De lo contrario, podemos autorizar el servidor de hosting y dejar fuera la plataforma de facturación o marketing.
Modificar registros correctos sin revisar la configuración existente
Cuando aparece un problema, la reacción habitual es reemplazar inmediatamente el valor actual por el sugerido.
Esto puede ser peligroso si el registro incluye configuraciones personalizadas.
Recomiendo guardar una copia y comparar ambos valores. A veces la solución consiste en incorporar una parte de la recomendación, no en eliminar todo lo anterior.
Configurar los registros en el proveedor equivocado
Otro error frecuente consiste en modificar la zona DNS de cPanel cuando el dominio utiliza nameservers externos.
El cambio parece guardarse correctamente, pero no se publica en Internet.
Antes de tocar un registro, deberíamos saber quién controla realmente el DNS.
Pensar que SPF y DKIM garantizan la bandeja de entrada
SPF y DKIM mejoran la autenticación, pero no controlan por sí solos la clasificación final.
Un mensaje puede superar ambas comprobaciones y terminar en spam por:
- Mala reputación de IP.
- Quejas de usuarios.
- Contenido sospechoso.
- Envíos bruscos o masivos.
- Listas compradas.
- Demasiados rebotes.
- Enlaces de baja reputación.
- Adjuntos problemáticos.
Yo presentaría SPF y DKIM como requisitos básicos, no como una garantía.
No esperar a que se propaguen los cambios DNS
Los cambios DNS no siempre se reflejan inmediatamente.
El tiempo depende del TTL, de la caché de los resolvers y del proveedor utilizado.
Después de modificar un registro, conviene esperar, realizar nuevas consultas y evitar aplicar cambios sucesivos sin comprobar si el anterior ya se ha propagado.
Qué revisar si cPanel muestra todo como válido, pero los correos llegan a spam
Este es el punto en el que debemos ampliar el diagnóstico.
Si Email Deliverability muestra SPF y DKIM como válidos, la causa puede encontrarse fuera de la configuración básica.
Reputación de la dirección IP
Las direcciones IP utilizadas para enviar correos desarrollan una reputación.
Esta reputación puede verse afectada por:
- Envíos de spam.
- Equipos o cuentas comprometidas.
- Volúmenes anormales.
- Rebotes.
- Quejas.
- Inclusión en listas de bloqueo.
- Actividad de otros usuarios en una IP compartida.
En un hosting compartido, la reputación puede depender parcialmente de la gestión global del servidor.
Reputación del dominio remitente
Los proveedores también evalúan el comportamiento del dominio.
Cambiar de dirección IP no siempre resuelve un problema si el dominio mantiene un historial negativo.
Una buena reputación se construye con:
- Envíos esperados.
- Destinatarios interesados.
- Pocos rebotes.
- Pocas quejas.
- Volumen estable.
- Identidad coherente.
- Autenticación correcta.
Volumen y frecuencia de los envíos
Un dominio que envía diez mensajes diarios y pasa repentinamente a enviar miles puede activar filtros.
Cuando iniciamos una nueva campaña o utilizamos una infraestructura nueva, conviene aumentar el volumen progresivamente.
También debemos separar el correo transaccional del promocional cuando la actividad lo justifique.
Calidad de la lista de destinatarios
Una lista antigua o comprada puede contener:
- Direcciones inexistentes.
- Buzones abandonados.
- Trampas de spam.
- Usuarios que nunca solicitaron los mensajes.
- Contactos que ya no reconocen al remitente.
En mi opinión, una lista pequeña y activa es mucho más valiosa que una base de datos grande con destinatarios desinteresados.
Contenido, enlaces y archivos adjuntos
El contenido también influye.
Deberíamos revisar:
- Asuntos engañosos.
- Exceso de mayúsculas.
- Demasiados enlaces.
- URLs acortadas.
- Dominios enlazados con mala reputación.
- Adjuntos ejecutables o poco habituales.
- Mensajes formados únicamente por una imagen.
- Falta de versión en texto.
- Remitentes poco reconocibles.
No existe una palabra mágica que envíe automáticamente todos los mensajes a spam. Los filtros modernos analizan el conjunto del mensaje y el comportamiento del remitente.
Rebotes, quejas y bajas
Un volumen elevado de rebotes indica que la lista no se mantiene correctamente.
Las quejas por spam son todavía más perjudiciales. El hecho de que una persona facilitara su dirección hace años no significa que siga esperando recibir mensajes.
En campañas comerciales, debemos incluir un mecanismo claro de baja y procesar las solicitudes correctamente.
Buenas prácticas para mejorar la entregabilidad del correo
La entregabilidad no se resuelve con una única acción. Requiere una combinación de configuración técnica, mantenimiento y buenas prácticas.
Mantener SPF, DKIM y DMARC correctamente alineados
Revisa periódicamente:
- Qué servicios envían correos.
- Si SPF incluye todos los remitentes legítimos.
- Si DKIM continúa validando.
- Si DMARC recibe y procesa informes.
- Si el dominio visible está alineado.
- Si se han eliminado servicios antiguos.
Cada vez que se cambia de proveedor, se migra el hosting o se incorpora una plataforma, conviene repetir la revisión.
Evitar envíos masivos no solicitados
No utilices cuentas de hosting convencionales para campañas masivas no solicitadas.
Además de perjudicar la reputación, este tipo de envío puede provocar bloqueos, limitaciones y suspensión del servicio.
Para campañas legítimas, utiliza una plataforma preparada para gestionar:
- Bajas.
- Rebotes.
- Quejas.
- Segmentación.
- Calentamiento.
- Métricas de entrega.
Eliminar direcciones inexistentes o inactivas
Mantén limpia la lista.
Elimina o revisa:
- Rebotes permanentes.
- Direcciones con errores.
- Contactos inactivos durante largos periodos.
- Usuarios que han solicitado la baja.
- Direcciones que nunca interactúan.
Utilizar un remitente reconocible
El destinatario debe identificar fácilmente quién le escribe.
Conviene mantener coherencia entre:
- Nombre del remitente.
- Dirección de correo.
- Dominio.
- Contenido.
- Página enlazada.
- Motivo del mensaje.
Los correos inesperados o confusos generan más quejas, incluso cuando son técnicamente legítimos.
Revisar periódicamente la reputación del dominio y de la IP
No esperes a que aparezca una incidencia grave.
Incluye en el mantenimiento:
- Revisión de listas de bloqueo.
- Supervisión de rebotes.
- Análisis de informes DMARC.
- Comprobaciones de SPF y DKIM.
- Pruebas hacia distintos proveedores.
- Control de cuentas comprometidas.
- Actualización de contraseñas.
- Revisión de scripts que envían correos desde la web.
Cómo utilizamos Email Deliverability en HostingTG
En HostingTG utilizamos cPanel en nuestros planes de hosting compartido porque centraliza las principales tareas relacionadas con dominios, páginas web, bases de datos y cuentas de correo.
Email Deliverability es un buen ejemplo de cómo una herramienta visual puede convertir una configuración técnica en un proceso más accesible.
Diagnóstico centralizado desde cPanel
Desde una única pantalla, el usuario puede comprobar:
- Qué dominios presentan problemas.
- Qué registro necesita atención.
- Qué valor recomienda el servidor.
- Si la reparación automática está disponible.
- Qué cambios deben realizarse externamente.
Esto reduce el tiempo necesario para localizar la causa de una autenticación incorrecta.
Corrección de errores sin utilizar la consola
No todos los propietarios de una página web conocen el funcionamiento interno del DNS ni se sienten cómodos trabajando desde una consola.
Cuando el servidor controla la zona, cPanel permite corregir determinados errores sin introducir comandos.
Esta facilidad resulta especialmente útil después de migraciones, cambios de nameservers o modificaciones accidentales.
Cuándo es necesaria la intervención del proveedor
Existen situaciones que el usuario no puede resolver desde su cuenta:
- Cambios en el PTR.
- Problemas del hostname.
- Incidencias generales del servidor.
- Reputación de una IP compartida.
- Bloqueos de puertos.
- Configuración del servicio de correo.
- Errores que requieren permisos administrativos.
En estos casos, la información mostrada por Email Deliverability facilita el diagnóstico inicial y permite proporcionar datos concretos al soporte.
Checklist para revisar la entregabilidad de un dominio
Cuando un correo no llega, recomiendo seguir un orden. Cambiar varios elementos a la vez dificulta identificar la causa.
Comprobaciones dentro de cPanel
- Acceder a Email Deliverability.
- Revisar el estado del dominio.
- Abrir Administrar.
- Comprobar SPF.
- Comprobar DKIM.
- Revisar DMARC.
- Consultar posibles avisos sobre PTR.
- Comparar los valores actuales con los sugeridos.
- Verificar si Reparar está disponible.
Comprobaciones en el proveedor DNS
- Confirmar los nameservers autoritativos.
- Comprobar que los registros están publicados en el proveedor correcto.
- Evitar duplicados de SPF.
- Revisar el selector DKIM.
- Confirmar la política DMARC.
- Esperar la propagación.
- Realizar consultas DNS externas.
Comprobaciones externas a la autenticación
- Revisar la reputación de IP.
- Revisar la reputación del dominio.
- Comprobar listas de bloqueo.
- Analizar rebotes.
- Revisar el contenido.
- Probar con varios proveedores.
- Confirmar que el destinatario espera el mensaje.
- Revisar la calidad de la lista.
- Verificar que ninguna cuenta esté comprometida.
- Comprobar los informes DMARC.
Seguir este orden permite separar los problemas de autenticación de los problemas de reputación o contenido.
La entregabilidad debe formar parte del mantenimiento del dominio
Email Deliverability de cPanel permite detectar errores en algunos de los registros más importantes para la autenticación del correo.
Desde esta herramienta podemos revisar SPF, DKIM, DMARC y determinados problemas relacionados con PTR. Cuando cPanel controla la zona DNS, también puede reparar automáticamente algunas configuraciones.
Si el dominio utiliza DNS externos, tendremos que copiar los valores sugeridos y publicarlos en el proveedor autoritativo. Para modificar el PTR, normalmente será necesario contactar con el proveedor responsable de la dirección IP.
En mi experiencia, la mayor ventaja de Email Deliverability no consiste únicamente en reparar registros. Su verdadero valor está en permitirnos detectar un problema antes de que afecte a la comunicación con clientes.
Una propuesta comercial que no llega, una factura filtrada como spam o una respuesta de soporte rechazada pueden provocar pérdidas de tiempo y oportunidades.
También debemos recordar que la autenticación es solo una parte de la entregabilidad. Aunque cPanel muestre todos los registros como válidos, todavía tendremos que cuidar la reputación, el contenido, las listas, los rebotes y el volumen de envío.
No considero Email Deliverability una solución mágica. La considero el primer lugar que deberíamos revisar cuando un dominio tiene problemas para entregar sus mensajes.
Dedicar unos minutos a comprobar SPF, DKIM, DMARC y PTR puede evitar muchas horas intentando descubrir por qué los clientes no reciben nuestros correos.
Dudas de la comunidad
¿Qué es Email Deliverability en cPanel?
Es una herramienta que analiza la configuración de autenticación del correo de los dominios asociados a una cuenta cPanel. Permite revisar registros como SPF, DKIM y DMARC, además de mostrar determinadas incidencias relacionadas con PTR.
¿Qué diferencia existe entre SPF, DKIM y DMARC?
SPF indica qué servidores están autorizados para enviar mensajes en nombre del dominio. DKIM añade una firma digital que permite comprobar la autenticidad y la integridad del correo. DMARC define cómo deberían tratarse los mensajes que no superan correctamente la autenticación o la alineación.
¿Qué significa que un dominio aparezca como válido?
Significa que cPanel no ha detectado errores evidentes en los elementos que analiza. No garantiza que todos los mensajes lleguen a la bandeja de entrada, ya que también influyen la reputación, el contenido, los rebotes y el comportamiento de envío.
¿Por qué mis correos llegan a spam aunque SPF y DKIM sean correctos?
La causa puede estar en la reputación de la IP o del dominio, el contenido, los enlaces, el volumen de envío, las quejas, los rebotes o la calidad de la lista de destinatarios.
¿Qué hace la opción Reparar de cPanel?
Intenta instalar automáticamente los registros recomendados cuando el servidor controla la zona DNS del dominio y dispone de permisos para modificarla.
¿Cuándo debo utilizar la opción Administrar?
Cuando necesites revisar la configuración actual, consultar el valor sugerido, copiar registros para un proveedor externo o entender el problema antes de aplicar cambios.
¿Puedo reparar los registros si utilizo DNS externos?
Sí, pero normalmente no podrás hacerlo automáticamente desde cPanel. Tendrás que copiar los registros sugeridos y añadirlos en el panel del proveedor que administra los nameservers autoritativos.
¿Puede cPanel modificar el registro PTR?
No siempre. El PTR suele depender del proveedor que controla la dirección IP. En muchos casos será necesario contactar con el proveedor de hosting o de infraestructura.
¿Cuánto tardan en aplicarse los cambios DNS?
Depende del TTL, de las cachés y del proveedor DNS. Algunos cambios se reflejan rápidamente, mientras que otros pueden tardar varias horas.
¿Email Deliverability garantiza que los correos lleguen a la bandeja de entrada?
No. Ayuda a corregir la autenticación del dominio, pero la decisión final también depende de la reputación, el contenido, la interacción de los destinatarios y las políticas del proveedor receptor.
Opinión Personal
La entregabilidad del correo electrónico debería revisarse con la misma frecuencia que las copias de seguridad, las actualizaciones o la seguridad de una página web. No sirve de mucho preparar un presupuesto, responder a un cliente o enviar una factura si el mensaje termina en spam o es rechazado por el servidor receptor.
La herramienta Email Deliverability de cPanel facilita mucho esta tarea porque permite comprobar desde un único lugar si existen problemas con SPF, DKIM, DMARC o PTR. Para quienes no trabajan habitualmente con registros DNS, disponer de un diagnóstico claro y de valores recomendados supone un ahorro considerable de tiempo.
Aun así, considero importante no confiar únicamente en que cPanel muestre todos los registros como válidos. La autenticación es una parte esencial, pero la reputación de la IP, la calidad de los destinatarios, el contenido de los mensajes y las prácticas de envío también influyen en el resultado final.
En mi experiencia, revisar estos elementos antes de que aparezca un problema puede evitar malentendidos, retrasos y oportunidades comerciales perdidas. Unos minutos de mantenimiento preventivo pueden ahorrar muchas horas intentando descubrir por qué los clientes no están recibiendo nuestros correos.
¿Has tenido problemas con correos que llegan a spam o mensajes rechazados a pesar de tener SPF y DKIM configurados? Cuéntanos tu experiencia en los comentarios y comparte qué solución te funcionó.
