Un email rebota con el código 550 5.4.1 en un cliente de Microsoft 365 aunque SPF, DKIM y DMARC den PASS. ¿Por qué? La respuesta cabe en una frase: la dirección del destinatario no existe en el directorio del servidor que recibe el mensaje, o el acceso a ella está denegado de forma explícita. Es un rechazo de directorio, no de sender reputation. Y detrás hay 4 causas posibles: una dirección aislada y un dominio completo no se tratan igual.
En Exchange Online, esta respuesta suele venir del Directory-Based Edge Blocking, un mecanismo que descarta las direcciones inválidas antes de mirar el contenido del mensaje. Ahí se atascan muchas campañas: tu CMO pregunta por qué baja el open rate, tu herramienta de emailing muestra una configuración técnica impecable y el NDR (Non-Delivery Report) no se entiende si no sabes leer su texto exacto.
Qué significa el código 550 5.4.1
550 es un código de estado permanente (clase 5yz de la RFC 5321, de octubre de 2008): el servidor no vuelve a intentar el envío, a diferencia de los errores 4xx temporales, que según la misma RFC se reintentan durante al menos 4 o 5 días. El subcódigo 5.4.1 (Enhanced Status Code de la RFC 3463, de enero de 2003) indica un problema de enrutamiento o de acceso en el lado del destinatario, no de contenido ni de blocklist. Esa es la diferencia con el 550 5.7.1, donde el rechazo viene de una política de filtrado o de una reputación de remitente deteriorada. Aquí, el intercambio EHLO y MAIL FROM pasó sin problemas y el comando RCPT TO se aceptó sintácticamente. La dirección se rechazó al resolverla en el directorio. Para ver las familias de códigos 4xx y 5xx de un vistazo, la taxonomía completa de los errores SMTP da el marco general.
Buzón eliminado o nunca creado: el caso más frecuente
El NDR muestra «550 5.4.1 Recipient address rejected: Access denied». La dirección nunca existió en el directorio de Exchange Online, o se eliminó tras una baja o el cierre de una cuenta. Ningún reintento cambia el resultado: el destinatario no existe en el lado receptor.
Lo primero es comprobar la ortografía exacta de la dirección, porque un dominio mal copiado basta para provocar este rechazo. Si la dirección es correcta y el rechazo dura varios días, está muerta. Suele ser de un antiguo contacto o de un puesto suprimido, y a menudo llega heredada de una importación de CRM que nadie actualizó.
Dominio aceptado mal configurado como Internal Relay o Authoritative
Un síntoma distingue esta causa: el rechazo afecta a todos los destinatarios de un mismo dominio, no a una sola dirección. En Exchange Online, un dominio aceptado puede ser Authoritative (el directorio de M365 es la fuente de verdad y DBEB rechaza cualquier dirección ausente) o Internal Relay (parte de los buzones vive en otro sitio y el flujo sigue hacia otro sistema mediante un conector).
El problema aparece sobre todo en entornos híbridos: el tenant de Microsoft 365 está como Authoritative mientras siguen existiendo buzones en un servidor Exchange local no sincronizado del todo. Exchange Online rechaza entonces direcciones perfectamente válidas porque no las encuentra en su directorio. Según Microsoft Learn, mientras se sincronizan los usuarios hay que mantener el dominio aceptado en Internal Relay. Solo se pasa a Authoritative cuando todos los destinatarios están en Microsoft 365.
Si el dominio ya debería estar bien y aun así rebotan direcciones válidas, el administrador suele hacer esto: cambiar el dominio aceptado de Authoritative a Internal Relay en el centro de administración de Exchange (Flujo de correo > Dominios aceptados), guardar y volver a Authoritative. En PowerShell, el mismo cambio se hace con el cmdlet Set-AcceptedDomain y su parámetro -DomainType. Así Exchange Online reaprovisiona el estado del directorio y descarta una caché obsoleta.
Directory-Based Edge Blocking: el rechazo en la frontera antes de cualquier filtro
«Si la dirección no figura en el directorio, el servicio bloquea el mensaje antes incluso de que empiece el filtrado.» (documentación de Exchange Online, Microsoft Learn)
DBEB (Directory-Based Edge Blocking) rechaza las direcciones desconocidas en el perímetro de red del servicio, antes de que el mensaje entre en el pipeline antispam de Microsoft 365. No es lo mismo que un bloqueo de relay o un rechazo de conexión previo, que se trata aparte en el artículo sobre el error SMTP 554 5.0.0: ahí se rechaza la propia conexión. Aquí la conexión se establece y lo que falla después es la resolución de la dirección. En entornos híbridos, DBEB solo funciona si el registro MX del dominio apunta a Microsoft 365, precisa la misma página. Microsoft calcula entre 5 y 10 minutos para activarlo.
El NDR completo suele traer un código adicional: «550 5.4.1 Recipient address rejected: Access denied. AS(201806281)». Ese código identifica un rechazo DBEB y confirma que el bloqueo viene del directorio de Exchange Online, pero no explica por qué falta la dirección. Si aparece justo después de crear un buzón en un entorno híbrido, lo más probable es un retraso de sincronización entre el directorio local (Microsoft Entra Connect, el antiguo Azure AD Connect, renombrado en 2023) y Exchange Online: el buzón existe en local y el cambio aún no se ha replicado. Antes de buscar más lejos, el administrador fuerza un ciclo delta con Start-ADSyncSyncCycle -PolicyType Delta en el servidor de Entra Connect.
Alias o lista de distribución inactiva
Cuarto caso: la dirección rechazada es un alias o una lista de distribución desactivada. Un grupo de distribución eliminado y un alias retirado de un buzón compartido dan exactamente el mismo síntoma en pantalla. El caso más espinoso es el grupo de distribución dinámico on-premises en un entorno híbrido: por su estructura no puede sincronizarse con Exchange Online, por mucho que se espere.
La solución documentada para este caso es crear un contacto de correo en Exchange Online que reutilice la dirección externa del grupo dinámico local. Si solo se eliminó un alias, hay que volver a crearlo en el buzón de destino o avisar al remitente de que la dirección cambió.
Lo que el 550 5.4.1 revela sobre el estado de la lista
«Mis campañas acaban rechazadas y, sin embargo, mi herramienta de emailing muestra una configuración técnica perfecta»: lo dicen una y otra vez los responsables de growth o lifecycle que se topan con el 550 5.4.1 por primera vez. La tentación es revisar SPF, DKIM, IP warmup y sender reputation, como en cualquier rechazo clásico de deliverability. Con este código no sirve de nada: las 4 causas anteriores están en el lado del destinatario, en su directorio.
El reflejo SPF, DKIM, warmup viene de un buen hábito. Pero ningún ESP comprueba por defecto si la dirección sigue existiendo en el destinatario, solo si su formato es válido. Ese punto ciego es el que cubre una verificación de lista, sin añadir otra capa que vigilar a diario.
Una dirección eliminada, un alias muerto, un dominio entero mal configurado por falta de sincronización: en los 4 casos hay una lista con entradas muertas, y se acumulan rápido. CaptainVerify verificó 126 millones de direcciones en 2025 y solo el 57 % eran válidas. Además, una lista pierde cada año cerca del 23 % de sus direcciones válidas, según el análisis sobre lo que vale realmente una dirección de email.
Por eso conviene verificar la lista antes de enviar. Elimina la categoría de error entera sin tocar el DNS ni la configuración de Exchange: una dirección que ya no existe en el directorio del destinatario se detecta en la verificación, no en el bounce de una campaña ya enviada. Antes del próximo envío, basta pasar una muestra de la lista por una verificación para ver cuántas direcciones caerían en un 550 5.4.1, sin haber calentado la IP para nada. Es list hygiene, y se resuelve antes de cualquier trabajo sobre la infraestructura de envío.
Preguntas frecuentes
¿El 550 5.4.1 es lo mismo que el 550 5.7.1? No. El 5.4.1 señala un problema de enrutamiento o de acceso a la dirección en el directorio; el 5.7.1, una política de filtrado o una reputación de remitente deteriorada. Las correcciones no se parecen: en el directorio para uno, en la reputación para el otro.
¿Cuánto hay que esperar tras una resincronización del directorio híbrido? Microsoft Entra Connect sincroniza por defecto cada 30 minutos, según Microsoft Learn, y luego Exchange Online todavía tiene que procesar el cambio. Cuenta con unas horas antes de pensar en otra causa: reintentar antes da el mismo rechazo.
¿Un rechazo 550 5.4.1 hace subir mi hard bounce rate global? Sí. Cada ocurrencia cuenta como hard bounce, tanto en las estadísticas de tu herramienta de emailing como en las de los proveedores de correo de los destinatarios. Si se acumulan en una misma lista, deterioran la sender reputation aunque no haya ningún otro error de deliverability. Para un panorama más amplio del aumento de estos rechazos, el artículo sobre los rechazos SMTP y su aumento detalla cómo se deteriora la reputación.
