When a user departs an organization, the Exchange admins are often requested to do something with the departed user’s email address to deal with any emails that continue to be sent to the former staff member. Obviously email is such an important communications channel, and individuals are often situated in critical paths for various matters, that it’s normal to feel concerned about what might happen if someone emails the person after they’ve left the organization.
There’s a few different approaches that can be taken, each of which has pros and cons.
- Configuring an out of office message for the mailbox requires that the mailbox still exists (so it can’t be fully decommissioned), and will only fire once per sender, so there’s a risk that a sender will misinterpret the out of office message as a temporary absence. Out of office messages are also typically not processed by automated email systems that cleanse a database of inactive email addresses so as to avoid continually emailing them.
- Configuring an server-side inbox rule introduces the risk of an infinite loop if the auto-reply goes to an address that will also automatically respond. And again, this requires that the mailbox still exists.
- Moving the email address to a catch all mailbox, or assigning it to another person, requires someone to manually inspect and deal with any messages that continue to be received.
- Configuring a transport rule or some other server-side processing to notify senders that an email address is no longer active, similar to out of office, will also mean that automated systems don’t cleanse the address from their database.
- Dropping the message entirely, and sending a non-delivery report to the sender, tends to freak people out because of a fear of some critical email being lost.
There’s no single, perfect solution, because every organization is different.
If you still need the SMTP address itself to remain active (e.g. the person was the sole purchasing officer when the company started, but there is now a purchasing team with a shared mailbox), then you can forward or move the SMTP address to another mailbox to continue dealing with business critical emails. That’s a fine approach, and doesn’t bother the sender with unnecessary notifications. It’s also a good way to correct such issues in the long term, transitioning key communications away from individual email addresses and towards generic email addresses that can survive individual staff turnover.
But if you want senders to stop using that email address, what you definitely shouldn’t do is send automatic replies from now until the Earth is consumed by our exploding sun. Like this one.
I receive that notification every week when I send my newsletter. It’s 100% useless, because it doesn’t tell me which email address I sent the email to, and there’s more than one email address for that domain in my subscriber database. If they simply allowed a non-delivery report to be sent, my email service would automatically scrub the address from the database, which is required by anti-spam laws in some countries, as well as by the GDPR rules in the EU. They’re not the only organization doing it either. I get a handful of them every week from the same domains, all equally useless because they don’t tell me exactly which address is no longer in use.
Now, obviously I could email their info@ address and ask them which email address is the inactive one. That creates work for them to do, checking their own logs to see which email addresses my newsletter is going to and then working out which one is inactive. I can then manually remove it from my subscriber database. Multiply that by the number of organizations who are sending this type of notification to me, and those who will do it in future, and it starts to waste quite a lot of people’s time. And that’s just my newsletter. The same notification is going to an unknown number of other senders, most of which would scrub the address if a proper NDR was sent, so the pattern of email traffic to that departed user’s email address should quickly reduce to almost nothing.
If you want people to stop using an inactive email address, the ultimate goal should be to get to a point where the departed user’s email address is no longer valid in the organization, and any messages sent to it result in a non-delivery report to the sender. How you get to that goal is up to you. An approach that tends to work for my customers is:
- Enable out-of-office message for departed user. This will catch anyone who forgot or didn’t know the person was leaving, and they can self-correct.
- Grant mailbox access to another individual, or forward the mailbox to another individual. I prefer to grant mailbox access instead of forwarding, because it creates an audit trail of access to the departed users mailbox and items. The individual can review the mailbox for any important correspondence that still comes in.
- After a reasonable period (30 days is enough, in my experience), decommission the departed users mailbox. If you want to retain the mailbox but stop it from receiving emails, configure the mailbox to reject all senders or create a transport rule to do the same. Exchange Online customers can use inactive mailboxes to retain the data instead, if you prefer.
Just please don’t set up an infinite auto-reply.
Great article Paul. Disagree with your forecast of the sun going nova though. More likely it will become a red giant.
Under GDPR you cannot give another employee access to the mailbox of people who leave the company, without consent. Also you cannot catch the incoming e-mail of people who leave the company (by assigning their mail address to another mailbox).
Thank you for this article. I manage 7 customer facing email inboxes for our company and was looking for an efficient method to communicate the closing of one of them. This helped me to draft the auto-reply with the pertinent info and establish a timeline to completely close the inbox (30 days). Thanks again 🙂
This article is a huge validation for me. We typically both grant access to the existing mailbox AND forward new mail to the same individual or a small distribution group for the former user’s team. It’s getting them to give it up after 30 days I struggle with. But it’s nice to see so many points I’ve made to managers spelled out so cleanly in the article and helps me know I’ve been leading my users in the right direction.
Well written Paul, I linked this articel to my HR-Department.
Missed you at Summit!
Norbert from Bremen / Germany
Thanks for this article, Paul. I wanted to share a solution I saw at a customer. They we’re running a daily PowerShell task to get all Mailboxes with activated OOO. Then they deactivated and activated the OOO again. With the OOO mode freshly activated, a sender would receive an OOO notification everyday, they’re writing mails to an OOO activated mailbox.
Omg a bit overdone imo.