Delegated mailbox permissions are mailbox access rights that let one user or account read, send, or manage another mailbox. They are usually granted through directory or mail system roles, and may include full access, send as, or send on behalf permissions, with audit logs used to track who acted on the mailbox.
Mailbox delegation as an access control problem
Delegated mailbox permissions are not just a convenience setting, they are an access control decision that extends one principal’s reach into another mailbox. The security question is who can act, what they can do, and whether that access is still justified for the business role that needs it.
Because mailbox permissions can allow reading, sending, or managing mail, they affect confidentiality, integrity, and sometimes legal or operational accountability. A delegated mailbox often behaves like shared trust, so the permission model should be treated as a privileged pathway rather than a routine collaboration feature.
Common delegated permission types
Mailbox delegation usually appears in a few distinct forms. Full access lets a delegate open and manage mailbox content. Send as lets the delegate send mail that appears to come directly from the mailbox owner. Send on behalf preserves the delegate’s identity while still using the mailbox relationship.
Those differences matter because they shape both user expectations and forensic interpretation. A message sent with send as can look indistinguishable from the owner’s own activity to a recipient, while send on behalf leaves a clearer attribution trail. Organizations should know which permissions are actually in use, not just which ones are nominally assigned.
Why delegation changes mailbox risk
Delegation expands the blast radius of a compromised account or a poorly governed admin action. If a delegate is phished, over-privileged, or left in place after a role change, the mailbox relationship can become a route to sensitive correspondence, internal approvals, invoice fraud, or impersonation.
Risk also increases when delegated access is layered onto high-value mailboxes such as executives, finance, legal, or service mailboxes. In those cases, mailbox permissions can become a persistence mechanism for an attacker or a social-engineering enabler for a fraud attempt.
How to govern and verify delegated access
delegated permissions should be granted for a specific purpose, reviewed periodically, and removed when the business need ends. The operational control is simple in principle: know who has access, why they have it, and whether that access still matches current duties.
Audit logs are essential because mailbox delegation is easy to forget once it is granted. Administrators should verify not only permission assignments, but also whether a delegate has used those rights recently, whether stale access remains after team changes, and whether mailbox activity lines up with expected business processes.
For guidance on designing safer mailbox and application consent relationships, see Entra ID Applications and Consent Guide, and for broader permission design trade-offs, see Authorisation Models Guide.
Detection and response for mailbox delegation abuse
Detection should focus on unexpected permission changes, unusual sending patterns, mailbox access from unfamiliar locations or devices, and delegation that appears outside approved support or business workflows. A mailbox that suddenly begins sending requests, payment instructions, or internal approvals is a strong review trigger.
Post-incident review should include permission history, message traces, audit logs, inbox rules, and any evidence that a delegate used the mailbox to persist, conceal activity, or impersonate the owner. If the mailbox also stores identity resets, billing changes, or sensitive correspondence, the response should treat it as a business-process compromise as well as an access event.
For operational guidance on safer privileged access patterns, see Privileged Access Management Guide and Security Awareness for Executives and Assistants Guide.
Risk and Threat Considerations
Delegated mailbox permissions can be abused for impersonation, business email compromise, and quiet persistence because the mailbox relationship is often trusted by recipients and overlooked by defenders. The same access that helps an assistant or service desk act efficiently can also let an attacker send believable mail, read sensitive threads, or maintain access after the original user thinks the issue is resolved.
Failure mechanism: Excessive or stale mailbox delegation, combined with weak review and weak detection, allows unauthorized sending or mailbox review without needing to defeat the mailbox owner directly.
Impact: Attackers can impersonate trusted users, divert payments or approvals, harvest sensitive correspondence, and preserve access to communications that drive further compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Mailbox delegation depends on governed account and access assignment. |
| AC-6 — Least Privilege | Delegated mailbox rights should be limited to the minimum required mailbox actions. | |
| AU-2 — Event Logging | Mailbox delegation needs audit events for access and message actions. | |
| Recommendation — Review delegated mailbox access as part of account lifecycle management and remove unnecessary assignments promptly. Constrain mailbox delegation to the smallest access scope that satisfies the business need. Log mailbox delegation changes and mailbox actions so investigators can reconstruct who acted. | ||
| CIS Controls v8 | CIS-5 — Account Management | Mailbox delegation is a privileged account and access management issue. |
| Recommendation — Inventory delegated mailbox rights and remove stale or unjustified access. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Delegated mailbox access can become excessive privilege when broader than needed. |
| NHI-01 — Improper Offboarding | Delegated mailbox rights often persist after role change or departure. | |
| Recommendation — Reduce mailbox delegation to the minimum privileges required for each role. Revoke mailbox delegation during offboarding and role transitions. | ||
Practitioner Guidance
Governance implication: Treat mailbox delegation as a privileged relationship that needs ownership, approval, and periodic recertification. The right question is not only whether the permission works, but whether the business case for that permission still exists and whether the delegate should be using a narrower access pattern instead.
What to watch for: Pay close attention to high-value mailboxes, broad full-access grants, and permissions that outlive role changes or offboarding. A permission model is only as safe as its removal process.
Related resources from NHI Mgmt Group
- What is the difference between delegated permissions and application permissions in Microsoft Graph for mailbox access?
- Why do delegated mailbox permissions create security risk in Exchange Online?
- Why do delegated mailbox permissions increase phishing automation risk?
- Why do granular vault permissions matter in delegated support models?