Cross-tenant recall: Exchange Online deja que otra empresa borre correo de tus buzones

A mediados de agosto Microsoft empieza a desplegar en Exchange Online una de las funciones más pedidas de los últimos años: recuperar un correo que ya has enviado a otra empresa. Leída desde el lado del remitente suena a red de seguridad. Léela desde el otro extremo del cable, que es donde estamos casi todos: a partir de ahora alguien de otra organización podrá hacer desaparecer un mensaje que ya está entregado en el buzón de tu gente. Y la casilla que lo permite no la activas tú para recuperar tus correos. La activas para que otros recuperen los suyos de tus buzones.

Escribimos esto desde el lado del que administra tenants de otros. Gestionamos entornos de Microsoft 365 para empresas, y sabemos cómo llega este tipo de novedad: casi nunca la pide un administrador. La pide un usuario que ha leído un titular, o la pide la matriz. Cuando llegue —y va a llegar— conviene tener la respuesta pensada, porque el aviso oficial es corto y las consecuencias no.

Lo que el recall ya hace hoy (y casi nadie ha vuelto a mirar)

Mucha gente tiene en la cabeza el recall de hace quince años: aquel mensaje que pedía por favor al Outlook del destinatario que retirase el correo, y que fallaba casi siempre. Ese ya no existe. Desde el recall en la nube, la petición la intercepta un agente dentro del propio servicio y la palabra que usa la documentación de Microsoft para lo que hace con el original es hard-delete: borrado duro del buzón del destinatario. No pide permiso al cliente de correo, no depende de que el destinatario tenga Outlook abierto y, según la misma página, el sistema sigue intentándolo hasta 24 horas.

Hay un detalle en esa página que merece leerse dos veces. El diálogo de Outlook sigue diciendo que solo se recuperan los mensajes no leídos, y la documentación lo desmiente con todas las letras: «esa afirmación ya no es exacta». Existe un ajuste de organización que decide si se pueden recuperar mensajes que el destinatario ya había leído, RecallReadMessagesEnabled, y su valor por defecto —vacío— equivale a activado. Traducido: hoy, dentro de tu organización, un compañero puede hacer desaparecer de tu buzón un correo que tú ya habías leído, y el aviso que ves en pantalla dice lo contrario de lo que hace el sistema.

Los dos interruptores que gobiernan todo esto llevan años ahí, en una sola orden:

Set-OrganizationConfig -MessageRecallEnabled $true -RecallReadMessagesEnabled $true
# valor por defecto: vacío, equivalente a $true en ambos

Todo esto ya estaba. Lo que cambia en agosto no es la potencia del recall: es de quién puede venir la orden.

Lo que cambia: MC1423106

El aviso del Centro de mensajes MC1423106 (identificador de hoja de ruta 561330) anuncia el cross-tenant message recall: hasta ahora el recall solo funcionaba entre buzones de la misma organización —de hecho, a día de hoy la documentación de Exchange Online sigue listando como limitación que «no puedes recuperar mensajes por internet ni entre organizaciones», junto con el correo hacia un Exchange local en escenarios híbridos: quien vaya a la página oficial va a leer lo contrario de lo que anuncia el aviso—, y a partir de este despliegue podrá cruzar la frontera entre tenants de Microsoft 365. Arranca a mediados de agosto de 2026 y se completa a primeros de septiembre, para clientes worldwide y también GCC, GCC High y DoD. Hay coberturas que sitúan la disponibilidad general algo más tarde; la fecha que manda es la de tu Centro de mensajes, no la de una noticia.

La parte bien hecha, y hay que reconocerla: llega desactivado y quien decide es quien recibe. Ningún remitente externo puede retirar nada de tus buzones si tú no has encendido la función y, además, has metido su identificador de tenant en una lista blanca. Se hace desde PowerShell de Exchange Online:

# 1) encender la función en TU tenant (el que recibe)Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled $true

# 2) autorizar tenants concretos a retirar correo de tus buzonesSet-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add="<tenantId1>","<tenantId2>"}

# 3) sacar a uno de la lista cuando se acaba la relaciónSet-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Remove="<tenantId1>"}

Si al ejecutar la primera orden tu consola no reconoce el cmdlet, no busques el fallo en el tenant: actualiza el módulo de Exchange Online Management, porque es nuevo y no está en las versiones anteriores. Si el tenant del remitente no está en la lista, su intento falla y él recibe el aviso de que la recuperación entre organizaciones no está disponible. El aviso añade otro detalle que conviene tener presente: si tienes activadas las notificaciones de recuperación al destinatario, también se aplican a los recalls que vienen de fuera. Es decir, tus usuarios van a empezar a recibir avisos raros de empresas ajenas, y alguien tendrá que explicárselo.

La asimetría: esa casilla no es para ti

Aquí está el punto que casi ninguna cobertura dice en voz alta, y es el que cambia la conversación entera. Activar la función en tu tenant no te sirve absolutamente de nada como emisor. Para que tu comercial pueda retirar el PDF con la lista de precios que acaba de mandar al cliente equivocado, quien tiene que encender la casilla y meter tu identificador de tenant en su lista blanca es el cliente. Tú, activándola, no ganas ninguna capacidad: solo la concedes.

Eso convierte esto en algo distinto de una función: es un favor. Y los favores no se evalúan preguntando «¿cómo se activa?», sino «¿a quién, por qué y qué pasa el día que quien tiene el favor no es quien yo creía?». Es exactamente la misma pregunta que nos hacemos con cualquier permiso concedido a un tercero dentro de un tenant; hace unos días escribíamos sobre los tokens de aplicaciones conectadas que no vuelven a pedir MFA, y el patrón mental es idéntico: lo que se concede una tarde sigue concedido dos años después, cuando ya nadie recuerda por qué.

El problema no es un desconocido: la lista blanca ya está escrita

Piensa un momento a quién meterías en esa lista. No a desconocidos: a la matriz, a las filiales, a la gestoría, al despacho que lleva la nómina, al proveedor de toda la vida. Es decir, exactamente los mismos remitentes que aparecen en el fraude del CEO y en el fraude de la factura, porque ese fraude no vive de engañar a nadie con un dominio raro, vive de la confianza que ya existe entre dos empresas que llevan años escribiéndose.

Conviene no dramatizar, porque el alarmismo también miente. Quien controla el tenant de tu proveedor tiene hoy jugadas mucho mejores que borrar correo: puede enviar correo haciéndose pasar por ellos, leer los hilos, cambiar un IBAN en una plantilla. Esto no le abre ninguna puerta nueva. Lo que le añade es una capacidad concreta que hasta ahora no tenía: retirar el mensaje después. Y esa es justo la parte que más molesta cuando toca reconstruir un incidente, porque un correo con una factura manipulada que desaparece del buzón el día que el pago ya ha salido no es lo mismo que uno que sigue ahí, con sus cabeceras, para que alguien lo mire con calma.

Hay un freno que juega a tu favor y que sale en la misma documentación: los mensajes reenviados a mano por el destinatario y los reenviados o redirigidos por una regla de bandeja de entrada no se recuperan. El reenvío automático dentro de la organización sí. Dicho de otro modo: la copia que tu usuario mandó al jefe pulsando «reenviar» sobrevive al borrado. Es un consuelo pequeño y depende del azar, pero explica bastante bien por qué el recall no es una máquina del tiempo.

Un borrado duro tampoco es el fin del mundo (durante 14 días)

Un borrado duro en Exchange Online no es una trituradora. Los elementos borrados de forma dura acaban en la subcarpeta Purges de Elementos recuperables cuando el buzón tiene recuperación de elemento único o retención por litigio activas, y la documentación dice, para los dos casos que nombra, que poner un buzón en in-place hold o en retención por litigio detiene el purgado automático del Asistente de carpetas administradas en las subcarpetas DiscoveryHolds, Deletions y Purges. Con una directiva de retención de Microsoft 365 el efecto es equivalente pero la carpeta es otra: ahí los elementos borrados en duro se conservan en DiscoveryHolds. Y la propia página del recall lo remata en su apartado de preguntas frecuentes: para buzones con retención por litigio o in-place hold, el mensaje recuperado sigue apareciendo en eDiscovery.

Un apunte de honestidad antes de seguir: la página del recall no dice a dónde va a parar el original recuperado. Eso sale de cruzarla con la de Elementos recuperables, y es lectura nuestra, no cita. Hecha esa salvedad, la conclusión operativa del artículo tiene un matiz que conviene no regalarse: hay una red puesta de serie, pero lleva reloj. La recuperación de elemento único viene activada por defecto en todo buzón nuevo de Exchange Online, así que el mensaje borrado en duro sigue en Elementos recuperables y un administrador puede sacarlo durante el periodo de retención de elementos eliminados: 14 días por defecto, 30 como máximo. Después no queda nada. De ahí sale la única instrucción práctica que le damos a un servicio de soporte con esto: cuando alguien diga «me ha desaparecido un correo», la búsqueda se hace esta semana, no el mes que viene. Y de ahí sale también para qué sirve de verdad una retención o un hold: no ponen la red, le quitan el reloj. Ojo, que eso no convierte la retención en una copia de seguridad —ya escribimos sobre por qué una política de retención de Purview no es un backup—, pero sí es la diferencia entre poder responder «lo tengo» y tener que decir «no lo sé». Es también la razón por la que el backup de Microsoft 365 deja de ser una discusión teórica el día que un tercero puede provocar un borrado en tus buzones sin pasar por ti.

El hueco que más nos chirría: el registro

En esa misma sección de preguntas frecuentes hay una respuesta de cuatro palabras que debería estar en negrita en el aviso y no lo está. A la pregunta de si los recalls aparecen en los registros de auditoría de buzón, la documentación contesta: «No, no por ahora». El sitio donde un administrador va a mirar cuando un usuario dice «me ha desaparecido un correo» es exactamente el sitio donde esto no consta.

Rastro hay, pero está en otro sitio y es más incómodo: el message trace registra el mensaje de recuperación, y el detalle del evento Drop es donde se lee si el borrado salió bien —con el matiz, muy poco intuitivo, de que el estado que muestra la traza es Failed tanto cuando el recall funciona como cuando expira, y hay que abrir el detalle para encontrar el Result:Success—. Es una comprobación de administrador con prisa a las nueve de la noche, no un panel. Y cuando el recall venga de fuera, la pregunta «¿quién ha borrado esto?» tendrá una respuesta que no está en tu tenant.

Cómo lo vamos a tratar en los tenants que gestionamos

Y una pregunta que dejamos abierta a propósito, porque no la hemos podido verificar: no está claro si el ajuste RecallReadMessagesEnabled del tenant que recibe gobierna también los recalls que llegan de fuera. Si lo gobierna, ponerlo en $false es un buen freno intermedio para quien quiera activar la función solo para mensajes aún no leídos. Si no lo gobierna, el freno no existe. Es de las cosas que preguntaremos antes de encenderlo en un tenant de cliente, y de las que no vamos a suponer.

Cuándo NO lo activaríamos

Y para ser justos con la función, el caso en el que sí la activaríamos sin rechistar: grupos empresariales que arrastran varios tenants por historia de adquisiciones, donde «otra organización» es en realidad la misma empresa con otro dominio y otro contrato de Microsoft. Ahí el recall entre tenants no es un favor a un tercero, es arreglar una frontera artificial que nunca debió existir. Ese escenario es más común de lo que parece y probablemente sea el motivo real por el que Microsoft ha construido esto.

Tres cosas que todavía no sabemos

No lo hemos probado, y lo decimos antes de que nadie lo pregunte: el despliegue empieza ahora. Todo lo anterior sale del aviso del Centro de mensajes, de la documentación de Exchange Online y de la de Elementos recuperables, no de un laboratorio. Quedan cosas sin documentar públicamente: cuántos tenants admite la lista, qué ve exactamente el destinatario si las notificaciones están apagadas y si el límite de mensajes ya leídos aplica en el caso externo. Cuando lo tengamos delante en un tenant real y podamos comprobarlo, lo contaremos igual de claro, salga como salga.

La pregunta que toca hacerse antes de decir que sí

Casi todas las decisiones de seguridad de un tenant se toman igual: llega una función nueva, alguien pregunta si se puede activar y la respuesta rápida es «sí, es de Microsoft». La respuesta lenta es preguntarse a quién le estás dando una llave, qué abre esa llave y quién la tendrá dentro de dos años. Con el recall entre organizaciones la llave abre un cajón concreto —los buzones de tu gente— y quien la usa no trabaja para ti. No hay que tenerle miedo, hay que tratarla como lo que es: una decisión de gobierno del correo, no un ajuste. Y las decisiones de gobierno se toman con la retención puesta, la lista corta y una fecha para volver a mirarla. Si esta semana andas revisando cambios de Exchange Online, por cierto, el otro plazo abierto vence el 31 de agosto.

Fuentes (verificadas el 8 de agosto de 2026): aviso del Centro de mensajes MC1423106 «Introducing cross-tenant message recall in Exchange Online» (identificador de hoja de ruta 561330; despliegue mediados de agosto – primeros de septiembre de 2026; desactivado por defecto; cmdlet Set-CrossTenantRecallConfiguration) — Centro de mensajes de Microsoft 365, reproducido por m365admin.handsontek.net y Petri; mecánica del recall en la nube, Set-OrganizationConfig -MessageRecallEnabled / -RecallReadMessagesEnabled, borrado duro, reintentos hasta 24 horas, limitaciones de reenvío y respuestas sobre eDiscovery y registros de auditoría — Microsoft Learn, «Work with Cloud-based Message Recall»; comportamiento de la carpeta Elementos recuperables y de las retenciones — Microsoft Learn, «Recoverable Items folder in Exchange Online». Imagen social del post: fotografía «Shredded» de Mike Haw (Flickr), vía Wikimedia Commons, CC BY 2.0.