Email forwarding is the routing of messages sent to one address into another mailbox. It is the mechanism that makes aliases useful, because users can publish many addresses without managing many inboxes. Security teams should understand forwarding paths, since they affect monitoring, retention, and incident response.
Expanded Definition
Email forwarding is the delivery of messages received by one mailbox or address into another destination mailbox, often through an alias, distribution rule, or mail gateway configuration. In NHI and IAM operations, it matters because forwarding can obscure where a message is finally read, retained, or acted on, which affects auditability and incident triage. Definitions vary across vendors when forwarding is implemented alongside shared mailboxes, delegation, or automated routing rules, so practitioners should separate simple address aliasing from post-receipt message movement. That distinction becomes important when forwarded mail contains secrets, approval requests, or identity verification links, because the security controls around the sender, the original recipient, and the final inbox may differ. Forwarding also interacts with retention, DLP, and access reviews, since a mailbox can appear unused while still receiving sensitive content elsewhere. The most common misapplication is treating forwarding as a harmless convenience, which occurs when administrators fail to map hidden delivery paths in environments with layered mail rules and delegated access.
Examples and Use Cases
Implementing email forwarding rigorously often introduces visibility tradeoffs, requiring organisations to balance user convenience against message traceability and control.
- A security team maps executive assistant forwarding rules so approval requests do not bypass monitoring or retention controls.
- A SaaS operations group uses aliases for role-based inboxes, but reviews whether forwarded alerts land in a mailbox with appropriate access logging.
- An incident responder traces a suspicious reset email through a forwarding chain to determine whether an account takeover occurred through a mailbox rule.
- A mail administrator compares forwarding configuration against guidance in the NIST Cybersecurity Framework 2.0 and internal policy to confirm the path is authorised.
- A governance team references the DeepSeek breach research when explaining how a single exposed mailbox or downstream route can broaden exposure far beyond the original inbox.
Forwarding is also used in customer support queues, contractor offboarding, and temporary coverage during leave, but each case should be time-bound and documented. The operational question is not whether mail can be delivered elsewhere, but whether the organisation can prove who received it, when, and under what authority.
Why It Matters in NHI Security
Email forwarding can become an NHI control issue when messages carry credentials, verification links, or workflow approvals that grant tool access. If forwarding rules are unmanaged, attackers may silently redirect password resets, admin notifications, or security alerts into an inbox they control. That creates a blind spot in both detection and response, especially when the original account still appears legitimate. NHIMG research shows that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, underscoring how quickly a forwarded secret can become an active compromise path. In practice, forwarding also complicates evidence preservation because the destination mailbox may sit outside the system owners’ standard review process. For governance teams, this means mail routing should be assessed alongside identity hardening, not treated as a separate messaging concern. The term becomes operationally unavoidable after a reset link, approval notice, or API key has already been forwarded into the wrong mailbox and used before anyone noticed.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Forwarding can hide secret movement and weak mailbox boundaries, which this control targets. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access depends on knowing where sensitive mail ultimately lands. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of delivery paths and recipient trust. |
Map forwarding destinations to authorised roles and remove routes that bypass intended access boundaries.
Related resources from NHI Mgmt Group
- When does SSH forwarding create more risk than value?
- When should organisations rethink email as the primary identifier?
- Why do browser-based prompt injections create a bigger trust problem than email summaries?
- How should security teams implement AI agent email access without over-granting permissions?
