If your company or organization sends a lot of email, chances are you use a “no reply” address in the FROM header of your email campaigns. You’re thinking that a lot of mail probably gets sent to that address — and you’d be right. You’re thinking that there’s no way to justify the time it would take to process that mail. Here, you’d be … umm, somewhat less right.

What’s a no-reply address?

A no-reply address is a dummy email address used in the FROM header of email campaigns. Often the address is literally something like “noreply@example.com.” If you search your mail archive for “no reply,” you’ll probably find dozens of these. This sort of address gets used when a sender wants to notify subscribers that they shouldn’t bother trying to reply with questions or requests.

Large, successful companies like LinkedIn and NewRelic no doubt have many other ways for subscribers to contact them. I can understand that they’d prefer not to have to also process freeform email replies. However, if they’re not monitoring these “no reply” addresses, they’re missing a critical source of actionable deliverability information.

(Just for fun, we tested the addresses above, by sending a message to each. LinkedIn not only does not monitor that no-reply address; they don’t even receive mail there. That is, the FROM address used in their notifications is not even a legitimate email address.)

Who would ever send mail to a no-reply address?!

Senders often seem to assume that nobody would ever bother to send an email to an address that looks like “no-reply@example.com.” But people do, frequently and repeatedly. Who do you know who isn’t in a hurry, at least some of the time, who might not notice the “no reply” message hidden in the email address? Besides, email is usually a conversation, not a broadcast. We can hardly blame our subscribers for assuming they’re allowed to write back.

Computers write back too, all the time. Automated vacation replies often get sent to the FROM address. Bounces sometimes go to the FROM address. They shouldn’t, but they do.

BitBouncePermission-based email filter services like BitBounce and SpamArrest send their challenge messages to the FROM address. More on these below.

Do any of these replies actually matter?

Some of these replies can be ignored. Vacation replies and “out of office” replies are a great example. Occasionally you’ll see a vacation reply announcing a 6-month or longer sabbatical. If your organization is struggling with inbox rates, pausing or unsubbing subscribers who won’t be engaging for a few months would be a good idea.

An even longer-term “vacation” reply…

Many organizations use the vacation reply feature to announce that employees have retired or left the company. These should be treated as unsub requests. If you continue to send email to an abandoned mailbox, the best case scenario is that the mailbox is eventually deleted, and the address bounces, and your systems intercept the bounce and unsub the address. But that could take months, during which this address is hurting your engagement rates. If the address is forwarded to someone else, that recipient might well complain about the “spam” you’re sending. It is far better to unsub these addresses as soon as the initial retirement message comes in.

A more colorful unsubscribe request…

What about personal replies, though? This message here is an unsubscribe request. Judging from the tone of the request, this subscriber’s next move would be to complain to Yahoo. That’s something we want to avoid; every complaint is strike against the sender’s reputation.

Whitelist challenges, aka the email Turing test…

How about the BitBounce / SpamArrest replies mentioned above? Those challenges can be treated in either of two ways:

  1. Respond to the challenge, to get your mailstream whitelisted into the subscriber’s inbox.
  2. Or unsub the address.

If you don’t do either, you’ll continue to send emails that that subscriber will never see. And if that subscriber uses one of the big mailbox providers, then this subscriber is hurting your list’s engagement rates. Either get these people engaged (by responding to the challenge request), or take them off the list.

Failed forwards from Microsoft…

This particular form of reply is a goldmine of actionable deliverability data, because Microsoft, for many senders, presents the biggest challenge of the big three MBPs to maintaining decent inbox rates.

Microsoft’s various mail systems allow subscribers to forward mail to a 3rd-party address, e.g. Gmail, Yahoo, or any other destination. If the forwarded message bounces, Microsoft’s backend systems will notify the FROM address of the original message. So, for example, if you send a newsletter to bob@hotmail, but Bob set up his Hotmail account to forward to his iCloud account, but then went on vacation and his iCloud inbox filled up, then Microsoft will email you to tell you that Bob’s iCloud address bounced. At that point, you’d probably want to unsub bob@hotmail because you’re not able to reach that subscriber, and further, that address is very likely hurting your engagement rates as seen by Microsoft.

If you have your DMARC policy set to reject, then most of your Microsoft-hosted subscribers who are forwarding mail out of Microsoft’s mail system will bounce — because the ultimate destination MBP (iCloud.com in the above example) will see your FROM address, look up the authentication, and reject the message unless you’ve specifically whitelisted Microsoft’s SMTP IPs, which would be a bad idea.

If you have a large mailing list, it is conceivable that you have thousands of subscribers whose mailboxes are hosted by Microsoft… but none of them show any engagement at Microsoft because they forward their messages out of Hotmail/Outlook to a different provider. Removing those subscribers can materially improve your engagement rates, and eventually your inbox rates too.

How Practical Is This?

Hopefully this article demonstrates the value of processing the replies sent to the FROM address on your email campaigns. But how practical is it, and is it really worth the effort?

In our experience, this effort is more than justified. We’ve seen a material increase in inbox rates, especially at Microsoft, due to this sort of processing.

By the way, the point of this is not necessarily that these replies need to be processed manually. If you have access to developer resources, it’s not that difficult to filter out large subsets of ignorable replies: any mention of phrases like “on vacation,” “annual leave,” “closed for the,” “away from,” etc., can trigger automatic deletion. Similarly, the phrases “retired” or “no longer,” and the headers associated with BitBounce, SpamArrest, and the Microsoft bounces would trigger further processing.

If you need help getting your systems set up to properly process replies, let us know.