Learn › Microsoft Teams › 3 · Messaging architecture

The chat service and compliance records

Your message lives twice: once in the chat service that users see, once as a compliance record in Exchange that lawyers see. Every retention, eDiscovery and 'why is it still there' mystery is the gap between those two copies.

The flow — what actually happens

Plain-language first; the packet-level view underneath each step is what you'd see in a Wireshark trace, and what healthy looks like.

  1. You hit Send

    The message goes to the Teams chat service — a purpose-built store in Azure. THAT copy is what every participant's client renders, instantly. Exchange is not involved yet; if Exchange Online had an outage right now, chat would keep flowing.

    On the wire HTTPS 443 to the chat service; delivery receipts ride the same channel. Client-side, the message appears from the service echo, not local optimism — which is why a send can visibly 'fail' and retry.
  2. The compliance copy lands (seconds to minutes later)

    A background pipeline writes a copy into hidden mailbox folders: 1:1/group chat → each participant's mailbox; channel messages → the group mailbox (and since the 2025-26 change, private channels too). This copy exists for Purview: retention, eDiscovery, holds. Users never see it.

    On the wire Nothing user-visible — the proof is in eDiscovery: a search hits messages via mailbox locations (TeamsMessagesData folder), and brand-new messages take minutes to become searchable. That indexing lag is this pipeline.
  3. Deletion — the two-copy dance

    User-deletes affect what clients render. Retention policy deletion works on the compliance side and then reaches forward to purge the service copy on its own schedule. A hold freezes the compliance copy even while the visible copy disappears — 'deleted' and 'gone' are different claims.

    On the wire eDiscovery again: search after a user delete still hits (compliance copy intact); search after retention purge completes doesn't. The interval between is your tenant's real deletion latency — measure it once.

Where each conversation's record lives

Conversation Visible copy Compliance copy
1:1 / group chat Chat service Every participant's mailbox (leavers: inactive mailbox rules apply)
Standard channel Chat service Group mailbox
Private channel Chat service Group mailbox (post-2025/26 migration; formerly member mailboxes — old content may still sit there)
Meeting chat Chat service Participants' mailboxes (it is a group chat with a fancy name)
External/federated chat Both tenants' services Each side keeps records for its own users only

Practical consequences:

  • eDiscovery scoping follows the mailbox map — to find channel messages you scope the GROUP; scoping the user finds their chats, not their channel posts.
  • Guests' chat records live in your tenant against their guest mailbox shadow — discoverable by you; federated users' messages are recorded in their tenant, and you only hold your side of the conversation.
  • Deleting a user's mailbox deletes their chat compliance copies — inactive mailboxes / holds are how leavers' chats stay discoverable.

What to watch (proofs)

  • The pipeline's existence: Purview eDiscovery search for a message you just sent — the minutes until it hits = compliance-copy + index latency.
  • Where a hit came from: eDiscovery results show the source mailbox — group vs user — proving the table above against your own tenant.
  • The service copy's independence: EXO outage advisories with chat unaffected (service health history) — the architectural claim, evidenced.
  • Purge latency: delete via retention (short test policy on a test mailbox), watch the visible copy outlive the policy by the documented processing windows.

The wire

  • Send/receive: HTTPS 443 to the Teams chat service (no direct EXO dependency at send time)
  • Compliance copy: internal pipeline to hidden mailbox folders (TeamsMessagesData)

PowerShell for this concept

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.