If your product reads a Google inbox through OAuth, you need restricted Gmail scopes. Restricted scopes require Google app verification plus an annual third-party security assessment (CASA). There is no exception for reply detection: gmail.readonly, gmail.modify, gmail.metadata and the IMAP scope https://mail.google.com/ are all restricted (Google's Gmail scope table, as of October 2026). Only gmail.send is merely "sensitive".
The cheap alternative, app passwords over IMAP/SMTP, still works on Google: Google switched off password-based "less secure apps" on March 14, 2025, with app passwords as the stated exception. On Microsoft the clock is running. Exchange Online's Basic SMTP AUTH goes disabled by default for existing tenants at the end of December 2026, with a final removal date to be announced in the second half of 2027 (Microsoft message MC786329, updated January 27, 2026).
Google: which scope triggers what
| Scope | Class | What a sequencer uses it for |
|---|---|---|
gmail.send | Sensitive | Sending only — no reply detection |
gmail.readonly | Restricted | Reading replies, bounces |
gmail.modify | Restricted | Read + label/move (warmup "rescue from spam") |
gmail.metadata | Restricted | Headers only — still restricted |
gmail.compose / gmail.insert | Restricted | Drafts, inserting messages |
https://mail.google.com/ | Restricted | Full access; required for IMAP/SMTP via XOAUTH2 (Google) |
Source: Google, Choose Gmail API scopes.
A sequencer needs sending, reading and (for warmup) modifying. That is the restricted tier, whichever protocol you use.
Unipile's 2026 OAuth guide lists gmail.readonly and gmail.modify as "sensitive" (Unipile). Google's own table says restricted. Plan your verification on Google's table.
Google: the verification path
- Brand verification of the OAuth consent screen (domain, privacy policy, homepage).
- Scope justification with a demo video showing each scope in use, and compliance with Google's Limited Use rules for user data.
- Security assessment (CASA) for restricted scopes, renewed every year. Google says "all applications must be revalidated every year" and assigns an assurance level, AL1 or AL2, based on "user count, requested scopes, and other application-specific signals"; once an app reaches AL2 it stays there (Google Cloud help).
Until verified, an app shows the "unverified app" screen and is capped at "100 new users in total". Google exempts internal apps used only within the developer's own Workspace domain, and test builds.
CASA: who, how much, how long
The App Defense Alliance lists nine authorised labs: TAC Security, Bishop Fox, KPMG, Leviathan Security, NCC Group, NetSentries, Orange Cyberdefense South Africa, Prescient Security and DEKRA. It has paused onboarding new labs "due to the migration to Linux Foundation" (ADA assessors page, as of October 2026).
| Source | Price | Notes |
|---|---|---|
| Leviathan Security (lab, list price) | AL1: $3,000 (start within 30 days), $4,500 (10 days), $6,000 (2 days) | One retest included; annual |
| Nango (integration vendor's guide) | TAC Security $540–720; NetSentries ~$700; Prescient $3,000+ | Labels them "Tier 2" |
| Unipile (integration vendor's guide) | $540–1,000 "self-serve"; legacy track $15k–75k | Legacy figure unverified |
Timelines: Nango puts verification plus CASA at "5–20 days from requesting review being fully verified"; Unipile says 4–8 weeks. Budget 6–10 weeks of calendar time for a first pass including remediation, and a recurring $1k–6k a year in lab fees plus a few engineer-weeks preparing evidence.
The large spread in CASA prices (from about $540 to $6,000, and an unverified $15k–75k "legacy" figure) appears to reflect lab choice and assurance level. I could not confirm which assurance level Google assigns to a cold-email sequencer with tens of thousands of users, or which level Instantly and Smartlead hold. Ask two labs for quotes before budgeting.
How incumbents route around it
- Admin-trusted client ID. Instantly asks the Workspace admin to add its client ID ("Instantly OAuth Email v1") under Manage app access and set it to Trusted for all users (Instantly help). In cold email the "customer" usually is the Workspace admin of a throwaway sending tenant, so this step is cheap.
- Bring-your-own OAuth client. Smartlead lets customers create their own Google Cloud project and OAuth client with
gmail.send,gmail.readonlyandhttps://mail.google.com/, so messages are tied to "your app ID" (Smartlead help). Combined with Google's internal-app exemption, this pushes verification off the platform and onto each sending organisation. - App passwords. Still accepted on Google (Google), though some infra vendors tell customers Workspace mailboxes must use OAuth (Maildoso help) — likely a tenant policy rather than a Google rule.
Whether an admin-trusted but unverified app can use restricted scopes in that domain without CASA is not stated on the Google pages fetched for this research. Instantly's documented flow implies admin trust is at least part of its approach. Confirm with Google's OAuth policy team before relying on it.
Microsoft: publisher verification and Graph permissions
| Item | What it is | Cost |
|---|---|---|
| Entra multitenant app | Your OAuth client in Microsoft's identity platform | Free |
| Publisher verification | Blue badge; needs a Microsoft AI Cloud Partner Program account, verified publisher domain (not onmicrosoft.com) | Free |
Graph Mail.Send | Send via sendMail | — |
Graph Mail.Read / Mail.ReadWrite | Replies, warmup moves | — |
SMTP.Send, IMAP.AccessAsUser.All | OAuth over SMTP/IMAP (Microsoft) | — |
Publisher verification is not optional in practice: since November 8, 2020, users cannot consent to most newly registered multitenant apps that lack it when they request more than basic sign-in (Microsoft). Many enterprise tenants also require admin consent for mail permissions regardless. This research found no paid, mandatory third-party assessment comparable to CASA for Graph mail permissions, which makes Microsoft the cheaper provider to integrate via OAuth.
The basic-auth timeline
| Date | Provider | Change | Source |
|---|---|---|---|
| Summer 2024 | New "less secure app" connections blocked | ||
| Mar 14, 2025 | Password-based IMAP/SMTP/POP off for all accounts; app passwords still work | ||
| Jan 2026 | Microsoft | Planned 2,000/day external-recipient cap per mailbox cancelled | The Register, Jan 7, 2026 |
| Mar–Apr 2026 | Microsoft | Original SMTP AUTH Basic retirement — postponed | MC786329 |
| End Dec 2026 | Microsoft | SMTP AUTH Basic disabled by default for existing tenants; admins can re-enable | MC786329 |
| After Dec 2026 | Microsoft | New tenants: SMTP AUTH Basic unavailable by default | MC786329 |
| H2 2027 | Microsoft | Final, irreversible removal date to be announced | MC786329 |
Once disabled, clients get 550 5.7.30 Basic authentication is not supported for Client Submission, a permanent 5xx failure — the message is not retried (CaptainDNS, February 20, 2026).
On Google, app-password IMAP/SMTP remains a legitimate, assessment-free path as of October 2026. On Microsoft, any sequencer or inbox vendor still sending through Basic SMTP AUTH has until the end of December 2026 before new tenants break, and existing tenants need an admin to switch it back on. The Microsoft inbox supply chain — especially low-cost Azure-tenant inboxes sold in bulk — has to move to OAuth or Graph in the next 6–15 months. Expect connection failures, reconnect campaigns and support load across the market in Q1 2027.
If Google ever withdraws app passwords for IMAP/SMTP the way it withdrew less-secure apps, every app-password sequencer is forced through CASA at once. Google has given no date for that, but the March 2025 change shows the direction.
What this means for an entrant
- Start the Google verification and CASA process in month one, in parallel with the build. It is 6–10 weeks of calendar time and a hard gate on Google OAuth beyond 100 users. Budget $1k–6k a year in lab fees.
- Launch on app passwords for Google and OAuth/Graph for Microsoft. That is the cheapest compliant combination as of October 2026; build Google OAuth as the second path, not the first.
- Offer bring-your-own OAuth client for agencies and enterprises. It moves verification off your critical path and is a security selling point in the EU (see GDPR and ePrivacy).
- Turn Microsoft's December 2026 default-off into a migration offer: a one-click "reconnect via OAuth" for inboxes failing with
5.7.30, aimed at customers of incumbents whose Microsoft inboxes break. - Keep a protocol abstraction (see Sending architecture) so a policy change at Google or Microsoft is an adapter swap, not a rewrite. Track policy shifts on Provider crackdowns and Provider rules: Google, Microsoft and the ESPs.