IT Checklist for Rolling Out a New Email Client

An IT checklist for rolling out a new email client is the answer to a question your CFO or CISO will eventually ask: how do we know the tool that now reads and writes on the company's behalf is safe to trust? A generic SaaS vendor questionnaire will not answer that. It produces reassurance without evidence. The checklist below is scoped to the specific properties of an email client — OAuth scopes, admin consent, audit logging, tenant isolation, offboarding — and every item is written as an answerable question, not an assurance you accept.

The order is deliberate. Approvals and scopes go first because they are the blast-radius controls; a pilot cohort goes in the middle because it is where you find the failures a document review cannot; a comms plan and a rollback plan go last because they exist to make the rollout survivable when something you did not predict goes wrong. Work top-down and the earlier decisions constrain the later ones the right way.

The short answer#

Before approving a new email client for the company, walk the ten items below in order. Anything you cannot answer with a link to the vendor's own live documentation is a gap the vendor has to close before you go further — not something to accept on a sales call.

• OAuth scopes requested, and why each one is required. Prefer narrow scopes (Gmail's `gmail.modify` or the Microsoft Graph equivalent) over blanket `full_access`.
• Admin consent, not end-user consent. Users should not be able to grant the app tenant-wide access on their own.
• App allowlisting in Google Workspace or Microsoft 365 (Entra ID enterprise apps), scoped to the users who need it.
• Data residency and subprocessors — where mail bodies are stored, which model providers see message content, and whether training on your mail is off by default.
• Retention windows for mail, drafts, agent logs, and OAuth grants, matched to your legal hold policy.
• Audit logging — every send, approval click, autonomy change, and OAuth grant — with an export path to a store your security team already owns.
• Tenant isolation and BYOK — whether encryption keys can be scoped to your organisation and what happens if a subprocessor is breached.
• A two-week pilot cohort of ten to twenty users spanning the mail patterns you actually run (sales, support, execs, shared inboxes).
• A comms plan that tells every user what changes, what the agent can and cannot do, and where to report a bad send.
• A written rollback plan — token revocation, mail-flow return path, evidence retention — before you invite the first user, not after the first incident.

Criteria that actually matter#

The reason most email-client security reviews look the same is that they lean on generic SaaS questionnaires — SOC 2, GDPR, incident response — without adjusting for what makes an email client different. An email client sees every conversation, has permission to send under a user's identity, and often executes actions on the basis of message content. That combination changes what "good" looks like on several dimensions, and it is where a rigorous review earns its keep.

Blast radius comes first. An email client's OAuth grant is one of the widest a user can hand out — full mailbox read, often full send, sometimes calendar and contacts on top. The right question is not "is this vendor SOC 2 certified" but "which scopes are they asking for, and are any of them broader than the job requires?" A tool that requests `https://mail.google.com/` (full access to mail) when it only needs `gmail.modify` is telling you something about its engineering discipline, and about how it will treat future requests.

Reversibility is the second dimension a generic review misses. A sent email cannot be un-sent. An OAuth token you granted to a subprocessor cannot be un-known. A shared thread cannot be recalled from an outsider's inbox. Anything with a one-way door needs an approval step in front of it and a way to prove — from the audit log — who approved what and when. If the vendor's own documentation does not show you the approval trail, the trail does not exist.

Observability is the third, and the one that decides how a bad day ends. An AI-native email client that can draft, send, file, and reply autonomously will eventually do something the sender did not expect. When that happens, the question is whether you can show exactly what the agent saw, what it decided, and what a human clicked. If the answer lives only in the vendor's dashboard with no export, you are trusting their SLA to answer a legal question — and legal questions have deadlines that vendor support does not honour.

Minimum privilege is the fourth, and it applies twice. On the user side, no one should have more autonomy than their job needs; a support agent's agent does not need Autopilot access to draft to executives on their behalf. On the provider side, prefer the narrowest OAuth scopes the tool can function on, and require admin consent for any third-party app that wants mail content. Google's own admin guidance and Microsoft's app-consent controls are your Entra-side and Workspace-side baselines.

Scoring table: the ten-item vendor assessment template#

Use the table below as a vendor assessment template. Score each item Pass, Partial, or Fail; anything Fail on a High-priority row is a stop-work item that the vendor has to fix before the pilot starts. Anything Partial is allowed, but write down the compensating control you will run alongside it, so the trade-off is on paper and not in someone's head.

Read the table as a walkthrough for a two-hour vendor call rather than a form to email over. The verification column matters more than the answer column; a vendor who says "yes" to every question and cannot walk you through the evidence live is answering the wrong version of the question.

Worked example: a two-week pilot for a 120-person company#

A concrete run through the checklist keeps the sequence honest. Imagine a 120-person company on Google Workspace, mixed use across sales, support, product and finance, with two shared inboxes. IT has approval authority; security signs off; the CFO is watching the cost. The pilot runs over two calendar weeks with fifteen users spanning the mail patterns above, and the goal is a defensible go/no-go decision at the end.

1. 1

   Day −3: vendor call, walk the scoring table live

   Book a two-hour call and score all ten questions against the vendor's own documentation. Anything Fail on a High-priority row stops the pilot until it is fixed. Capture the answers verbatim in a shared doc so the security and IT views are the same view.

2. 2

   Day −2: admin consent and app allowlisting

   In Google Workspace Admin, restrict OAuth consent for the vendor's client ID to the pilot security group. Confirm end-user consent is off tenant-wide. In Microsoft 365 shops, do the equivalent in Entra → Enterprise applications and disable user consent for apps requesting mail scopes.

3. 3

   Day −1: audit log routing and rollback dry-run

   Configure the audit log export to your SIEM or log store and verify a test send lands in it within an hour. Then dry-run the rollback on a throwaway account — revoke the OAuth grant, confirm the app loses access, confirm mail flow continues through the previous client.

4. 4

   Day 0: comms plan sent to the pilot cohort

   Send the pilot users a plain-English note: what the tool does, what the agent will and will not do without approval, what the retention window is, how to report a bad send, and who owns the rollback decision. Attach the vendor's own security page rather than paraphrasing it.

5. 5

   Days 1–5: Copilot mode only, watch the audit log

   Every pilot user runs in approve-before-send (Copilot) mode. IT watches the audit log daily for scope surprises, unexpected external recipients, and any actions the vendor's docs did not describe. Log every anomaly in the shared doc, with a link to the audit-log entry.

6. 6

   Days 6–10: selective Autopilot promotion, gated by role

   Promote three named users to Autopilot on scoped flows only — e.g. sales draft-and-send to known contacts, support triage-and-label. No exec accounts on Autopilot in the pilot. Watch the same log daily and compare the promoted flows against the pre-approved allowlist.

7. 7

   Day 11: mid-pilot go/no-go, comms update if it stays

   Review the anomaly log with security. Any High-priority Fail from the scoring table that surfaced during the pilot is a stop; anything Medium is a documented compensating control. If it stays, send an update to the cohort naming what changes going forward and why.

8. 8

   Day 14: rollout decision + written rollback plan

   Write the go/no-go with the evidence attached. If go, publish the rollback plan alongside the rollout plan so both live at the same URL — who can pull the OAuth grant, in what order, and what mail flow reverts to. A rollout without a written rollback is a rollout you cannot recover.

Red flags in a vendor's own answers#

The scoring table above assumes the vendor is telling the truth. Most are, but some answers are structural warnings — patterns that show the tool was built for individual users and stretched into a business product without ever being re-architected for one. Watch for these on the call, because they are hard to work around once the tool is live:

• "We request full mailbox access to keep things simple." Simple for whom? Broad scopes exist so the vendor does not have to justify the narrow ones. A tool that will not scope down when asked will not scope down later either.
• "End users can install it themselves — no admin needed." That is the sales pitch, and it is also the compliance failure. Any app that touches mail content should require admin consent, full stop.
• "Audit logs are in our dashboard." A log that only lives in the vendor's dashboard is a log you cannot subpoena, cannot query with your own SIEM, and cannot keep after you cancel. Ask for export before you sign.
• "AI training on your mail is opt-out." Even where it is legally permissible, the default should be off. A vendor that opts you in silently is a vendor whose product decisions are made without asking whether they clear an enterprise procurement.
• "Rollback? Just cancel and we'll delete the data." Rollback needs to be executable from your side — revoke OAuth, remove the app, restore mail flow — without touching the vendor's support queue. Anything less is a support-ticket-shaped hostage.
• No named security contact, no incident SLA, no post-mortems on request. An email client that does not answer security mail in hours is one you will hear from days after an incident, from a customer, not the vendor.
• "Prompt injection? We tell users not to click bad links." That is the wrong answer. Inbound mail is untrusted input to the agent; the defence has to sit inside the agent, not inside the user's judgement.

None of these is a hard disqualifier on its own — a tool that fails one might still be the right choice with a workaround. But two or three of them together add up to a product that will fight your governance rather than support it, and every workaround you build is technical debt you pay for at every audit.

What we'd pick and why (honest)#

Full disclosure before the recommendation: we build AI Emaily, so read this section knowing we sell the tool we are about to describe. The named concession further down is why the rest of the argument is worth anything — a page that concedes nothing is a page you should discount.

For an IT team choosing an AI-native email client on the strength of the ten questions above — narrow OAuth scopes, admin-only consent, exportable audit log, BYOK, offboarding hooks, executable rollback — AI Emaily is the tool we would pick, and this is who we are the right choice for. If you connect Gmail, Google Workspace, Outlook or Microsoft 365 mailboxes and want the agent to start in Copilot (approve-before-send), with Autopilot as a per-user opt-in gated by a security group, and every action logged in an immutable audit trail with undo on the actions themselves, the ten defaults in the scoring table are how we ship. Retention is short by default. BYOK keys are decrypted only in an isolated worker, never client-side and never logged. Model providers see no training on your mail. You can start on a 7-day free trial of Pro or Autopilot (card required, $0 charged if you cancel before day 7) — check the current AI Emaily pricing for what each tier includes.

Where we are not the right pick, and the concession that makes the rest of this credible: if your organisation lives fully inside Microsoft 365 and the admin surface you actually need is deep Purview retention labels, Entra-native role-based access at the granularity of individual mailbox scopes, and native eDiscovery held to Microsoft's own compliance boundary, Microsoft Copilot for Microsoft 365 inherits all of that from the tenant it lives in and we do not match it. We ship a strong app-level admin surface; we do not ship the tenant-level compliance graph a large regulated Microsoft shop already runs on. On that reader's shortlist, Copilot is a fair-and-square favourite, and pretending otherwise would waste your evaluation cycle.

For everyone in between — the twenty-to-three-hundred-person team that wants a real IT-grade admin surface without inheriting an enterprise compliance stack — the ten questions above are the shape our admin panel was built around. Score us against them, pilot us against them, and if we do not pass a High-priority row live on the call, do not approve us.