Hay muchas posibilidades involucradas con este error. Tomado de esta respuesta mía en otra pregunta (pero ligeramente modificada):
Primero, intente establecer una sesión SMTP con los servidores de correo remotos usando telnet para ver si puede obtener más información.
También es posible que se haya establecido algún tipo de regla de firewall extraño que descarte, altere o modifique los paquetes hacia o desde un dominio o IP asociado con el servidor remoto. Improbable, pero he visto cosas más extrañas. Verifique el firewall de su puerta de enlace, así como el firewall del software del servidor de Exchange, para ver si hay alguna regla que pueda tener algo que ver con el servidor SMTP remoto. Compruebe dominios, direcciones IP y cualquier rango de direcciones que puedan estar asociadas con el dominio remoto.
Otra pequeña posibilidad es que el dominio remoto tenga problemas de zona DNS. Quizás sus registros MX están rancios. Tal vez realizaron una migración de zona pero nunca migraron todo al nuevo servidor DNS. Nuevamente, han sucedido cosas más locas.
Otra posibilidad es que el servidor receptor esté realizando una búsqueda DNS inversa en su IP de envío y no coincida con sus registros MX. Si el registro MX apunta a 192.0.2.1, pero está detrás del firewall que es 192.0.2.2 y se configura una IP virtual en el firewall para aceptar 192.0.2.1, entonces el tráfico saliente se verá como 192.0.2.1, pero RDNS sí lo hará. muestre 192.0.2.2 como el servidor de correo. Esa discrepancia puede hacer que algunos servidores de recepción rechacen el mensaje de varias maneras (aunque espero que el administrador del correo electrónico del destinatario no suprima los mensajes informativos de devolución, sino que opte por mensajes genéricos de falla).
(Como nota al margen, las comprobaciones de RDNS como las anteriores son una tontería, ya que muchas personas tienen relés autenticados para el correo electrónico saliente y eso, por necesidad, no coincidirá con el servidor entrante. ¡Administradores de correo electrónico, no sean perezosos!)
Por último, pero ciertamente no menos importante, ¡USE REGISTROS SPF! DKIM también. Es posible que muchos de sus problemas de correo electrónico transitorios simplemente desaparezcan después de configurar correctamente esas dos cosas.
Por supuesto, escuche a Shane Madden y revise su cola de correo .
Al final, contacta a los administradores del dominio remoto y resuélvelo con ellos . Puede que tenga que trabajar con ellos para resolver el problema.
Verifique su cola de correo en la sección "Caja de herramientas" de la consola de administración de Exchange.
Podrá profundizar en los errores específicos que se generan cada vez que se intenta entregar el mensaje, lo que debería arrojar algo de luz sobre la causa raíz. Encuentre un mensaje de problema específico en una cola de dominio, luego haga clic derecho en el mensaje y abra las propiedades; la
Last Error
sección " " es lo que interesa.Las causas probables son la conectividad del puerto 25 / tcp y los problemas de resolución de DNS, pero edite los errores que encuentre en la pregunta si todavía tiene problemas y podemos ayudarlo a determinar la causa raíz.
fuente
Sin más información, esto no parece extraño. Algunos servidores del destinatario implementan controles de límite de velocidad que evitan la inundación de sus servidores. Algunos mensajes pasan de inmediato, otros tienen que esperar (y lo intentan más tarde).
Si este problema es cierto para más del (digamos) 10% de sus correos, entonces tiene problemas con la resolución de DNS, su firewall interno u otras configuraciones de red extrañas que impiden el flujo de correo en su sitio.
Pero esto no tiene absolutamente nada que ver con su configuración MX.
fuente
Otra nota, específicamente para los dominios de aol.com, si su empresa les enviará mucho correo (no sé cuál es el umbral para que comiencen a ponerlo en la lista negra), debe registrar su nombre de dominio con un contacto de administrador de correo en este sitio web: http://postmaster.aol.com/Postmaster.Whitelist.php
fuente
El DNS que estaba configurado en mi servidor de Exchange había sido retirado. Traté de hacer ping a un par de dominios de correos retrasados y no recibí ninguna resolución.
Entré en la configuración de mis redes en el servidor y actualicé el DNS primario y secundario.
Todo comienza a fluir bien de nuevo.
Espero que esto ayude
fuente