Does Outlook App on iOS Forwards Your Email Data to Apple Servers? - Intune

The Rumor

There’s a persistent gossip circulating in the enterprise mobility and security community: the Outlook iOS app forwards your email data — encrypted or otherwise — to Apple’s servers. Some versions of the rumor claim the data goes in clear text. Others suggest it’s encrypted but still readable by Apple. We also sometimes hear that Apple Intelligence can process your Outlook emails.

I decided to stop speculating and start investigating. What follows is a complete forensic walkthrough of how I captured, decoded, and analyzed the actual data that flows between Microsoft’s cloud, Apple’s push notification infrastructure, and your iPhone — using nothing more than a Mac, a USB cable, and Console.app.

Every finding in this article is reproducible. Every log excerpt is real. Every conclusion is evidence-based.

Understanding the Architecture: Why APNs Is Involved At All
The Investigation Setup
First Attempt: The Silent Notification
Second Attempt: Catching the Full Notification Chain
Dissecting the Three-Notification Architecture
The Encrypted Payload: Proving It’s Real Encryption
The Complete Data Flow: apsd → SpringBoard → NSE → Lock Screen
Metadata Exposure: What Apple CAN See
Apple Intelligence and Outlook: Separate Concern
Enterprise Recommendations for Intune Admins
Conclusion
Reproduction Guide

Understanding the Architecture: Why APNs Is Involved At All

Before diving into logs, you need to understand why Apple is in the picture at all. This isn’t a Microsoft design choice — it’s an iOS platform requirement.

The iOS Push Notification Mandate

iOS does not allow third-party apps to maintain persistent background connections to their own servers. This is a deliberate power management and security decision by Apple. Instead, all push notifications — from every app, including Outlook, WhatsApp, Gmail, Slack, and everything else — must route through Apple’s Push Notification Service (APNs).

The Data Flow (High Level)

Key Processes Involved

The critical question is: what exactly is in the payload that apsd and SpringBoard see, before Outlook’s NSE decrypts it?

The Investigation Setup

Equipment

iPhone running iOS 26.x (non-jailbroken, production device)
Mac running macOS 26.x (any recent version with Console.app)
USB cable (Lightning or USB-C depending on your iPhone)
Outlook for iOS (latest production build from App Store)
Microsoft 365 account with Exchange Online mailbox

Launching Console.app

Connected iPhone to Mac via USB cable
Opened Console.app on Mac (Spotlight → type “Console”)
Selected the iPhone in the left sidebar under Devices
The live log stream immediately started flowing

Setting Up Filters

Console.app on modern macOS streams an enormous volume of log data. Without filters, you’ll see thousands of entries per second. I applied these filters:

Primary filter: Process name apsd This captures Apple’s push services daemon — the first process that handles incoming APNs notifications. This is where we’ll see the raw payload as delivered by Apple’s servers.

Secondary filters used during analysis:

SpringBoard — to see how iOS routes and displays the notification
Outlook-iOS — to see what Outlook does after receiving the notification

The Test Scenario

I used a second email account (completely separate from the Outlook mailbox being tested) to send test emails. This ensures we capture the full push notification chain from the moment Microsoft’s servers detect the new email through to the lock screen display.

First Attempt: The Silent Notification

What Happened

For the first capture attempt, I had Outlook open in the foreground while sending the test email. This turned out to be an important learning moment.

The Token Registration (Lines 1-4 of Captured Logs)

The very first thing I observed was the APNs token registration for Outlook:

			
default 21:28:30.814440+0100  apsd
  <APSUserCourier 0x1012dcd50 production 0>:
  Received request from <APSConnectionServer: 0xbd704ed00;
  production/com.apple.aps.usernotifications/SpringBoard 0>
  to generate token for info <APSAppTokenInfo 0xbd6d6c870>:
  Topic com.microsoft.Office.Outlook
  Identifier 49869632-CD0A-42E2-8330-D0CDC89877C4

		

Line-by-line breakdown:

Next, apsd found a cached token:

			
default 21:28:30.816148+0100  apsd
  <APSUserCourier 0x1012dcd50 production 0>
  found cached token for topic: com.microsoft.Office.Outlook,
  token: {length = 32, bytes = 0x545ebf68 d1cacfbb 3b6ae21b ed40fb49
  ... 5cd80868 ccb832c2 }

		

This 32-byte token (545ebf68...ccb832c2) is the device’s APNs token for Outlook. Microsoft’s servers use this token to address push notifications to this specific device. This token is stored on Microsoft’s servers and is sent with every push notification request to APNs.

The Topic Filter (Lines 5-360)

After token registration, apsd sends a massive “filter message” to Apple’s servers listing every app topic this device is subscribed to. This is where something interesting appeared — a complete inventory of every app on my device that uses push notifications:

			
default 21:29:20.680821+0100  apsd
  Sending filter message for version: 4129
  reason ChangesOptimization
  with enabled topics = (
    <a02b76fd ...>=com.microsoft.Office.Outlook,
    <c540b034 ...>=com.hammerandchisel.discord,
    <fffc05c7 ...>=com.linkedin.LinkedIn,
    <f864c9cc ...>=com.openai.chat,
    <0cebe04f ...>=com.anthropic.claude,
    <d3ae759e ...>=com.google.Gmail,

		

Privacy note: This filter message reveals to Apple every single app on your device that uses push notifications, along with hashed topic identifiers. This is a known metadata exposure inherent to the APNs architecture, not specific to Outlook.

The Payload That Arrived

When the test email arrived, I captured this payload:

			
default 21:33:19.346618+0100  apsd
  <APSUserCourier 0x1012dcd50 production 0>:
  Received message for enabled topic 'com.microsoft.Office.Outlook'
  onInterface: <APSCourierConnectionProtocolConnection: 0xbd680b4e0;
  NonCellular>
  with payload '{
      aps = {
          "content-available" = 1;
          "filter-criteria" = "f7f1b7dd-5245-4539-a4a5-ac80463d617c";
          isSilentNotification = 1;
      };
      storeId = "{
          \"MailboxGuid\":\"f7f1b7dd-5245-4539-a4a5-ac80463d617c\",
          \"NewMailNotifications\":[],
          \"NotificationWatermark\":6,
          \"TenantGuid\":\"e834900c-91ff-4fd7-ac3d-c395c45fd77b\",
          \"Watermark\":{\"Counter\":6,\"SessionId\":639093762700639289}
      }";
      type = OutlookPushNotification;
  }'
  with priority 5 for device token: NO isProxyMessage: NO

		

Annotated breakdown:

SpringBoard Confirms: No Alert Content

In the SpringBoard logs from Part 3, this silent notification was confirmed:

			
default 21:33:19.389384+0100  SpringBoard
  [com.microsoft.Office.Outlook] Received remote notification request A11F-DA57
  [ waking: 0, hasAlertContent: 0, hasSound: 0
    hasBadge: 0 hasContentAvailable: 1
    hasMutableContent: 0 pushType: Background]

		

The critical flags:

hasAlertContent: 0 — No visible notification content
hasSound: 0 — No notification sound
hasBadge: 0 — No badge update
hasContentAvailable: 1 — Background wake-up only
pushType: Background — Classified as background notification

Why Was NewMailNotifications Empty?

Because Outlook was in the foreground. When the app is actively running, Microsoft’s cloud knows it can sync directly via the app’s own HTTPS connection to outlook.office365.com. The push notification in this case serves only as a “wake-up nudge” — it tells the app “hey, there’s new data, sync now” without including any email content.

This was my first attempt. I needed to try again with Outlook fully suspended.

Second Attempt: Catching the Full Notification Chain

Changed Approach

For the second attempt, I:

Force-closed Outlook
Locked the iPhone
Waited 30 seconds for Outlook to fully suspend
Started Console.app fresh with apsd filter
Sent a test email from an external account
Waited for the lock screen notification to appear with sender name and subject

This time, because Outlook was suspended, Microsoft’s cloud had to include email content in the push notification — there was no active app connection to sync through.

What I Captured: Three Distinct Notifications

This time, I captured three separate APNs notifications arriving in rapid succession for a single email. This was the breakthrough discovery.

Dissecting the Three-Notification Architecture

Notification 1: Badge Update (77 bytes) — 11:35:09

The first notification arrived at 11:35:09, just 77 bytes:

			
default 11:35:09.231949+0100  apsd
  Received message for enabled topic 'com.microsoft.Office.Outlook'
  onInterface: WWAN
  with payload '{
      aps = {
          badge = 3;
          "filter-criteria" = "f7f1b7dd-5245-4539-a4a5-ac80463d617c";
      };
  }'

		

Purpose: Updates the red badge number on the Outlook app icon on the home screen. Nothing more.

SpringBoard confirmed:

			
default 11:35:09.243695+0100  SpringBoard
  [com.microsoft.Office.Outlook] Received remote notification request 5EE0-1D72
  [ waking: 0, hasAlertContent: 0, hasSound: 0
    hasBadge: 1 hasContentAvailable: 0
    hasMutableContent: 0 pushType: Alert]

		

Note hasBadge: 1 but hasAlertContent: 0 — badge update only, no visible notification.

Notification 2: Silent Background Sync (395 bytes) — 11:35:11

Two seconds later, the silent sync notification arrived:

			
default 11:35:11.271423+0100  apsd
  Received message for enabled topic 'com.microsoft.Office.Outlook'
  onInterface: WWAN
  with payload '{
      aps = {
          "content-available" = 1;
          "filter-criteria" = "f7f1b7dd-5245-4539-a4a5-ac80463d617c";
          isSilentNotification = 1;
      };
      storeId = "{
          \"MailboxGuid\":\"f7f1b7dd-5245-4539-a4a5-ac80463d617c\",
          \"NewMailNotifications\":[],
          \"NotificationWatermark\":6,
          \"TenantGuid\":\"e834900c-91ff-4fd7-ac3d-c395c45fd77b\",
          \"Watermark\":{\"Counter\":6,\"SessionId\":639095131434753897}
      }";
      type = OutlookPushNotification;
  }'

		

Same as what we saw in the first attempt. Silent wake-up, empty NewMailNotifications, plaintext metadata.

Notification 3: The Alert Notification (2,134 bytes) — 11:35:11 ← THE CRITICAL ONE

			
default 11:35:11.371124+0100  apsd
  <APSUserCourier 0x1012dcd50 production 0>:
  Received message for enabled topic 'com.microsoft.Office.Outlook'
  onInterface: <APSCourierConnectionProtocolConnection: 0xbd6808c00; WWAN>
  with payload '{
      aps = {
          alert = {
              "loc-key" = "MAIL_ENCRYPTED_BODY";
              "title-loc-key" = "MAIL_ENCRYPTED_TITLE";
          };
          category = Mail;
          "filter-criteria" = "f7f1b7dd-5245-4539-a4a5-ac80463d617c";
          isAlertNotification = 1;
          "mutable-content" = 1;
          sound = "Mail.caf";
          "thread-id" = "AAQkAGY3ZjFiN2RkLTUyNDUtNDUzOS1hNGE1LWFj
                         ODA0NjNkNjE3YwAQAGJZwuSkc6BMoZoAKQB8Cek=";
      };
      encrypted = "v0wu+P8ChNTQ7Yrc6yU5Btd94ypbOGPdgp6fj+CoA8L1
                   hn88p+B3FYGdAqdCWYoWKa755cytWVrE85IZf7xPPA5T
                   FgWPHiwYO5MY5O6kAjS+yTlnyANMtb5Z4V9Non987...
                   [truncated — full base64 blob is ~1,048 characters]";
      publicKeyId = "381478_639093762696060000";
      storeId = "{
          \"ImmId\":[0,9,0,46,0,0,0,0,0,29,132,3,17,170,102,17,
                    205,155,200,0,170,0,47,196,90,13,0,91,32,119,
                    163,43,190,142,76,187,44,43,59,129,149,87,234,
                    0,2,108,141,187,17,0,0],
          \"MailboxGuid\":\"f7f1b7dd-5245-4539-a4a5-ac80463d617c\",
          \"TenantGuid\":\"e834900c-91ff-4fd7-ac3d-c395c45fd77b\"
      }";
      symmetricKeyAndSigningKey = "T4+gRd57OaFpCpKWJUpHkUaGzDFSYJYA
                                   uhN0aBpyHgC/2Xj1jo7CXD4YzlWTyOOR
                                   7TvzJY5zYMxcM/lXbEmVf31cgD1KL4cl
                                   ZuWZgM2YROLpu18V2/Y185hMTefMCmVU
                                   ...
                                   [256 bytes when decoded]";
      type = NewMailPushNotification;
  }'
  with priority 10 for device token: NO isProxyMessage: NO

		

This is the smoking gun. The aps Dictionary (What Apple’s standard APNs infrastructure processes):

The Custom Fields (Microsoft’s encrypted email content)

SpringBoard Confirms: This One Has Alert Content:

			
default 11:35:11.400199+0100  SpringBoard
  [com.microsoft.Office.Outlook] Received remote notification request 3E68-7C68
  [ waking: 0, hasAlertContent: 1, hasSound: 1
    hasBadge: 0 hasContentAvailable: 0
    hasMutableContent: 1 pushType: Alert]

		

Critical flags this time:

hasAlertContent: 1 — YES, this has visible notification content
hasSound: 1 — Will play notification sound
hasMutableContent: 1 — Outlook’s NSE will modify this before display
pushType: Alert — This is a visible alert notification

Then:

			
default 11:35:11.400226+0100  SpringBoard
  [com.microsoft.Office.Outlook] Remote notification request 3E68-7C68
  can be modified: 1

SpringBoard confirms: this notification will be handed to Outlook’s Notification Service Extension for modification (decryption) before display.

And finally, after Outlook’s NSE decrypted the content:

			
default 11:35:11.706306+0100  SpringBoard
  [com.microsoft.Office.Outlook] Saving notification 3E68-7C68: YES
  [ hasAlertContent: YES, shouldPresentAlert: YES
    settingsShouldSave: YES pipelineState: pending]
default 11:35:11.720772+0100  SpringBoard
  [com.microsoft.Office.Outlook] Saving notification 3E68-7C68: YES
  [ hasAlertContent: YES, shouldPresentAlert: YES
    settingsShouldSave: YES pipelineState: completed]

		

The notification pipeline went from pending to completed — the decryption succeeded, and the notification was displayed on the lock screen with the real sender name and subject.

I Captured a Second Email Too

To confirm the pattern was consistent, I sent a second test email. The same three-notification architecture appeared in Part 4 of the logs, this time with a 2,474 byte alert notification (larger email = larger encrypted blob):

			
default 11:36:08.412076+0100  apsd
  Received message for enabled topic 'com.microsoft.Office.Outlook'
  with payload '{
      aps = {
          alert = {
              "loc-key" = "MAIL_ENCRYPTED_BODY";
              "title-loc-key" = "MAIL_ENCRYPTED_TITLE";
          };
          "mutable-content" = 1;
          ...
      };
      encrypted = "mEkdtS5N3Hx0TOIbsAYBA2PddhAezrNhQrzet2djHut...";
      symmetricKeyAndSigningKey = "...";
      type = NewMailPushNotification;
  }'

		

Same pattern: placeholder titles, encrypted blob, RSA-wrapped key. The architecture is consistent.

The Encrypted Payload: Proving It’s Real Encryption

Seeing "encrypted" in a field name doesn’t prove anything. I needed to verify that the blob is genuinely encrypted and not merely base64-encoded plaintext or simple obfuscation.

Decoding the Base64 Blob

I extracted the encrypted field value and decoded it from base64:

			
Input (base64):  v0wu+P8ChNTQ7Yrc6yU5Btd94ypbOGPdgp6fj+CoA8L1
                 hn88p+B3FYGdAqdCWYoWKa755cytWVrE85IZf7xPPA5T...
Decoded length:  784 bytes

Hex Dump of First 64 Bytes:

			
Offset   Hex                                              ASCII
──────── ──────────────────────────────────────────────── ────────────────
00000000 bf 4c 2e f8 ff 02 84 d4 d0 ed 8a dc eb 25 39 06 .L...........%9.
00000010 d7 7d e3 2a 5b 38 63 dd 82 9e 9f 8f e0 a8 03 c2 .}.*[8c.........
00000020 f5 86 7f 3c a7 e0 77 15 81 9d 02 a7 42 59 8a 16 ...<..w.....BY..
00000030 29 ae f9 e5 cc ad 59 5a c4 f3 92 19 7f bc 4f 3c ).....YZ......O<

		

Analysis: This is pure binary noise. No readable ASCII strings, no JSON structure, no email addresses, no subject lines. The data appears random — exactly what properly encrypted ciphertext looks like.

Entropy Analysis

Entropy measures the randomness of data. Truly encrypted data has high entropy (close to maximum), while plaintext, encoded text, or simple obfuscation has lower entropy.

			
Entropy Analysis Results:
─────────────────────────
Total bytes:              784
Unique byte values:       242 out of 256 possible (94.5%)
UTF-8 decodable:          NO
ASCII readable strings:   NONE
Verdict: HIGH ENTROPY — Consistent with AES encryption

		

242 out of 256 possible byte values were present in just 784 bytes. This is characteristic of strong symmetric encryption (AES). For comparison:

Plain English text typically uses only 70-80 unique byte values
Base64-encoded text uses exactly 64 unique characters
Simple XOR obfuscation would show patterns in byte frequency distribution

Analyzing the Symmetric Key

The symmetricKeyAndSigningKey field decoded to exactly 256 bytes:

			
Decoded length:  256 bytes
Unique bytes:    165 out of 256 (64.5%)
UTF-8 readable:  NO
Verdict: RSA-2048 encrypted (256 bytes = 2048 bits / 8)

The 256-byte size is the definitive fingerprint of RSA-2048 encryption. RSA-2048 always produces exactly 256 bytes of output regardless of input size. This confirms Microsoft is using hybrid encryption:

A random AES key is generated per notification
The email content is encrypted with this AES key → encrypted field
The AES key is encrypted with the device’s RSA-2048 public key → symmetricKeyAndSigningKey
Only the device’s private key (stored in iOS Keychain, protected by Secure Enclave) can decrypt the AES key

The Complete Data Flow: apsd → SpringBoard → NSE → Lock Screen

Combining all the evidence from the logs, here is the complete annotated flow for a single incoming email notification:

Phase 1: APNs Delivery (apsd)

			
11:35:11.329977  apsd    hasPayload? {length = 2134, bytes = 0x7b226170
                         73223a7b 22616c65 7274223a ...}
                         forTopic com.microsoft.Office.Outlook

The apsd daemon receives the raw 2,134-byte payload from Apple’s APNs servers over the persistent TLS connection on port 5223. The hex bytes 7b226170 73223a7b 22616c65 7274223a decode to {"aps":{"alert": — confirming the payload is JSON with an alert.

The push is associated with the device token 545ebf68... and timestamped.

Phase 2: Routing to SpringBoard

			
11:35:11.385118  SpringBoard  APSXPCDeliverMessageEvent:
                              Created APSIncomingMessage. UUID: (null)
11:35:11.385160  SpringBoard  Delivering message from apsd:
                              <APSIncomingMessage: 0xb2a9b6340>
                              2049413124 com.microsoft.Office.Outlook

		

SpringBoard receives the message from apsd via XPC (inter-process communication). It logs the full payload content — same MAIL_ENCRYPTED_TITLE / MAIL_ENCRYPTED_BODY placeholders and encrypted blob we saw in apsd.

Phase 3: Notification Classification

			
11:35:11.400199  SpringBoard
  [com.microsoft.Office.Outlook] Received remote notification request 3E68-7C68
  [ waking: 0, hasAlertContent: 1, hasSound: 1
    hasBadge: 0 hasContentAvailable: 0
    hasMutableContent: 1 pushType: Alert]

		

SpringBoard classifies the notification:

It has alert content (the placeholder strings count)
It has sound (Mail.caf)
It is mutable — this is the trigger for the Notification Service Extension

Phase 4: NSE Invocation

			
11:35:11.400226  SpringBoard
  [com.microsoft.Office.Outlook] Remote notification request 3E68-7C68
  can be modified: 1

SpringBoard confirms the notification will be handed to Outlook’s Notification Service Extension (NSE). The NSE is a separate binary (com.microsoft.Office.Outlook.NotificationServiceExtension) that runs in its own sandboxed process.

What the NSE does (inferred from the architecture):

Reads the symmetricKeyAndSigningKey from the payload
Decrypts it using the device’s RSA private key from iOS Keychain
Uses the resulting AES key to decrypt the encrypted blob
Extracts the sender name, subject line, and preview text
Calls UNNotificationContent.bestAttemptContent to replace:
- MAIL_ENCRYPTED_TITLE → actual sender name (e.g., “John Smith”)
- MAIL_ENCRYPTED_BODY → actual subject line (e.g., “Meeting tomorrow at 3pm”)
Returns the modified notification to SpringBoard

Phase 5: Display

			
11:35:11.706306  SpringBoard
  [com.microsoft.Office.Outlook] Saving notification 3E68-7C68: YES
  [ hasAlertContent: YES, shouldPresentAlert: YES
    settingsShouldSave: YES pipelineState: pending]
11:35:11.711378  SpringBoard
  [com.microsoft.Office.Outlook] Adding notification 3E68-7C68
  [ hasAlertContent: 1, shouldPresentAlert: 1
    hasSound: 1 shouldPlaySound: 1 ];
  interruption-level: 1; destinations 398
11:35:11.720772  SpringBoard
  [com.microsoft.Office.Outlook] Saving notification 3E68-7C68: YES
  [ hasAlertContent: YES, shouldPresentAlert: YES
    settingsShouldSave: YES pipelineState: completed]

		

The notification pipeline completes. The decrypted sender name and subject line are now displayed on the lock screen. The entire process from APNs delivery to lock screen display took approximately 350 milliseconds (11:35:11.370 → 11:35:11.720).

Important: The decrypted email content exists only in memory within the NSE’s sandboxed process and in SpringBoard’s notification storage. It was never sent back to Apple’s servers. The decryption is purely local.

Metadata Exposure: What Apple CAN See

While the email content encryption is robust, the metadata exposure is real. Here’s the complete inventory of what transits Apple’s servers in plaintext:

Data Visible to Apple (Per Notification):

Why Metadata Matters: A Practical Example

Without reading a single word of email content, an entity with access to APNs traffic data could construct the following profile:

“Device token 545ebf68... belongs to a user in organization e834900c-... (resolvable to a company name via public M365 metadata). This user’s mailbox f7f1b7dd-... receives email primarily between 09:00-18:00 CET on weekdays, suggesting a European work schedule. On March 19, they received a burst of 12 notifications across 3 thread IDs in a 30-minute window, suggesting an urgent email chain. They access email over both WiFi and cellular networks.”

Government Surveillance Context

This isn’t theoretical. In December 2023, U.S. Senator Ron Wyden revealed that foreign governments had been demanding push notification records from Apple and Google.

https://www.cnbc.com/2023/12/06/apple-and-google-phone-users-spied-on-through-phone-push-notifications.html

Apple subsequently updated its transparency reporting to include push notification data requests. The metadata described above is exactly the type of data that would be available in response to such legal demands.

Apple Intelligence and Outlook: Separate Concern

A related question: can Apple Intelligence (Apple’s on-device AI, introduced in iOS 18.1) access your Outlook email data?

Microsoft’s Official Position

Microsoft explicitly states:

“When using Outlook for your email, Apple Intelligence does not have access to your mailbox. Apple Intelligence can have access to messages you are composing if you decide to share your drafted content with their services.”

Source: Microsoft Support Article

Why This Is True (Technical Basis)

App sandboxing: Outlook’s local data store is in its own iOS sandbox. Apple Intelligence cannot access another app’s sandbox data. This is a fundamental iOS security boundary.
APNs payload encryption: As we’ve proven, the push notification payload is encrypted. Apple Intelligence has no access to the decryption keys (stored in Outlook’s Keychain entries).
NSE isolation: The Notification Service Extension runs in its own sandboxed process. The decrypted email content exists only within this process and in SpringBoard’s notification storage — not in any location accessible to Apple Intelligence.
Contrast with Apple Mail: Apple Intelligence does have full access to emails in the built-in Apple Mail app, because Apple owns both the app and the AI system. This is a fundamentally different architecture than Outlook.

Intune Control

Organizations using Microsoft Intune can disable Apple Intelligence features within Outlook via App Protection Policies, providing an additional control layer. Reference: Microsoft Intune Support for Apple Intelligence

Enterprise Recommendations for Intune Admins

Based on these findings, here are specific recommendations for organizations managing iOS devices through Microsoft Intune:

The Encryption Architecture Is Sound — No Action Required for Content Protection:

Microsoft’s hybrid RSA-2048 + AES encryption of push notification content is well-architected. The email content (sender name, subject line, preview text) cannot be read by Apple or anyone with access to APNs traffic. The decryption occurs entirely on-device using keys stored in iOS Keychain.

Evaluate Metadata Exposure Against Your Threat Model:

TenantGuid and MailboxGuid transit in plaintext through Apple’s infrastructure. For most organizations, this is acceptable risk. For organizations in regulated industries (government, defense, healthcare, finance) or those with elevated threat models, consider:

Whether the ability to identify your organization and individual mailboxes via APNs metadata is within your risk tolerance
Whether notification timing pattern analysis constitutes a concern
Documenting this metadata exposure in your data flow assessments and privacy impact assessments

Consider Lock Screen Notification Policies:

While the push notification content is encrypted in transit, it is decrypted and displayed in plaintext on the lock screen. For high-security environments, consider:

Disabling notification previews on the lock screen via Intune device configuration profiles
Requiring authentication before notification content is revealed
Using Intune’s notification restriction policies for managed devices

Disable Apple Intelligence in Outlook Where Required:

Use Intune App Protection Policies to disable Apple Intelligence features within Outlook for compliance-sensitive environments. While Apple Intelligence cannot access the Outlook mailbox, this provides defense-in-depth.

Investigate WatchConnectivity Payloads:

During this analysis, I observed significant WatchConnectivity (WCSession) activity between Outlook and Apple Watch, with serialized payloads ranging from 305 to 4,307 bytes being synced via Apple’s relay servers. The encryption status of these payloads was not fully determined and warrants separate investigation for organizations deploying Apple Watch in enterprise contexts.

Conclusion

The Rumor: (Mostly)

The claim that Outlook iOS forwards email data in cleartext to Apple’s servers is false. Microsoft has implemented a robust encryption scheme:

Email content is AES encrypted before being sent through APNs
The AES key is RSA-2048 encrypted with a device-specific public key
Apple’s servers see only placeholder strings (MAIL_ENCRYPTED_TITLE, MAIL_ENCRYPTED_BODY)
Decryption occurs entirely on-device via Outlook’s Notification Service Extension
The entire process from encrypted payload to lock screen display takes ~350ms

The Nuance: Metadata IS Exposed

The rumor has a kernel of truth: data does transit through Apple’s servers, and some of it is in plaintext. Organizational identifiers (TenantGuid, MailboxGuid), conversation thread IDs, notification timing, and frequency patterns are all visible to Apple — and potentially to entities that compel Apple to disclose push notification data.

The Bottom Line

For the vast majority of enterprise deployments, Microsoft’s Outlook iOS push notification architecture meets security expectations. The email content encryption is genuine and well-implemented. The metadata exposure is real but bounded, and organizations with elevated security requirements should factor it into their risk assessments.

Reproduction Guide

Every finding in this article can be independently verified. Here’s how:

Requirements

Mac with Console.app (built into macOS)
iPhone with Outlook for iOS installed
USB cable
A second email account to send test emails

Steps

Connect iPhone to Mac via USB
Open Console.app → select your iPhone in the left sidebar
In the search bar, filter by Process: apsd
Force-close Outlook on the iPhone (swipe away from app switcher)
Lock the iPhone
Wait 30 seconds for Outlook to fully suspend
Click Clear in Console.app
Send a test email from another account to the Outlook mailbox
Wait for the lock screen notification to appear
Click Pause in Console.app
Search the captured logs for com.microsoft.Office.Outlook and payload
You should see three notifications: badge (77 bytes), silent sync (395 bytes), and alert (~2,000+ bytes)
In the alert notification, look for MAIL_ENCRYPTED_TITLE, MAIL_ENCRYPTED_BODY, and the encrypted field

Key Log Searches:

All log excerpts in this article are from real device captures with personal identifiers redacted where necessary. The analysis was performed on production software without jailbreaking or modifying the device.