¿Puedo arreglar el 550 5.4.1 desde mi lado?

Solo si la dirección estaba mal escrita. El rechazo lo hace el tenant de Microsoft 365 que recibe, a partir de su propio directorio, así que una dirección correcta que sigue rebotando la tiene que arreglar el administrador de ese lado. Lo que sí puedes hacer es definir el alcance, confirmar dónde está alojado el correo del dominio y demostrar que tu autenticación está limpia.

¿El 550 5.4.1 significa que estoy bloqueado o en una lista negra?

No. El bloqueo en el borde basado en directorio rechaza el mensaje porque la dirección del destinatario no es válida en esa organización, antes de cualquier filtrado de spam. Un problema de reputación o de autenticación aparece con otro código, casi siempre de la familia 5.7.x. Este rebote habla de la dirección, no del remitente.

¿Por qué el correo interno funciona y los remitentes de afuera reciben el rebote?

El correo entre cuentas del mismo tenant nunca pasa por el perímetro del servicio, que es donde ocurre la revisión del destinatario. Por eso una migración puede verse terminada desde adentro mientras clientes y proveedores siguen recibiendo 5.4.1 por alias, buzones compartidos o grupos que nadie volvió a crear. Prueba siempre desde una cuenta externa.

550 5.4.1 recipient address rejected: causa y solución

Imagina una agencia de logística de 14 personas que escribe a un cliente nuevo en una empresa que usa Microsoft 365. La dirección salió de una tarjeta de presentación. La respuesta llega en menos de diez segundos y no es del cliente:

550 5.4.1 Recipient address rejected: Access denied. AS(201806281)

"Access denied" suena a problema de permisos, así que el primer impulso es culpar a un filtro de spam, a una lista negra o a un firewall, y empezar a reescribir el registro SPF. Nos llaman justo en ese punto más seguido de lo que nos gustaría. Este rebote no tiene nada que ver con tu autenticación ni con tu reputación. Es el lado que recibe diciendo que no tiene ese destinatario.

Qué te está diciendo el rebote

Microsoft 365 revisa la dirección del destinatario antes de aplicar cualquier filtrado. La función se llama bloqueo en el borde basado en directorio y la descripción de Microsoft es directa: rechaza los mensajes para destinatarios inválidos en el perímetro de la red del servicio, el mensaje se bloquea antes de que el filtrado ocurra y se devuelve un informe de no entrega al remitente.

De ahí salen dos conclusiones. Tu mensaje nunca llegó a un buzón, a una regla de transporte ni a una cuarentena, así que no hay nada que el destinatario pueda buscar y liberar. Y la decisión salió del directorio de la organización que recibe, no de algo tuyo: recibes el mismo rebote si envías desde Google Workspace, desde Microsoft 365, desde un CRM o desde el script de pedidos de una tienda.

Ignora el código entre paréntesis al final de la línea. Las dos partes que importan son el código de estado y la dirección que nombra.

Cuál 550 tienes enfrente

La mayor parte de las horas que se pierden con los rebotes vienen de tratar todos los 550 igual. Identifica la cadena exacta que recibiste y después decide si el siguiente paso te toca a ti.

Rebote que recibiste	Qué decidió el lado que recibe	Quién lo puede arreglar
`550 5.4.1 Recipient address rejected: Access denied`	Microsoft 365 no encontró un destinatario válido para esa dirección y la rechazó en el perímetro	El administrador que recibe, o tú si es un error de tipeo
`550 5.1.10 RESOLVER.ADR.RecipientNotFound`	La búsqueda de la dirección falló dentro de la organización que recibe, síntoma común en entornos híbridos	El administrador que recibe
`550 5.1.1 The email account that you tried to reach does not exist`	Gmail no tiene esa cuenta en ese dominio	El administrador que recibe, o tú si es un error de tipeo
`550 5.4.6 mail for example.com loops back to myself`	Un servidor de correo cree que es dueño del dominio y no tiene buzón local para la dirección	Quien administra ese servidor, con frecuencia un hosting tuyo anterior
`550 5.7.1` o `550 5.7.26`	Tu autenticación o tu reputación de envío, no la dirección	Tú

Solo la última fila es tu problema en el sentido habitual. Las demás son problemas de ruteo y de directorio, y tres están del otro lado de la barda. Eso cambia cómo se ve una hora bien usada: estás juntando evidencia para el administrador de alguien más, no ajustando tu propio DNS.

Qué revisamos primero, en orden

Esto toma unos diez minutos y deja resuelto de quién es el problema.

Lee la dirección letra por letra. No el nombre que se muestra, la dirección que aparece en el rebote. Letras invertidas, un .com que debía ser .com.mx, un espacio pegado desde un PDF, una I mayúscula donde va una l minúscula. Sigue siendo la causa más común y descartarla no cuesta nada.
Define el alcance. Manda un mensaje corto a otra dirección del mismo dominio, de preferencia una publicada en su sitio. Si rebotan todas las direcciones del dominio, el problema está en cómo está configurado ese dominio. Si rebota solo una, el problema es ese destinatario.
Confirma a dónde va de verdad el correo del dominio. Un dominio cuyo MX apunta a los hosts de mail protection de Microsoft es un tenant de Microsoft 365, y la explicación del 5.4.1 aplica. Si el MX apunta a otra parte, la conversación es distinta.
Descarta tu propio lado antes de escalar. Ningún administrador se mueve rápido por un remitente que no puede demostrar que su autenticación está limpia. Revisa SPF, DKIM, DMARC y MX en tu dominio primero, para que el mensaje que le mandes a su área de sistemas sea corto y creíble.

dig +short MX dominiodelcliente.com
# 0 dominiodelcliente-com.mail.protection.outlook.com.

El cuarto paso es el que ahorra más tiempo. Revisa tu propio dominio en el verificador antes de escribirle a nadie, para que la nota que mandes al otro lado diga en una línea que tu SPF, DKIM, DMARC y MX están limpios y que el rechazo salió de su directorio.

El arreglo cuando afecta a una sola dirección

Cuando rebota un solo destinatario y el resto del dominio funciona, algo en ese objeto de destinatario está mal o quedó viejo. Puede ser que la dirección ya no exista, y eso el área de sistemas del cliente te lo responde en dos segundos. Si existe, la guía de Microsoft para un buzón afectado en un entorno híbrido es restablecer la dirección proxy SMTP del destinatario: cámbiala a una dirección temporal y después regrésala, lo que obliga al directorio a publicarla de nuevo. Las carpetas públicas habilitadas para correo se revisan igual, confirmando que la carpeta sí se sincronizó a Exchange Online.

Lo que descuadra a la gente son los tiempos. Microsoft indica que hay que esperar hasta 24 horas para que el bloqueo en el borde basado en directorio se actualice por completo. Un administrador que hace el cambio, prueba tres minutos después y ve el mismo rebote suele concluir que no funcionó y lo revierte. Haz un cambio, anota la hora y vuelve a probar después de ese plazo.

El arreglo cuando afecta a todo el dominio

Cuando rebotan todas las direcciones del dominio, revisa el tipo de dominio aceptado en el tenant que recibe, en Flujo de correo y luego Dominios aceptados. Microsoft define con claridad las dos opciones que importan. Un dominio autoritativo significa que la organización es completamente responsable de entregar el correo a los destinatarios del dominio y de generar los informes de no entrega, y el correo para destinatarios desconocidos se rechaza. Un dominio de retransmisión interna no es autoritativo: la organización recibe el correo pero lo retransmite a un sistema de correo externo bajo su control, y ese sistema externo es el responsable de generar los informes de no entrega para los destinatarios que no se resuelven.

El paso de reparación de Microsoft para un caso que afecta a todo el dominio es resincronizar el directorio cambiando el dominio aceptado de autoritativo a retransmisión interna y de vuelta a autoritativo. En el centro de administración son dos clics en la misma pantalla. Desde PowerShell es un comando por cada lado:

Set-AcceptedDomain -Identity "dominiodelcliente.com" -DomainType InternalRelay
Set-AcceptedDomain -Identity "dominiodelcliente.com" -DomainType Authoritative

Una advertencia, porque ya hemos limpiado el resultado: dejar el dominio en retransmisión interna no es un arreglo. La instrucción de Microsoft es no elegir esa opción cuando todos los destinatarios del dominio están en Microsoft 365, y la razón es que deja de rechazar direcciones desconocidas en el perímetro y se las entrega a un sistema que puede que ya no exista. El síntoma desaparece y el correo a direcciones mal escritas deja de producir un rebote que alguien lea.

La trampa de las migraciones

La versión que más vemos no es un error del servicio, es una migración que se dio por terminada demasiado pronto. El consejo de Microsoft para armar el tenant es poner el dominio aceptado en retransmisión interna mientras lo construyes, agregar a todos los destinatarios previstos, dejar que se replique y solo entonces pasar el dominio a autoritativo.

Si pasas a autoritativo una noche antes de tiempo, el directorio se convierte en la reja. Los buzones del personal ya están ahí, así que el correo interno se ve perfecto y la migración se declara exitosa. Las direcciones que nadie reconstruyó son las que empiezan a rebotar hacia afuera: el buzón compartido que está en la plantilla de facturas, el grupo de distribución que usa la bodega, dos alias del buzón de la recepcionista anterior, el contacto de una contadora que no está en el tenant. Los clientes y proveedores reciben el 5.4.1. La empresa no se entera, porque el rebote llega al remitente, no al destinatario.

La imagen espejo es igual de frecuente: un dominio que quedó como dominio aceptado autoritativo en un tenant viejo que nunca se dio de baja, todavía respondiendo por direcciones que se movieron hace años.

Qué vigilar después

Una vez corregido el destinatario o el tipo de dominio, prueba desde fuera de la organización, no desde una cuenta del mismo dominio, porque el correo interno nunca pasa por la revisión del perímetro. Después recorre la lista de direcciones que la empresa publica de verdad, no la lista del personal: la de la página de contacto, la de las facturas y cotizaciones, la del perfil de empresa, los alias de ventas y cobranza, la dirección a la que la tienda en línea manda los avisos de pedido. Cada una es un camino que usa un cliente y cada una puede fallar por su cuenta.

Guarda los mensajes de rebote hasta que tengas una prueba limpia. Traen la dirección exacta y la hora, que es lo que permite reconstruir si un cambio funcionó en lugar de discutirlo.

Cómo ayuda Guanacos Tech

Casi todo el trabajo en un 5.4.1 es demostrar dónde ocurrió la falla para que la persona correcta invierta los diez minutos correctos. Leemos el rebote, revisamos el ruteo del dominio que recibe, descartamos o confirmamos tu propia autenticación y te damos un párrafo corto que puedes enviarle al área de sistemas del otro lado, o hacemos el cambio nosotros si el tenant es uno que administramos. Es parte de nuestra consultoría de entregabilidad de correo y aparece todo el tiempo en las semanas siguientes a una migración de buzones. Agenda una llamada de 30 minutos y trae un rebote con encabezados completos; con eso normalmente alcanza para decirte de quién es este cambio.

550 5.4.1 "Recipient address rejected: Access denied": por qué rebota una dirección correcta