Your login for our support center is different than your Control Panel login.

Click here to create a login for the support center

 Knowledgebase
Knowledgebase
How SocketLabs On-Demand Servers Handle Non-Delivery Reports(NDRs) and Bounces

One of the major benefits of the SocketLabs On-Demand service is providing a single central location to see the status of all your messages, including those that failed delivery.  We employ an array of technologies to collect and analyze failures that occur and provide the details to you in your reports. Since our services have such a wide range of uses, we do not send non-delivery reports (NDRs) back to the original senders by default.

Along with the ability to view message failure details in the reports section of the Control Panel, you can also take advantage of our suite of APIs to access failure data and details.  Our Notification API will push, in real-time, all failure events that occur in response to the messages you are sending. Your options regarding how to utilize this data are endless once you are storing it in your own databases.

Another reason that by default we do not automatically enable non-delivery reports back to senders is that failure alerts can cause what is known as backscatter spam.  This occurs when failures notifications are directed to forged From addresses on malicious email messages.  We always reserve the right to disable NDRs at any time, if we detect any malicious abuse of these options, or if we determine that it is causing a negative impact on our business, network, or our other customers.

If you'd like to receive NDR notifications, you can enable this feature in the Control Panel.  Once you log-in to your SocketLabs account, navigate to the server dashboard by selecting "View" next to the ServerID you wish to modify.  From the server dashboard select Configuration -> Settings from the top menu navigation bar.  From the settings page use the submenu of "Advanced Features" to select Non-Delivery Reports.

Please be aware that each NDR, bounce message, or feedback loop that we forward back to you will count against the monthly message allotment for the server.  This means that sending a message to an invalid address will result in two messages counting against your allotment. The first for the initial failure, and a second message for the notification back to the sender.

The configuration page allows for a number of different customized options.  First, you can select whether this feature is Enabled or Disabled altogether.  If you Enable the feature you can select between sending NDRs back to the original sender, to a single static address, or to both the sender and a static address.  You can also decide whether or not you would like to receive a report when the SocketLabs platform prevents delivery due to the address being present on your suppression list.  

We also allow for you to configure a static address to which we can forward the bounce messages we are processing for your server.  A bounce message is different than a standard failure in that the original email was accepted initially by the recipient's mail server, and later the server sent back an error message.  The standard format for bounce messages sent back to us removes the original sender information, so these types of failures can only be forwarded to a single static address.

The final option you can enable is the forwarding of feedback loops.  We have agreements in place with many mailbox providers to receive feedback when a recipient marks one of your messages as spam/junk in their mail client. These spam complaints are known as feedback loops. Some marketing applications are able to process these feedback loops to unsubscribe complaining recipients.  This is the most common reason to enable the forwarding of these notices.

Any other questions about how the SocketLabs platform handles NDRs, bounces, and feedback loops can be directed to our support team.


Comments (0)
Help Desk Software by Kayako  Copyright © 2018 SocketLabs, Inc.  Terms of Service | Privacy Policy | Acceptable Use Policy