ACCESS AND SECURITY
What a warmup tool can do inside your mailbox, and how to take it back
A warmup service has to send from your mailbox, read what arrives and move messages out of spam, so whatever method you use grants broad access to your mail. OAuth can be revoked per app; an app password lasts until you delete it or change your password. Revoking stops future access, not data already copied. Write the revocation step down before you click Authorize.
Why warmup needs more access than most tools
Warmup works by exchanging messages between your mailbox and a network of other mailboxes, then opening, replying to and rescuing those messages from spam so the filters see engagement. That means the service does three things with your account: it sends as you, it reads your incoming mail to find its own messages, and it moves or labels messages. There is no narrow version of that job. A tool that only sends cannot warm, and a tool that can move messages out of spam can technically see the rest of the folder.
A placement tester is different: you send to its seed addresses and it reads its own inboxes, so it never needs access to yours. Keep that distinction in mind when a single vendor sells both, as MailReach does.
The three ways a tool connects, and what each hands over
| Method | What the tool gets | How it ends | What to watch |
|---|---|---|---|
| Google OAuth | The scopes shown on the consent screen. Google classifies full mailbox access (https://mail.google.com/, read, compose, send and permanently delete) and gmail.modify as restricted | Remove the app from your Google Account's third-party access page | Read the scope list on the consent screen, not the vendor's marketing page |
| App password with IMAP and SMTP | A 16 digit passcode that opens the mailbox over IMAP and SMTP, so full read, send and move access | Delete the app password, or change the account password, which revokes all of them | Google says app passwords are not recommended and are unavailable on many organization accounts |
| Microsoft 365, OAuth or SMTP AUTH | Delegated permissions the user or admin consents to, or SMTP AUTH on the mailbox | Revoke the grant in Entra ID; disable SMTP AUTH on the mailbox | If security defaults are on, SMTP AUTH is already disabled |
Sources: Google for Developers, Gmail API scopes; Google Account Help, app passwords; Microsoft Learn, configure user consent; Microsoft Learn, SMTP AUTH in Exchange Online. All read on .
On the Google side, the restricted classification is not a label for decoration. Google states that apps using restricted scopes must pass OAuth verification, and that if they store or transmit that data on their servers they must go through a security assessment (Google for Developers, Gmail API scopes). That is a useful question to ask a vendor: has your app completed the verification for the scopes it requests? MailReach, for example, documents a Gmail connection by app password, with 2-Step Verification and IMAP enabled (MailReach help, connecting Gmail with an app password, read on ).
What revocation does, and what it does not
Revoking access is fast on both providers, and it is only half of offboarding.
- Google OAuth. Once you revoke a linked app, Google says they can't access your data anymore, but also that you may need to contact the developer to ask them to delete the data they already have (Google Account Help, third-party access).
- Google app password. Remove it from the App Passwords page. Google also revokes every app password when you change the account password (Google Account Help, app passwords).
- Microsoft Entra ID. Admins review and revoke an app's permissions under Enterprise apps. Microsoft notes that permissions granted by users cannot be revoked from the portal, only through Graph or PowerShell, and that revoking does not stop users from consenting again (Microsoft Learn, review permissions granted to enterprise applications).
The sequence for switching tools without a gap, and the exports to take first, is in switching warmup tools. The register itself is part of the client report template.
The real risks, in order of likelihood
- Access that nobody remembers. The most common failure is not a breach, it is a trial connected two years ago that still holds a valid grant. An inventory beats any vendor promise.
- A shared or reused credential. An app password pasted into a shared document or a client's spreadsheet is a full mailbox credential. Google warns that sharing your account password with a third party gives it full access to your account.
- A consent phishing lookalike. Microsoft recommends allowing user consent only for apps from verified publishers, to reduce the risk of malicious apps tricking users into granting access (Microsoft Learn, configure user consent). Check the publisher on the consent screen.
- A vendor incident. If the warmup service is compromised, every connected mailbox is exposed at the level of access you granted. That is the argument for dedicated sending mailboxes rather than a founder's or a client's main inbox.
- Warming a mailbox you do not control. For an agency, connecting a client's mailbox under your own account means the client cannot revoke it without you. Have the client own the grant.
What to check before you connect a mailbox
- Which mailbox. Prefer a dedicated sending mailbox over a personal or shared inbox that holds contracts, invoices or password resets.
- Which method, and whether your admin allows it. On Google Workspace, admins can mark each third-party app as Trusted, Limited, Specific Google data or Blocked, and can refuse all unconfigured apps (Google Workspace Admin Help, control which apps access data). On Microsoft 365, user consent and SMTP AUTH may already be off. Ask first; a tool you cannot connect cannot be piloted.
- The exact scopes or protocol. Screenshot the consent screen or note the IMAP and SMTP settings, and file them with the date.
- The vendor's answers, in writing. What data is stored, for how long, where, whether the app completed Google's verification for restricted scopes, and how deletion is requested at cancellation.
- The revocation step. Who revokes, where, and how you will verify it worked, written before anyone clicks Authorize.
- The owner. One named person per mailbox holds the grant, the vendor account and the cancellation.
These checks slot into the access plan line of the warmup pilot protocol. Provider specific limits and admin paths are in warmup on Google Workspace and Microsoft 365.
Questions people also ask
Is OAuth safer than an app password for warmup?
Usually, yes, for two documented reasons: the grant shows a scope list you can read, and it can be revoked per app without touching anything else. An app password opens the mailbox over IMAP and SMTP with no scope limit, and Google itself says app passwords are not recommended. Neither method narrows what warmup needs, which is send, read and move.
Can a warmup tool read my other emails?
Technically, with the access it needs, yes. Whether it does is a vendor policy, not a technical limit. That is why the checks above ask what data is stored and for how long, and why a dedicated sending mailbox is the safer choice.
I cancelled the subscription. Is access revoked?
Not necessarily. Cancelling billing and revoking access are separate steps. Remove the app or the app password on the provider side, verify it is gone, then ask the vendor in writing to delete stored data.
Does a placement test need access to my mailbox?
No. You send a message to the vendor's seed addresses, and the vendor reads its own inboxes. That is one reason to run a test before connecting anything to a warmup service. See GlockApps vs MailReach for the two testers.