Problemas al enviar correo externo – códigos SMTP

Trabajando en soporte y administración de Exchange es frecuente recibir consultas sobre errores de envío de correo a otras organizaciones.

En general esto se presenta de la siguiente manera:

  1. El usuario “x” envía un correo externo
  2. “x” recibe un NDR (Non Delivery Report) con un código de error
  3. “x” reporta el problema a soporte
  4. Soporte quiere entender si el error es de su plataforma o de la del destinatario

Los NDRs son mensajes de sistema que reportan el estado de la entrega de un mensaje al remitente, estos se generan cuando un mensaje por algún motivo no puede ser entregado y en general entran en una de las siguientes categorías:

Códigos 5.x.x – Los códigos que empiezan por 5 representan fallas permanentes, es decir que requieren intervención.

Códigos 4.x.x – Los códigos que empiezan por 4 se asocian a fallas temporales y podrían o no requerir intervención.

Entender con precisión por donde viene el problema puede implicar actividades complementarias que van más allá de revisar el NDR, tareas de rastreo de mensajes, revisión de registros en DNS como PTR y SPF y chequeo de sitios de listas negras entre otros.

Independientemente de esto, el código de error SMTP nos da rápidamente una idea de lo que puede estar sucediendo. Estos códigos pueden ser vistos dentro del mismo NDR o en caso de no contar con uno disponible en los logs de protocolo SMTP o por ejemplo reproduciendo la comunicación con telnet.

Dentro de los códigos existentes tenemos de varios tipos y dado que no siempre el servidor destino utiliza Exchange pueden haber algunas variantes dentro de los errores devueltos.

En esta entrada en particular vamos a enfocarnos en los más usuales incluyendo una breve descripción que facilite la evaluación de si el problema “es nuestro” o “del otro lado”.


550 5.1.1 – Bad Destination Address / The email account that you tried to reach does not exist / RESOLVER.ADR.RecipNotFound / No such User / Recipient Rejected / The email account that you tried to reach does not exist / Service unavailable; Client host blocked

Este error se puede deber a múltiples causas pero lo importante es que el servidor que recibió el correo no tiene una casilla asociada a la dirección de correo del destinatario.

En general esto se reduce a:

  • El usuario ingreso incorrectamente la dirección del destinatario
  • El destinatario ya no existe en la organización de correo
  • La dirección cacheada en Outlook no es la correcta
  • Se está utilizando un registro MX desactualizado

En definitiva, no es un problema con la configuración de nuestro servidor de correo.


550 5.7.1 – Delivery not authorized / Unable to relay / Client was not authenticated / Your email messages have been blocked by reputation service / mx.google.com #550-5.7.1 [2002:xxxx:xxxx::xxxx:xxxx] Our system has detected that this message 550-5.7.1 does not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication.

En general el error 5.7.1 esta asociado a algún tipo de configuración de seguridad del servidor del destinatario.

Dependiendo de la información completa en el NDR el problema se puede deber a:

  • No se cuenta con permisos para enviar al destino
  • El servidor destino no esta configurado para recibir correo anónimo
  • Error de ruteo de mensaje (podría ser un registro MX incorrecto)
  • Registro SPF del remitente configurado de forma erronea
  • La dirección IP que utiliza el servidor del remitente esta dentro de una lista negra
  • En el caso puntual del error de IPV6 estaría faltando crear un registro PTR

En este situación el problema puede estar tanto del lado del remitente como en el servidor de destino.

Por ejemplo, si estamos enviando a un grupo y el administrador de la organización destino no habilito que recibiera de forma anónima tendríamos un error de este tipo. En este caso habría que ponerse en contacto con el administrador de la organización externa.

En otro escenario se podría dar que nuestra IP este en listas negras por lo que sería conveniente chequear esto primero. Un buen sitio para esto podría ser mxtoolbox.com.


4.4.1 The recipient´s server is not responding / Connection timed out / Connection refused

Este error se debe a que el servidor destino no responde.

Esto puede ser por:

  • Problemas temporales a nivel de conectividad (ya sea en origen o destino)
  • Permisos en firewall

En principio este error es temporal y el servidor va a reintentar la comunicación durante el tiempo configurado.

En este caso sería recomendable probar la comunicación con telnet desde el servidor que envía correo hacia internet.


400 4.4.7 Message delayed / Remote Server returned ‘550 4.4.7 QUEUE.Expired; message expired’

En general este tipo de errores tienen relación con el destino, en este caso habría que verificar con cuantos dominios de correo nos esta sucediendo.

Este tipo de error se puede deber a:

  • Errores temporales de conectividad en el destino
  • Configuración de antispam en destino
  • Registros MX o SPF incorrectamente configurados en orígen

Luego del error 400 4.4.7 el servidor seguirá reintentando el envío en base a su configuración. Si luego del tiempo configurado esto no es posible devuelve un error permanente 550 4.4.7.


4.4.2 delivery temporarily suspended: lost connection with SERVER while sending RCPT TO / lost connection with SERVER while receiving the initial server greeting / The connection was dropped during transmission.

En este caso el servidor se conectó correctamente al destino y comenzó con el envío del mensaje, sin embargo en algún punto la comunicación fue interrumpida.

Si bien esta situación puede ser temporal, el problema puede ser del origen o del destino. Si el error se presenta al enviar a un dominio en particular o en casos aislados seguramente el problema este en el destino, si comenzamos a ver que se incrementan estos reportes el problema puede ser en el origen, ya frente esta situación habría que evaluar conectividad del servidor, ya sea placa de red, routers, firewall, etc.


Con esto llegamos al final del artículo, por información teórica y práctica sobre configuración de transporte y resolución de problemas en Exchange, ver los siguientes recursos para miembros VIP del sitio (videos de entrenamiento):


About Daniel Núñez Banega

Consultor IT especializado en Microsoft Exchange, Active Directory y Microsoft 365.
Principales Certificaciones: Microsoft Certified Trainer | Microsoft Certified Solutions Expert | Microsoft Certified Systems Engineer | Microsoft Certified Systems Administrator | Microsoft Certified IT Professional | Microsoft Certified Technology Specialist | Microsoft 365 Certified: Enterprise Administrator Expert | Microsoft 365 Certified: Security Administrator Associate | Microsoft Certified: Cybersecurity Architect Expert | Comptia Pentest+ | EC-Council Certified Ethical Hacker Master

Reader Interactions

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *