El error 550 “Access denied – Invalid HELO name” aparece cuando un servidor de correo rechaza la identificación que recibió al comenzar una conexión SMTP. No suele indicar un problema con el texto del mensaje ni con la dirección del destinatario: la conversación se detuvo antes de que el envío pudiera avanzar normalmente.
Para resolverlo correctamente hay que determinar quién presentó el HELO o EHLO inválido: tu programa de correo, un sitio web que envía mensajes, el servidor de tu proveedor o un servidor externo. Esa distinción evita modificar configuraciones que no están relacionadas con el rechazo.
Qué son HELO y EHLO
SMTP utiliza los comandos HELO o EHLO para que el sistema que inicia la conexión se identifique. EHLO es la variante extendida y permite anunciar funciones como autenticación y cifrado. De acuerdo con el estándar SMTP, el cliente debe enviar uno de estos comandos antes de iniciar la transacción del mensaje.
La identificación debe tener un formato válido, normalmente un nombre de host completo como servidor.ejemplo.com. Un nombre vacío, una palabra local como localhost, caracteres no admitidos o una dirección IP escrita con una sintaxis incorrecta pueden provocar el rechazo.
Primero identificá dónde ocurrió el error
Guardá el rebote completo, la fecha, la hora, el remitente y el destinatario. El texto que acompaña al código 550 suele mostrar qué servidor emitió la respuesta. Después comprobá el escenario:
- Falla al enviar desde Outlook, Thunderbird o un teléfono: revisá el servidor SMTP, el puerto, el cifrado y la autenticación de la cuenta.
- Falla solamente desde un formulario o aplicación: verificá que el sitio use un servidor SMTP real y autenticado, no una conexión improvisada con un nombre local.
- Falla para todos los usuarios y destinos: el hostname o la configuración saliente del servidor puede ser incorrecta.
- Falla únicamente hacia un proveedor: ese receptor puede aplicar una validación más estricta o haber detectado otra inconsistencia relacionada.
Qué revisar en un cliente de correo
- Confirmá que el servidor saliente sea el indicado por tu proveedor, por ejemplo
mail.tudominio.como el hostname protegido por el certificado. - Usá el nombre de usuario completo, incluida la parte posterior a la arroba.
- Activá la autenticación SMTP. No supongas que recibir correo correctamente significa que el servidor saliente también está bien configurado.
- Elegí el puerto y el tipo de cifrado que figuran en “Connect Devices” o “Configurar cliente de correo” dentro de cPanel. Las opciones seguras SSL/TLS son las recomendadas.
- Eliminá configuraciones antiguas o duplicadas si el programa continúa intentando usar un servidor anterior.
Si el inconveniente ocurre en Outlook, seguí también la guía No puedo enviar correos desde Outlook: causas y solución.
Qué debe revisar el administrador del servidor
En un VPS o servidor dedicado, comprobá que el hostname sea un nombre de dominio completo y que resuelva a la IP pública utilizada para enviar. También conviene verificar el registro PTR o DNS inverso de esa IP y la configuración de HELO saliente de Exim. En servidores cPanel, el archivo de configuración correspondiente puede asignar el nombre utilizado por cada dominio, pero no debería editarse sin conocer la arquitectura del servicio.
El nombre presentado, el hostname, la resolución directa y el PTR no necesitan ser idénticos en todos los diseños, pero deben ser coherentes y administrados. Un hostname inexistente, privado o sin resolución pública puede reducir la confianza y activar controles del receptor.
Si el mensaje sale desde WordPress o una aplicación
Un sitio puede enviar mediante la función de correo local del servidor o mediante SMTP autenticado. Para diagnosticar, compará un envío desde Webmail con otro desde el formulario:
- Si Webmail funciona y el formulario falla, revisá el plugin SMTP, las credenciales y el servidor configurado en la aplicación.
- Si ambos fallan con el mismo rechazo, pedí al proveedor que revise el hostname y los registros de Exim.
- Si el sitio se conecta a un servicio externo, verificá la documentación de ese servicio; no copies los parámetros del correo cPanel si el proveedor usa otros.
Cómo verificar el resultado en cPanel
En Correo electrónico → Track Delivery podés buscar por destinatario y comprobar si Exim aceptó el mensaje, lo entregó o recibió una respuesta remota. La herramienta muestra la ruta y el detalle disponible para los envíos de la cuenta. Consultá la guía de Track Delivery en cPanel para interpretar cada resultado.
Si administrás WHM o el servidor, correlacioná la hora del intento con los registros principal y de rechazos de Exim. El rebote visible para el usuario puede resumir el problema; el registro suele permitir identificar el host que se presentó y en qué etapa se produjo el rechazo.
Qué no conviene hacer
- No desactives globalmente la exigencia de un HELO válido como primera medida.
- No agregues una IP a listas de confianza sin comprobar quién la utiliza.
- No cambies SPF, DKIM o DMARC al azar: esos registros son importantes para la autenticación, pero no corrigen por sí solos una sintaxis HELO inválida.
- No pruebes repetidamente con la misma configuración; demasiados errores pueden activar protecciones adicionales.
Lista rápida de resolución
- Conservá el error 550 completo y la hora exacta.
- Probá enviar desde Webmail para separar un problema de cliente de uno del servidor.
- Revisá servidor saliente, puerto, TLS, usuario completo y autenticación.
- Si falla el servidor, verificá hostname, DNS directo, PTR y HELO de Exim.
- Repetí una única prueba y confirmá el resultado en Track Delivery o en los logs.
Cuando el hosting es administrado, la corrección del hostname, del PTR o del HELO saliente corresponde al proveedor. Enviarle el rebote completo y la hora del intento permite resolver el caso mucho más rápido que informar solamente “no puedo enviar”.
