What permissions should a Gmail client request?

Only permissions necessary for its visible features. A full client may need read, send, and modify access, while a narrow utility should request less. Match each OAuth scope to a documented function.

Does using the Gmail API mean email stays off vendor servers?

No. The Gmail API identifies how software can access Gmail, not the vendor’s complete data path. Ask whether sync, search, notifications, collaboration, or AI use vendor infrastructure.

Does revoking Google access delete an app’s copies of email?

Not necessarily. Revocation stops future access, but Google notes that you may need to contact the third party to delete data it already copied.

What should an email client disclose about AI?

Whether AI is local or cloud-based, the processor, which content is sent, whether features are optional, retention, model training, and separate paths for drafting, summary, search, or classification.

Is a security assessment enough to trust an email client?

It is useful evidence within a defined scope and date, not a guarantee about every release, workflow, or message. Review current permissions, architecture, storage, policy, and update practices too.

Gmail email-client privacy checklist: 10 questions

A Gmail client can read the most sensitive archive many people own. Before connecting one, review more than the logo and feature list: verify the Google permissions it requests, where message data travels, what is stored on the Mac or vendor servers, how AI features use content, which analytics receive metadata, and how to revoke access and delete retained data.

The 10-minute privacy review

Read the OAuth permission screen before approving.
Open the product’s privacy policy and search for Gmail, Google user data, email content, retention, AI, analytics, subprocessors, and deletion.
Determine whether mail travels directly between Google and the app or through vendor infrastructure.
Find where OAuth tokens, message bodies, attachments, search indexes, and diagnostics are stored.
Confirm how to revoke Google access and delete local or cloud copies.

1. Match Google permissions to the feature set

Google publishes Gmail OAuth scopes with different capabilities. Read-only, send-only, compose, modify, and broad mailbox access are not interchangeable. The official scope reference recommends the least sensitive permission that supports the app.

A full mail client may reasonably need to read, send, and modify messages. A narrow utility should request less. The question is not whether access sounds scary in isolation; it is whether each permission is necessary, explained, and consistent with the product.

2. Prefer Google authorization over shared passwords

Google no longer supports clients that require personal Gmail users to share a Google username and password, and recommends looking for Sign in with Google. See Google’s email-client setup guidance. An app password is still a secret with mailbox consequences and is not a substitute for understanding the client.

3. Map the complete data path

Ask whether the app connects directly from the Mac to Google or uses vendor servers for synchronization, search, collaboration, notifications, AI, or cross-device state. If vendor infrastructure is involved, identify what passes through it, what persists, in which region, and for how long.

“Uses the Gmail API” does not answer the data-path question. A Gmail API client can be direct or server-mediated; an IMAP client can also be direct or server-mediated. Architecture and policy supply the answer.

For the protocol distinction, read Gmail API vs. IMAP for Mac email apps.

4. Find every stored copy

A responsive offline client normally stores synchronized mail locally. That can be a good product choice, but the storage deserves clear answers:

Are message databases and attachments protected by macOS file permissions and platform security?
Are OAuth tokens stored in the Keychain or another protected credential store?
Can other Mac user accounts or backup tools read the cache?
Does uninstalling the app remove mail data, or is there a documented deletion step?
Are server-side indexes, previews, or attachment copies retained after account removal?

5. Separate email content from product analytics

Product analytics may collect app version, operating system, screen views, performance timings, or feature events. Email telemetry could expose sender addresses, subjects, search terms, message identifiers, or attachment names. The policy should state what is excluded, redacted, or intentionally never sent.

Crash logs and support bundles deserve the same review. Diagnostics should minimize message content and require deliberate user action when a detailed support export could contain private data.

6. Audit AI features separately

Ask whether AI is local or cloud-based, which provider processes content, whether the feature is optional, what content is sent, how long it is retained, and whether it trains any model. “AI-powered” is not a privacy disclosure.

An app may have different paths for drafting, summarization, search, and classification. Review each feature rather than assuming one setting controls all processing.

7. Read the deletion and retention language

Revoking Google access prevents future API access; it does not necessarily erase data already stored by the client. Google explicitly notes that you may need to contact a third party to delete copied data.

Google Account help says third-party access can be reviewed or removed at any time. Read Google’s third-party access guidance and verify the vendor’s own deletion instructions before connecting.

8. Check security review claims precisely

OAuth verification, a security assessment, code signing, notarization, and a public privacy policy answer different questions. Look for the exact scope, assessor, date, and ongoing obligations. Do not treat one badge as proof that every release, data path, or message is safe.

Google’s API Services User Data Policy requires accurate disclosure, minimum relevant permissions, secure handling, and limited use. Some restricted-scope apps must demonstrate security practices through assessment, depending on access and use. ZenMail’s own assessment context is described in its CASA Tier 2 article.

9. Include employer and regulated-data policy

A product can be acceptable for a personal account and prohibited for a managed Workspace account. Employers may restrict OAuth apps, require allowlisting, limit local storage, or prohibit third-party AI. Check policy before connecting work, health, legal, education, or financial mail.

10. Plan the exit before the trial

Know how to export settings or local data.
Know how to disconnect the Google account inside the app.
Know how to remove the app from Google Account connections.
Know where the local cache lives and how the vendor deletes server-side data.
Verify that canceling a subscription and deleting data are separate operations when the policy says so.

A compact decision rule

Connect the client only when the requested access matches the features, the data path is understandable, local and cloud storage are documented, AI and analytics are explicit, and both revocation and deletion are practical. If the vendor cannot answer where mail goes, wait.

Then compare the workflow, not only the privacy page: use the best Gmail clients for Mac guide and the Apple Mail vs. Gmail comparison.