Handing an email address to an app involves two separate things: providing a contact address when creating an account, and permitting entry to an inbox. The first gives the app an identifier that it can keep on file, pass on under its own privacy policy, and lose in a breach. The second opens message contents to the app. A per-app alias narrows the first exposure only, and each of the two requires its own check before it is given.
Gmail scopes and inbox access
On a Google account, inbox access is created through linked apps and OAuth scopes, and the scope names describe the access in plain language. Google's Gmail scope reference lists gmail.readonly as "View your email messages and settings", gmail.modify as "Read, compose, and send emails from your Gmail account", and the full mailbox scope https://mail.google.com/ as "Read, compose, send, and permanently delete all your email from Gmail". Google lists all three scopes as restricted, and states that an app which stores restricted-scope data on servers, or transmits it, must go through a security assessment. A Nylas scope reference confirms the same classification, and notes that gmail.send is sensitive rather than restricted, while gmail.labels is non-sensitive. A read-only tool, a send-only tool and a full mail client therefore need different scopes, and a consent screen that asks for more than the feature requires is asking for access the feature does not use.
A Gmail scope governs the mailbox, not the signup record. An app granted a read scope keeps that scope whatever address was used at signup, until the grant is revoked.
Restricted scopes carry a heavy verification load, and the size of that load signals how sensitive the access is. A guide to Google's verification process summarises Google's stated estimates as about six weeks for restricted-scope verification, with the security assessment repeated every 12 months. The developer bears that load, not the account holder. For the account holder, the practical consequence is that an app seeking inbox access for a stated feature, such as a mail client or a trip summary tool, is seeking a grant that remains in force after the feature has been used, until it is revoked.
Reporting on third-party Gmail access shows why that persistence matters. A Mailbird guide summarises Wall Street Journal reporting that some third-party applications scanned Gmail message contents, with employees at some companies reading mail as part of algorithm training or debugging, under permissions users had granted. That reporting is from 2018, so it is not evidence about any specific app today, but it illustrates the structural point: a broad inbox grant covers every message in the mailbox, not only messages relevant to the feature.
Signup address exposure
A signup address works as a stable identifier across services. Apple defines an email address as contact info in its App Store privacy definitions, and defines emails and text messages, including subject line, sender, recipients and contents, as a separate user-content data type. That separation is the core of the distinction. A signup address on its own does not expose message contents, but it does expose the holder to contact from that app, to inclusion in that app's customer records, and to the consequences if those records leak.
Breach figures show how large that exposure can become. Have I Been Pwned displayed 1,048 pwned websites and 17,846,896,404 pwned addresses on its homepage when checked on 1 November 2026. A count of the service's public breach list, published by TechCity on 10 October 2026, found 108 breaches added between 1 January and 10 October 2026, covering about 539.8 million accounts, with email addresses present in all 108. A Clean Email explainer on the same service notes that a breach result shows exposure, not account compromise, and that a clean result is not proof that an address never leaked. Signup risk therefore accumulates: every additional app holding the same address adds another record that can leak, be shared, or be matched against other records.
App store labels give a partial view of that sharing before signup. On Google Play, apps must complete a Data safety section, and a OneSignal guide to that section notes that an email address must be disclosed as a collected data type when an app or its third-party service collects it. On the App Store, Apple defines tracking to include sharing data with a data broker for targeted advertising or advertising measurement, in the same privacy definitions page. Both labels are developer declarations rather than audit results, so a label describes what a developer states, not what an independent check confirmed.
Sign-in providers
Sign in with Google and Sign in with Apple look similar on a signup screen, but they grant different things. Google states that a basic profile request covers name, email address and profile picture, and that a linked app may separately request permission to view, copy or manage account data, according to Google Account Help. Signing in with Google therefore does not by itself grant inbox access, and inbox access appears only when the consent screen lists a Gmail scope. The consent screen is the document that matters, not the button label.
Apple's Sign in with Apple takes a different signup route. Apple Support states that a user can choose to share an email address or hide it, and that the Hide My Email option creates a unique relay address for that app or website, on the @private.icloud.com or @privaterelay.appleid.com domain. Only mail from that app or website's designated addresses reaches the verified Apple Account email. Apple also states that it does not read or process message content passing through Hide My Email, except for standard spam filtering, and that messages leave relay servers after delivery, usually within seconds. The relay address therefore narrows signup exposure in the same way a per-app alias does, without granting inbox access or restricting access granted separately.
Revocation and copied data
Google states that linked apps can be reviewed or removed at any time, and that after revocation an app cannot access the data anymore, according to the same Google Account Help page. A SaneBox guide describes the same steps: open the Google Account Security section, open the third-party access list, select the app, and choose Remove Access. Google also states the limit of that action, in that a user may need to contact the developer to request deletion of data the app already copied. Revocation stops future access, but it does not retrieve copies already made, and it does not delete the app's own account record. For Workspace accounts, administrators have a separate control: Google's Workspace admin documentation lists the Gmail scopes above as high-risk scopes that an administrator can restrict, and notes that details about authorised apps typically appear 24 to 48 hours after authorisation.
The same limit applies to a signup address, since deleting an app does not guarantee deletion of the address from the app's records, from any third party it was shared with, or from breach data. Containment at signup therefore matters more than cleanup after the fact.
Pre-signup checks
Four checks cover most cases. The first check is the consent screen: a signup that lists only a basic profile, or an email address for account creation, is a signup-address act, while a consent screen that lists a Gmail scope is an inbox-access act, and the scope name states the access. The second check is the app store label: a label that lists an email address as data linked to identity, for advertising or tracking, states a sharing position that can be weighed before signup. The third check is the privacy policy, read for the sharing section rather than the introduction, since the relevant question is which third parties receive the address, and for what purpose. The fourth check is the sign-in method: where Sign in with Apple with Hide My Email is offered, or where a per-app alias is available, the signup address can be isolated to that app from the start.
A refusal is also a legitimate outcome, since an app that requests inbox read access for a feature that does not need it, such as a game with no mail feature, requests access disproportionate to its function.
AliasFleet signup addresses
AliasFleet provides email aliases that forward to a verified destination inbox. Each alias is a separate address assignable to one app, so mail from that app arrives through that alias alone. The free plan, as listed on the AliasFleet homepage on 1 November 2026, includes 10 active forwarding privacy aliases, 1 verified destination inbox, and 100 MB monthly forwarding. An alias that starts receiving unwanted mail points to the app that holds it, and disabling the alias stops mail through that address. AliasFleet states on the same homepage that it applies no email scanning and no ads.
An alias does not change inbox access. An app granted a Gmail read scope keeps that scope regardless of which address was used at signup, because the scope governs the mailbox, not the signup record. An alias also does not delete an address from an app's records after signup, and it does not prevent an app from sharing the alias address under its own policy. The value of the alias is containment at signup: one app's leak, sharing or spam exposes one address, not the address used for every other service.
Main points
Giving an app an email address at signup is a contained risk when the address is unique to that app, because the exposure is limited to that app's records and its handling of that address. Granting an app access to read an inbox is a different and larger risk, because the grant covers message contents across the whole mailbox, persists until revoked, and cannot be undone for data already copied. The distinction points to a default: isolate the signup address per app, and grant inbox access only to an app whose core function needs it, after reading the scope on the consent screen.
Top comments (0)