Mobile Email Setup

You are getting corporate mail working on a phone. Mobile mail tickets are policy tickets wearing a settings costume: whether mail works on a given phone is decided by the tenant's Conditional Access and app-protection policies, not by the mail settings the user is fiddling with. Determine what the tenant requires first, then make the phone comply — and never enroll a personal device into management as a side effect of "fixing email." Work in order.

1. History first. Search this client's past tickets for mobile email. Prior tickets reveal the client's standard (Outlook-app-only? MAM-only? full MDM?) and how the last dozen of these were resolved.

2. Docs second. Check the client's documentation and knowledge base for the mobile-access policy: which apps are sanctioned for mail, whether app protection (MAM) or full enrollment (MDM) is required, the BYOD policy, and any Conditional Access rules touching mobile. This is the ground truth — the phone must match it, not vice versa. Documentation may be absent for this tenant — fall back to the knowledge base and say what you could not check; if no mobile policy is documented anywhere, say so and ask the client's admin rather than assuming one.

3. Classify the device. Corporate-owned or personal (BYOD)? This decides what may be asked of it. For BYOD, the user's consent to whatever policy requires (app protection at minimum, enrollment at most) is a precondition, not a formality — state clearly what the organization can and cannot see/do under the applicable option before proceeding.

4. Identify versions. Phone OS version (policies commonly set OS minimums — an old iOS/Android version can be the entire ticket), the mail app in question (native Mail vs Outlook), and whether the account uses modern authentication (basic auth to Exchange Online is dead; any setup guide demanding server names and ports is a fossil — the modern path is sign-in via the app). Do not walk users through legacy basic-auth setups even if an old KB article suggests it — verify current guidance on the web when in doubt.

5. Evidence before theory. The exact prompt or error on the phone, and — where the desk has tenant access — the Entra sign-in log entry for the failed attempt (pair with the M365 Sign-in Issues playbook; a Conditional Access failure names the blocking policy outright).

6. Branch on the evidence:
   a. New setup, compliant path — walk the sanctioned app: install Outlook (or the documented standard), sign in with the work account, complete MFA. If policy requires app protection, the "your organization is now protecting data in this app" flow with a PIN prompt is expected — tell the user before it appears so it doesn't read as malware. Escalate when the account itself can't authenticate anywhere — that is an identity ticket, not a mobile ticket.
   b. Blocked by Conditional Access — mail worked in setup but access is blocked, or native Mail is refused while Outlook works. Read the CA failure from the sign-in log: app-protection-required policies block clients that can't attest (native Mail often falls here by design). The fix is the sanctioned app, not a policy exception. Escalate when the user's role genuinely needs an exception — that is a policy change for the tenant admin (see app-protection-policies in the m365-administration playbook), never a quiet desk-side workaround.
   c. Enrollment prompts — the phone demands device registration/management mid-setup. Determine from policy whether this is expected (MDM-required tenant) or a misconfigured target group. On BYOD, pause: confirm the user understands and consents, and offer the MAM-only path if the tenant supports it. Escalate when enrollment fails technically (pair with the mobile-device-mdm playbook) or the user declines management on a personal device — route to the client's policy owner rather than improvising access.
   d. Sync stopped on a working setup — mail worked, then quietly died. Usual causes in order: expired/changed password awaiting re-auth (open the app and complete sign-in), MFA method changed, the device fell out of compliance (OS too old after a policy update, jailbreak/root detection), or an app-protection PIN lockout. The sign-in log names which. Escalate when compliance requires an OS the device can't run — that is a hardware conversation with the client, not a troubleshooting loop.

BYOD boundary: never enroll a personal device, and never present enrollment as mandatory for mail without the client's documented policy saying so — consent first, and record that the options were explained. The tenant's policy wins: fix the phone to match policy and route policy-change requests to the tenant admin; no desk-side CA exceptions, ever. You do not run scripts or remote commands, and no remote device actions come from this playbook — wipes/locks live in the mobile-device-mdm playbook behind approval gates.

7. Close the loop. Have the user send and receive a test message, and confirm calendar sync if they use it. Leave a plain-text internal note (plain text, no markdown or emojis, raw URLs not links): device class (corporate/BYOD), app, branch, the policy that governed the outcome, verification result — never note device PINs or personal-account details — and anything you couldn't check.