Home » Exchange Server » What's Wrong with Auto-Replies for Inactive Email Addresses?

What's Wrong with Auto-Replies for Inactive Email Addresses?

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. 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:

  1. 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.
  2. 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.
  3. 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.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Andreas says:

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *