Cross-tenant recall: l'Exchange Online deixa que una altra empresa esborri correu de les teves bústies

A mitjan agost Microsoft comença a desplegar a l'Exchange Online una de les funcions més demanades dels últims anys: recuperar un correu que ja has enviat a una altra empresa. Llegida des del costat del remitent sona a xarxa de seguretat. Llegeix-la des de l'altre extrem del cable, que és on som gairebé tots: a partir d'ara algú d'una altra organització podrà fer desaparèixer un missatge que ja s'ha lliurat a la bústia de la teva gent. I la casella que ho permet no l'actives tu per recuperar els teus correus. L'actives perquè uns altres recuperin els seus de les teves bústies.

Escrivim això des del costat de qui administra tenants d'altri. Gestionem entorns de Microsoft 365 per a empreses, i sabem com arriba aquesta mena de novetat: gairebé mai la demana un administrador. La demana un usuari que ha llegit un titular, o la demana la matriu. Quan arribi —i arribarà— convé tenir la resposta pensada, perquè l'avís oficial és curt i les conseqüències no.

El que el recall ja fa avui (i gairebé ningú no ha tornat a mirar)

Molta gent té al cap el recall de fa quinze anys: aquell missatge que demanava si us plau a l'Outlook del destinatari que retirés el correu, i que fallava gairebé sempre. Aquell ja no existeix. Des del recall al núvol, la petició la intercepta un agent dins del mateix servei i la paraula que fa servir la documentació de Microsoft per al que fa amb l'original és hard-delete: esborrat dur de la bústia del destinatari. No demana permís al client de correu, no depèn que el destinatari tingui l'Outlook obert i, segons la mateixa pàgina, el sistema continua intentant-ho fins a 24 hores.

Hi ha un detall en aquesta pàgina que mereix llegir-se dues vegades. El diàleg de l'Outlook continua dient que només es recuperen els missatges no llegits, i la documentació ho desmenteix amb totes les lletres: «aquesta afirmació ja no és exacta». Existeix un ajust d'organització que decideix si es poden recuperar missatges que el destinatari ja havia llegit, RecallReadMessagesEnabled, i el seu valor per defecte —buit— equival a activat. Traduït: avui, dins de la teva organització, un company pot fer desaparèixer de la teva bústia un correu que tu ja havies llegit, i l'avís que veus a la pantalla diu el contrari del que fa el sistema.

Els dos interruptors que governen tot això fa anys que hi són, en una sola ordre:

Set-OrganizationConfig -MessageRecallEnabled $true -RecallReadMessagesEnabled $true
# valor per defecte: buit, equivalent a $true en tots dos

Tot això ja hi era. El que canvia a l'agost no és la potència del recall: és de qui pot venir l'ordre.

El que canvia: MC1423106

L'avís del Centre de missatges MC1423106 (identificador de full de ruta 561330) anuncia el cross-tenant message recall: fins ara el recall només funcionava entre bústies de la mateixa organització —de fet, a dia d'avui la documentació de l'Exchange Online continua llistant com a limitació que «no pots recuperar missatges per internet ni entre organitzacions», juntament amb el correu cap a un Exchange local en escenaris híbrids: qui vagi a la pàgina oficial llegirà el contrari del que anuncia l'avís—, i a partir d'aquest desplegament podrà creuar la frontera entre tenants de Microsoft 365. Arrenca a mitjan agost del 2026 i es completa a primers de setembre, per a clients worldwide i també GCC, GCC High i DoD. Hi ha cobertures que situen la disponibilitat general una mica més tard; la data que mana és la del teu Centre de missatges, no la d'una notícia.

La part ben feta, i cal reconèixer-la: arriba desactivat i qui decideix és qui rep. Cap remitent extern no pot retirar res de les teves bústies si tu no has encès la funció i, a més, has posat el seu identificador de tenant en una llista blanca. Es fa des del PowerShell de l'Exchange Online:

# 1) encendre la funció al TEU tenant (el que rep)Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled $true

# 2) autoritzar tenants concrets a retirar correu de les teves bústiesSet-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add="<tenantId1>","<tenantId2>"}

# 3) treure'n un de la llista quan s'acaba la relacióSet-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Remove="<tenantId1>"}

Si en executar la primera ordre la teva consola no reconeix el cmdlet, no busquis la fallada al tenant: actualitza el mòdul d'Exchange Online Management, perquè és nou i no hi és a les versions anteriors. Si el tenant del remitent no és a la llista, el seu intent falla i ell rep l'avís que la recuperació entre organitzacions no està disponible. L'avís afegeix un altre detall que convé tenir present: si tens activades les notificacions de recuperació al destinatari, també s'apliquen als recalls que venen de fora. És a dir, els teus usuaris començaran a rebre avisos estranys d'empreses alienes, i algú els ho haurà d'explicar.

L'asimetria: aquesta casella no és per a tu

Aquí hi ha el punt que gairebé cap cobertura no diu en veu alta, i és el que canvia la conversa sencera. Activar la funció al teu tenant no et serveix absolutament de res com a emissor. Perquè el teu comercial pugui retirar el PDF amb la llista de preus que acaba d'enviar al client equivocat, qui ha d'encendre la casella i posar el teu identificador de tenant a la seva llista blanca és el client. Tu, activant-la, no guanyes cap capacitat: només la concedeixes.

Això ho converteix en una cosa diferent d'una funció: és un favor. I els favors no s'avaluen preguntant «com s'activa?», sinó «a qui, per què i què passa el dia que qui té el favor no és qui jo em pensava?». És exactament la mateixa pregunta que ens fem amb qualsevol permís concedit a un tercer dins d'un tenant; fa uns dies escrivíem sobre els tokens d'aplicacions connectades que no tornen a demanar MFA, i el patró mental és idèntic: el que es concedeix una tarda continua concedit dos anys després, quan ja ningú no recorda per què.

El problema no és un desconegut: la llista blanca ja està escrita

Pensa un moment a qui posaries en aquesta llista. No pas desconeguts: la matriu, les filials, la gestoria, el despatx que porta la nòmina, el proveïdor de tota la vida. És a dir, exactament els mateixos remitents que apareixen en el frau del CEO i en el frau de la factura, perquè aquest frau no viu d'enganyar ningú amb un domini estrany, viu de la confiança que ja existeix entre dues empreses que fa anys que s'escriuen.

Convé no dramatitzar, perquè l'alarmisme també menteix. Qui controla el tenant del teu proveïdor té avui jugades molt millors que esborrar correu: pot enviar correu fent-se passar per ells, llegir els fils, canviar un IBAN en una plantilla. Això no li obre cap porta nova. El que li afegeix és una capacitat concreta que fins ara no tenia: retirar el missatge després. I aquesta és justament la part que més molesta quan toca reconstruir un incident, perquè un correu amb una factura manipulada que desapareix de la bústia el dia que el pagament ja ha sortit no és el mateix que un que continua allà, amb les seves capçaleres, perquè algú se'l miri amb calma.

Hi ha un fre que juga a favor teu i que surt a la mateixa documentació: els missatges reenviats a mà pel destinatari i els reenviats o redirigits per una regla de safata d'entrada no es recuperen. El reenviament automàtic dins de l'organització sí. Dit d'una altra manera: la còpia que el teu usuari va enviar al cap prement «reenvia» sobreviu a l'esborrat. És un consol petit i depèn de l'atzar, però explica força bé per què el recall no és una màquina del temps.

Un esborrat dur tampoc no és la fi del món (durant 14 dies)

Un esborrat dur a l'Exchange Online no és una trituradora. Els elements esborrats de manera dura acaben a la subcarpeta Purges d'Elements recuperables quan la bústia té recuperació d'element únic o retenció per litigi actives, i la documentació diu, per als dos casos que anomena, que posar una bústia en in-place hold o en retenció per litigi atura el purgat automàtic de l'Assistent de carpetes administrades a les subcarpetes DiscoveryHolds, Deletions i Purges. Amb una directiva de retenció de Microsoft 365 l'efecte és equivalent però la carpeta és una altra: allà els elements esborrats en dur es conserven a DiscoveryHolds. I la mateixa pàgina del recall ho remata al seu apartat de preguntes freqüents: per a bústies amb retenció per litigi o in-place hold, el missatge recuperat continua apareixent a l'eDiscovery.

Un apunt d'honestedat abans de continuar: la pàgina del recall no diu on va a parar l'original recuperat. Això surt de creuar-la amb la d'Elements recuperables, i és lectura nostra, no cita. Feta aquesta salvetat, la conclusió operativa de l'article té un matís que convé no regalar-se: hi ha una xarxa posada de sèrie, però porta rellotge. La recuperació d'element únic ve activada per defecte a tota bústia nova de l'Exchange Online, de manera que el missatge esborrat en dur continua a Elements recuperables i un administrador el pot treure durant el període de retenció d'elements eliminats: 14 dies per defecte, 30 com a màxim. Després no queda res. D'aquí surt l'única instrucció pràctica que donem a un servei de suport amb això: quan algú digui «m'ha desaparegut un correu», la cerca es fa aquesta setmana, no el mes que ve. I d'aquí surt també per a què serveix de debò una retenció o un hold: no posen la xarxa, li treuen el rellotge. Compte, que això no converteix la retenció en una còpia de seguretat —ja vam escriure sobre per què una directiva de retenció de Purview no és un backup—, però sí que és la diferència entre poder respondre «el tinc» i haver de dir «no ho sé». És també la raó per la qual el backup de Microsoft 365 deixa de ser una discussió teòrica el dia que un tercer pot provocar un esborrat a les teves bústies sense passar per tu.

El buit que més ens grinyola: el registre

En aquesta mateixa secció de preguntes freqüents hi ha una resposta de quatre paraules que hauria d'estar en negreta a l'avís i no hi és. A la pregunta de si els recalls apareixen als registres d'auditoria de bústia, la documentació contesta: «No, ara mateix no». El lloc on un administrador anirà a mirar quan un usuari digui «m'ha desaparegut un correu» és exactament el lloc on això no consta.

Rastre, n'hi ha, però és en un altre lloc i és més incòmode: el message trace registra el missatge de recuperació, i el detall de l'esdeveniment Drop és on es llegeix si l'esborrat va anar bé —amb el matís, molt poc intuïtiu, que l'estat que mostra la traça és Failed tant quan el recall funciona com quan expira, i cal obrir el detall per trobar el Result:Success—. És una comprovació d'administrador amb pressa a les nou del vespre, no un tauler. I quan el recall vingui de fora, la pregunta «qui ha esborrat això?» tindrà una resposta que no és al teu tenant.

Com ho tractarem als tenants que gestionem

I una pregunta que deixem oberta expressament, perquè no l'hem pogut verificar: no queda clar si l'ajust RecallReadMessagesEnabled del tenant que rep governa també els recalls que arriben de fora. Si el governa, posar-lo a $false és un bon fre intermedi per a qui vulgui activar la funció només per a missatges encara no llegits. Si no el governa, el fre no existeix. És de les coses que preguntarem abans d'encendre-ho en un tenant de client, i de les que no suposarem.

Quan NO ho activaríem

I per ser justos amb la funció, el cas en què sí que l'activaríem sense protestar: grups empresarials que arrosseguen diversos tenants per història d'adquisicions, on «una altra organització» és en realitat la mateixa empresa amb un altre domini i un altre contracte de Microsoft. Allà el recall entre tenants no és un favor a un tercer, és arreglar una frontera artificial que no hauria d'haver existit mai. Aquest escenari és més comú del que sembla i probablement sigui el motiu real pel qual Microsoft ha construït això.

Tres coses que encara no sabem

No ho hem provat, i ho diem abans que ningú ho pregunti: el desplegament comença ara. Tot l'anterior surt de l'avís del Centre de missatges, de la documentació de l'Exchange Online i de la d'Elements recuperables, no d'un laboratori. Queden coses sense documentar públicament: quants tenants admet la llista, què veu exactament el destinatari si les notificacions estan apagades i si el límit de missatges ja llegits s'aplica en el cas extern. Quan ho tinguem al davant en un tenant real i ho puguem comprovar, ho explicarem igual de clar, surti com surti.

La pregunta que toca fer-se abans de dir que sí

Gairebé totes les decisions de seguretat d'un tenant es prenen igual: arriba una funció nova, algú pregunta si es pot activar i la resposta ràpida és «sí, és de Microsoft». La resposta lenta és preguntar-se a qui li estàs donant una clau, què obre aquesta clau i qui la tindrà d'aquí a dos anys. Amb el recall entre organitzacions la clau obre un calaix concret —les bústies de la teva gent— i qui la fa servir no treballa per a tu. No cal tenir-li por, cal tractar-la com el que és: una decisió de govern del correu, no un ajust. I les decisions de govern es prenen amb la retenció posada, la llista curta i una data per tornar-la a mirar. Si aquesta setmana estàs revisant canvis de l'Exchange Online, per cert, l'altre termini obert venç el 31 d'agost.

Fonts (verificades el 8 d'agost del 2026): avís del Centre de missatges MC1423106 «Introducing cross-tenant message recall in Exchange Online» (identificador de full de ruta 561330; desplegament mitjan agost – primers de setembre del 2026; desactivat per defecte; cmdlet Set-CrossTenantRecallConfiguration) — Centre de missatges de Microsoft 365, reproduït per m365admin.handsontek.net i Petri; mecànica del recall al núvol, Set-OrganizationConfig -MessageRecallEnabled / -RecallReadMessagesEnabled, esborrat dur, reintents fins a 24 hores, limitacions de reenviament i respostes sobre eDiscovery i registres d'auditoria — Microsoft Learn, «Work with Cloud-based Message Recall»; comportament de la carpeta Elements recuperables i de les retencions — Microsoft Learn, «Recoverable Items folder in Exchange Online». Imatge social del post: fotografia «Shredded» de Mike Haw (Flickr), via Wikimedia Commons, CC BY 2.0.