The ‘no-reply’ problem…

Well, a reply-to address is an email address that receives a reply in place of your usual email address. So, it can be set up in your email program or when sending out newsletters. When a recipient replies to your email, the reply-to address is where the email gets sent, not to the email address from where the message originated.

Now, here’s the problem, most emails are dispatched from email addresses like noreply@ or no-reply@ indicating to the recipient that replying to this email will likely receive a bounce.

Why is adding a reply-to address so difficult? You tell me!

Here’s why this post came about. This week I received an email from MountainDuck.io with an upgrade offer. Mountain Duck lets you mount server and cloud storage as a disk in Finder on macOS and the File Explorer on Windows. So we can open remote files with any application and work like they were on a local volume.

This does sound great, but the version of the Mountain Duck app I have didn’t work quite well with an iDrive e2 Cloud Object Storage account I was using. When compared to its sibling CyberDuck which is a Cyberduck is a libre server and cloud storage browser for Mac and Windows with support for FTP, SFTP, WebDAV, Amazon S3, OpenStack Swift, Backblaze B2, Microsoft Azure & OneDrive, Google Drive and Dropbox, I’ve had excellent results and been a licensed user of CyberDuck too.

Both apps are great for what they do, yet I had pushed Mountain Duck to the limit when moving some 400 GB of personal data to iDrive and had a few hiccups. The issue is, as a fallback I used CyberDuck and for the files that gave me trouble with Mountain Duck, CyberDuck did a fine job and uploaded them — easy peasy!

So this week, when the upgrade offer for Mountain Duck arrived in an email, I thought I’d write a tiny note saying, ‘Oh my, upgrade price is too steep for an app that made me go back to CyberDuck because of continuous connectivity issues (Mountain Duck was not as robust)!’ And at the back of my mind I knew, this could bounce right back. And it did!

Mail delivery failed: returning message to sender

Now, whenever you get a “Mail delivery failed” message, it means that the destination (also called a recipient server) has rejected your email for some reason, and the reason is also shared in the failure notice:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

 noreply@mountainduck.io
   host mail.mountainduck.io [54.228.253.92]
   SMTP error from remote mail server after RCPT TO:<noreply@mountainduck.io>:
   550 5.1.1 <noreply@mountainduck.io>: Recipient address rejected:
   User unknown in virtual alias table
Reporting-MTA: dns; server1.spiderz.com

Action: failed
Final-Recipient: rfc822;noreply@mountainduck.io
Status: 5.0.0
Remote-MTA: dns; mail.mountainduck.io
Diagnostic-Code: smtp; 550 5.1.1 <noreply@mountainduck.io>: Recipient address rejected: User unknown in virtual alias table

Which, in our case, means that the email address in the ‘FROM’ of the email I received from Mountain Duck was a ‘noreply’ address, designed really, to send you a message, but not receive a reply.

I have never liked this, if you’re emailing, have your ‘noreply’ address forward replies to your support system. Otherwise, simply use a reply-to address!

A reply-to address tells email programs to send a reply to the reply-to address, not to the one where the email comes from! And from a customer experience point of view, it’s the single best thing to do, when you want to reply to questions or hear feedback.

So remember, when sending newsletters or any form of legitimate bulk email, say notifications or announcements, always have a reply-to address in place. You never know, you may have an eager client writing to tell you that your upgrade discount isn’t that great!