Send As is a delegated mailbox permission that lets one account send email as if it were another mailbox or user. The recipient sees the impersonated identity in the From field, so the permission is controlled as privileged access and should be granted and reviewed carefully.
How Send As Works
Send As is a delegated mailbox permission that changes how mail is presented to recipients. The sender can act through another mailbox or user identity, so the permission behaves like privileged access rather than a routine convenience feature.
Because the recipient sees the impersonated identity in the From field, the control affects both trust and accountability. In practice, the permission determines who can speak on behalf of an account, which means it should be treated as an authorization decision with real business and security consequences.
Why Send As Is Sensitive
Send As is sensitive because it can create messages that look fully native to the mailbox owner. That makes it useful for assistants, shared mailboxes and service workflows, but it also means a misused grant can be indistinguishable from legitimate correspondence at the point of receipt.
The core security issue is impersonation through delegated authority. If the permission is broader than intended, an actor can send convincing mail that may trigger approvals, reset requests, data sharing or other trust-based actions from recipients who rely on the displayed sender identity.
Common Business Uses and Control Boundaries
Organisations usually use Send As for shared functions such as executive support, team mailboxes, departmental inboxes and process automation. The control boundary matters because the permission should match the operational role, not simply the technical ability to access a mailbox.
That boundary is easiest to lose when a mailbox is repurposed, ownership changes, or delegation is granted informally to solve a short-term need. Clear approval paths and ownership records help prevent a shared mailbox from turning into an open-ended impersonation channel.
What Good Governance Looks Like
Send As should be reviewed as part of privileged access management, with attention to who has the permission, why they need it, and whether the business still requires it. The safest pattern is to keep the grant narrow, document the owner, and periodically confirm that the delegate’s role still justifies the authority.
Logging and monitoring are also important because the permission can be abused without changing the mailbox owner’s password. A strong governance model treats Send As as a controlled exception, not a standing convenience, and removes it when the business justification expires.
Risk and Threat Considerations
Send As creates a phishing-adjacent abuse path because it lets an authorised delegate generate mail that appears to originate from a trusted mailbox. If that permission is overbroad, stolen, or left active after role changes, it can support fraud, social engineering, and concealed misuse of a trusted identity.
Failure mechanism: An attacker, malicious insider, or careless delegate uses the permission to send credible messages under a trusted From address, bypassing recipient suspicion and weakening mailbox-based trust controls.
Impact: Recipients may act on fraudulent requests, sensitive data may be disclosed, and incident response can be delayed because the message appears to come from a legitimate account.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Send As requires managing delegated mailbox permissions as controlled account access. |
| AC-6 — Least Privilege | Send As is a privilege that should be limited to the minimum delegation needed. | |
| AU-2 — Event Logging | Send As misuse is best detected through audit records of message origin and delegation use. | |
| Recommendation — Review delegated mailbox permissions periodically and remove stale Send As access. Limit Send As grants to the smallest set of users and mailboxes needed for the role. Log delegated sending activity so impersonation misuse can be investigated quickly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Send As is an access-control decision over who may act through a mailbox. |
| Recommendation — Define and enforce approved delegation rules for mailbox sending authority. | ||
Practitioner Guidance
Governance implication: Treat Send As as a privileged delegation that requires explicit ownership, approval, and periodic recertification. The right question is not whether the feature works, but whether the named delegate still needs authority to represent that mailbox.
What to watch for: Unexplained message volume, unexpected changes in sending patterns, delegation granted to accounts outside the expected business role, and stale permissions after staff movement or mailbox reuse.
Practitioner takeaway: If a mailbox can speak for someone else, the permission deserves the same scrutiny you would give any other authority to impersonate a trusted identity.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org