The mail settings nobody files under security

Email security usually means filtering. Phishing protection. Malware. Links. Attachments. Quarantine.

Underneath all of that are quieter settings that can decide who reads a mailbox, who sends under another person's name and where copies of company mail are delivered. They often live in mail administration rather than in the identity system.

That is why they are easy to miss in an access review.

Delegation is standing access to a mailbox

Mailbox delegation is completely legitimate. An executive assistant needs access. A colleague provides cover during leave. A finance function is shared between several people.

But delegation is still access. A temporary grant does not necessarily disappear when the temporary situation ends.

Someone returns from leave. The delegate remains. A reporting line changes. The grant remains.

The people involved stop thinking about it because everything still works. That is how a convenience becomes a long-lived permission.

The right question is not whether delegation should exist. It is whether every current delegation still has an owner and a reason.

Send-as widens the identity that can speak

Send-as rights solve another legitimate problem. A team needs to send from finance@. Support agents need to reply from a shared address. An assistant may need to communicate on behalf of an executive.

For functional addresses, this is often exactly the right design. The risk changes when several accounts can send using an individual's address.

The visible From address may no longer tell you which account initiated the message. Investigation may depend on the mail platform's audit records rather than what the recipient sees. That matters when the identity belongs to someone who can authorize money, credentials or sensitive business changes.

The permission itself is not the problem. Unreviewed permission is.

External forwarding is a standing egress path

Automatic forwarding is easy to underestimate because it looks like a mailbox preference. Operationally, it is a continuing data transfer. Every matching message can leave the controlled company environment without the user doing anything further.

Sometimes that is an explicit business requirement. Sometimes somebody forwarded work mail to a personal account years ago because it was convenient. And sometimes a forwarding rule was created after an account compromise.

The outcome is similar enough that it deserves central visibility. For many organizations, blocking uncontrolled external auto-forwarding is a sensible default. Where an exception is required, it should be deliberate, attributable and reviewed.

Also remember that forwarding can be implemented in several ways:

• A forwarding setting.
• An inbox rule.
• A filter.
• A routing rule.
• Another mail-flow mechanism.

Checking only one of those gives you only part of the picture.

The identity review does not always see this

A SaaS access review might show that someone has Google Workspace or Microsoft 365. It will not necessarily tell you that the same account can open another person's mailbox, send using an executive address or continuously forward messages outside the organization.

Those permissions live deeper inside the mail system. This is an important boundary between identity governance and platform administration.

The identity provider controls the front door. The application still has permissions of its own.

Offboarding deserves the same question

Disabling a departing employee's account is necessary. It does not automatically answer every relationship that account had with other mailboxes.

Was the person a delegate elsewhere? Did they hold send-as rights? Were shared mailbox permissions changed? Did they create forwarding or routing that still exists?

Offboarding is safer when mail permissions are part of the checklist rather than something discovered later.

What to enumerate

Start with administrative reporting rather than opening people's mail.

• List current mailbox delegation.
• List send-as and send-on-behalf permissions.
• Separate permissions on functional mailboxes from permissions on named individuals.
• List external forwarding destinations, including rules and filters where your platform exposes them.

Then compare the identities involved with current employment and current business ownership. The interesting entries are usually not the large shared functions everyone recognizes. They are the ones nobody remembers creating.

The check worth running

Pull the list of external forwarding destinations for the whole environment. Read every destination.

Personal mailbox providers deserve explanation. An unfamiliar external address deserves investigation. And every legitimate exception should have somebody who can still tell you why it exists.

Explore this expertise: Email Security

All technical notes