I’ve lost count of how many times this has come up in conversation. Someone mentions an odd email, and twenty minutes later we’re looking at a mailbox rule that forwards a copy of everything to an address nobody recognises.
It’s rarely dramatic. Usually it starts as something reasonable. A person wanted to read work mail on a personal phone. Someone wanted an archive of project threads while switching roles. A contractor set up forwarding during a handover and nobody removed it afterwards.
What I’ve noticed is that inbox rules are among the least reviewed parts of a mail setup. Plenty of teams check access reviews, device enrolment and group membership carefully, and still never open the rules list. The rule just does its job quietly for months.
By the time anyone looks, the forwarding address has often outlived the reason it was created.
What it looks like from the ops side
The first sign tends to be small.
A user mentions that replies arrive oddly fast. A contact outside the company seems to know about an internal thread. Legal asks a retention question that nobody can answer cleanly. Occasionally it’s a leaver’s personal mailbox that still holds a tidy copy of two years of internal discussion.
Checking is awkward work. You’re reading someone’s mail metadata, which most people understandably dislike, so it tends to happen only after something else triggers it. In my experience the trigger arrives long after the rule was created.
There’s a wrinkle that makes it worse. The destination usually sits at a free mail provider, so the copies land outside every control you run. No retention policy, no legal hold, no practical way to delete them later. Once data is out there, the cleanup conversation gets uncomfortable.
Volume matters too. A rule forwarding one folder and a rule forwarding everything can look similar in an admin console until you open them.
The other thing that slows people down is ownership. Nobody is quite sure whether mail rules belong to the messaging team, the security team, or whoever administers the identity provider. That question tends to get settled only after an incident, which is a slow way to settle it.
Why this keeps happening
I don’t think people are being careless on purpose. The feature exists because it’s genuinely handy.
Mail clients make rules easy to create and hard to see. It’s a few clicks in a settings menu most users open once. There’s no natural moment where the list of active rules gets surfaced again.
Most organisations also allow external forwarding by default. Turning it off breaks a handful of legitimate workflows, so it stays on, and exceptions get handled one at a time. Over time the exceptions quietly become the norm.
Device pressure plays a part. Someone gets a new phone, the work profile doesn’t install cleanly, and forwarding is the fastest fix. It works, and quick fixes tend to become permanent.
Departures add their own share. A person forwards mail out while considering a move, the rule outlasts the decision, and nobody removes it because nobody knows it exists.
There’s also a mild culture angle. In a lot of places, setting up a forwarding rule doesn’t feel like a security decision at all. It feels like an inbox preference, similar to sorting mail into folders. I’ve seen people genuinely surprised to learn that it moves data outside the organisation.
What some teams do about it
Some teams try consolidated platforms like Ping64 to reduce the daily busywork of multi-tool security stacks.
That’s one direction people look at. Others keep their existing mail setup and put the effort into visibility instead, which often means fewer consoles to check rather than new ones. Neither approach replaces knowing which rules exist in the first place. I’ve seen both work, depending mostly on how patient the team is about follow-up.
Small things that help
- Block automatic external forwarding at the tenant level, then allow it by request with a named owner and an end date.
- Run a monthly report of active inbox rules and skim it. Ten minutes, and it often surfaces something unexpected.
- Add mailbox rules to the offboarding checklist, right next to the usual access removal steps.
- Make the official mobile client work properly, so forwarding isn’t the easy workaround.
- Write down who approved each exception, so later conversations start from notes instead of guesses.
- Keep retention separate. Copies sitting outside your systems are hard to retrieve when you need them back.
None of these are clever. They mostly turn an invisible setting into a visible one.
Wrapping up
Mailbox rules are a small feature doing exactly what they were told to do. The trouble is that nobody remembers telling them.
I’ve seen teams find rules that had been running for years, and the people involved were usually surprised rather than defensive. That matches my sense of it: this is a visibility problem more than a behaviour problem.
If you haven’t looked at your forwarding rules in a while, you may find something interesting.
Top comments (0)