What domain-wide delegation is
Domain-wide delegation is a Workspace admin granting a service identity the ability to act across every mailbox or calendar in the domain, for the scopes listed in that grant. The people whose mailboxes it reaches are not asked: the admin's approval stands in for all of them.
That reach is the point. A tool that audits forwarding rules across a fleet, or sets a leaver's out-of-office, has to work inside mailboxes whose owners will never see a consent screen. Used carefully, delegation is what makes fleet-wide mail work possible. Used carelessly, it is the single approval in a Workspace estate most worth a second look.
How it differs from a user OAuth consent
A user OAuth consent is a person approving scopes in Google's own window: they see the list, they approve it, and the approval is theirs. Domain-wide delegation is a separate, customer-approved grant: the customer's admin makes it in their Admin console, it names a service identity rather than a person, and it applies across the domain.
The two lists need not match. A vendor can request a narrow set of scopes at the consent screen while holding a much broader delegation grant, or the reverse: nothing forces the lists to line up, and approving one tells you nothing about the other. In particular, the consent screen does not narrow the delegation grant. The grant authorises exactly what its own scope list says, whatever the consent window showed.
Why this matters when a tool asks for both
A tool that signs in an admin and also works inside mailboxes needs both: an OAuth consent for the admin who signs in, and a delegation grant for the work that happens inside mailboxes. That is a legitimate shape, but it means one review is not enough. Read each list on its own terms:
- Read the consent scopes as what the vendor can do as the signed-in admin.
- Read the delegation scopes as what the vendor can do as anyone in the domain, without asking them.
- Treat a mismatch between the two as a question to raise, not a fault to excuse: ask why each list contains what it contains, and expect a per-scope answer.
The grant list is the boundary that matters. Approve the scopes you can explain to your customer in one sentence each, and revisit the list when the vendor adds features: a grant approved for last year's product quietly authorises this year's too.
What to ask any vendor requesting delegation
- Exactly which scopes does the grant list? Ask for the list in writing, scope by scope, with the feature each one serves. Decline anything the vendor cannot tie to a feature you actually use.
- Can the list be narrowed? If you only buy the mail features, ask whether the calendar and file scopes can stay out of the grant, and whether the product degrades honestly when they do: a gap named on screen, not a silent failure.
- What signs the requests? Ask whether the vendor authenticates with a downloadable key file or a keyless signing path. If key files exist, ask where they live, who can read them, how often they rotate, and how a leaked one would be noticed.
- Where is use of the grant recorded? Actions taken under delegation happen without the mailbox owner being asked, so the record is the only account of what happened. Ask where each use is logged, whether the log would show tampering, and how you would get a copy during an incident.
Make the review repeatable
Keep your own record of each grant you approve: the scope list, the date, the vendor's per-scope answers, and the features you bought at the time. When the vendor ships something new, check the grant before you turn the feature on: new features often mean new scopes, and a scope added to a grant deserves the same review the original list got. And when a relationship ends, on either side, remove the grant as deliberately as you made it, rather than leaving it to age in the background.
How CrossTenant handles it
CrossTenant is built on the model this guide recommends. Delegated requests are per-operation least-privilege: each call carries exactly the scope it needs, within the grant the customer has declared, and the declared grant can be narrowed per tenant. Signing is keyless by default, and production refuses downloaded service-account key files. Tenants marked read-only are refused mutations by the server, not by hidden buttons. And before any consent is requested, a pre-consent trust screen lists every OAuth scope the console will ask for, tagged read or write, with plain-language copy explaining each one.
Domain-wide delegation stays what it is: a separate, customer-approved grant, made by the customer's admin and reviewed with the customer on its own terms. The trust screen governs the OAuth consent; it does not stand in for that review. The full model is on the security posture page and in the trust & security statement.
Field guides
Ask us these questions first
The scope list comes before the consent: the trust screen shows every OAuth scope, tagged read or write, before anything is approved.