Why naming who opened a group email needs the full Gmail permission

A group email is one message with several names on it. Gmail's own API sends exactly that: one message, once, to whoever the headers name. Naming which one of those people opened it needs a different part of Gmail entirely, reached by exactly one OAuth scope, https://mail.google.com/. Nothing narrower gets there, and this page is the honest account of why.

Every claim below traces to one of three places: the RFCs that define email itself, Google's own documentation of what a Gmail permission is and what getting it involves, and the code this product actually runs. None of it is a workaround, and none of it is Onmindo's word for how Gmail behaves.

A group email is one message to a mail server

A group email starts as one message naming several recipients, and stays one message until something further down the mail system decides otherwise. What you actually wrote and sent is a set of header fields, To, Cc and Bcc among them (RFC 5322 defines all three), wrapped around one body and submitted once. Nothing in that structure requires more than one delivery; it only requires that whoever reads the message see every name on it.

Whether the mail system underneath turns that one message into one delivery or several is a separate decision, made by a different part of the stack, and answering it differently is where every difference in this post comes from.

The Gmail API sends what the headers say

users.messages.send is the call behind ordinary sending: hand it one message and Gmail delivers it to whoever the To, Cc and Bcc headers name, once, as one message. That is the whole contract. The API reads the same header fields a mail client would show a reader, and takes its recipients from nowhere else.

So it cannot show five names on a message while delivering that message to only one of them. Sending five separate calls, one per recipient, fixes who receives what, and it costs the header: a copy addressed to one person can no longer carry the other four in its To line, so the recipients stop seeing each other. Whatever the API sends is whatever the headers say, because the headers are the only instruction it has.

SMTP keeps the envelope apart from the headers

RFC 5321 is the protocol a mail server actually speaks to hand a message to another one, and it has its own addressing, separate from anything written in the message: a MAIL FROM command, and one RCPT TO command per recipient. Together these are called the envelope, and it is what a receiving server reads to decide where the message goes. The header fields RFC 5322 defines, the ones a reader actually sees, ride along inside the message and are never consulted for delivery.

That gap between the two is what makes per-recipient delivery under one shared header possible. The same To line, listing everyone, can sit on every copy of a message, while each copy's envelope names exactly one RCPT TO address. Everyone still sees everyone in the header they read, and the server still delivers each copy to one person, because delivery reads the envelope, not the header.

Exactly one Gmail permission reaches SMTP

Gmail's own SMTP submission server accepts exactly one OAuth scope over XOAUTH2: https://mail.google.com/. Nothing narrower authenticates there. Google's own scope list describes it as "Read, compose, send, and permanently delete all your email from Gmail" (read from Google's Gmail API scopes page on 8 September 2026).

That scope sits in Google's restricted class, the same class as the read and compose scopes a Gmail integration needs for sequences or thread summaries. Reaching it is not a checkbox. Google's own verification process ends, for a restricted scope, in a paid third-party security assessment, and Google's own published estimate for that stage of review alone is six weeks, on top of the brand and sensitive-scope review that has to pass first. The fee is not paid to Google. It is paid to whichever lab runs the assessment.

What that means when you use Onmindo

The full permission is asked for once, on its own consent screen, only from the person who turns on naming who opened a group email. Nobody else's account is asked for it, and ordinary sending, scheduling and templates never ask for it either. Decline the extra consent, or leave the feature off, and a group send still goes out as one ordinary message, and the popup still reports one shared "Opened" with a line saying it cannot say which recipient that was. Switch the feature on, and each copy carries a pixel of its own, which is what lets an open carry a name.

Two costs come with the permission rather than with the header. Each copy is a separate submission, so a send to five people spends five against the daily sending cap, the same cap that opens at 20 messages on a new account's first day and grows from there: a send to twenty five people is not possible on day one, whatever the recipient list says. And a copy that fails partway through is never retried. The addresses already sent to received a real message, so retrying would send them a second one, and the sender is told exactly which addresses went out and which did not. What a sender actually sees, row by row, is the fuller picture; this page is about why the permission is the price of it.

The honest version of the permission argument

Connecting Gmail to Onmindo asks for one scope by default: permission to send mail, plus the email address of the account, both in Google's sensitive class rather than its restricted one, and every feature past that asks for what it needs separately, on its own screen, the moment it is switched on. That claim is straightforwardly true, and it stays true for every sender who never turns naming-who-opened on.

The day a sender switches that feature on, they grant the exact permission Google's own consent screen describes as reading, composing, sending and permanently deleting all their email from Gmail: the same wording Mailtrack asks of every user, on its free tier included, whether or not that user ever opens the group-attribution feature (Mailtrack's Google Workspace Marketplace consent screen, read 8 September 2026). What changes between the two products is who is asked, and when: one sender, once, the day they choose the feature, against every user of the other product from the day they install it.