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. By default, we do not send non-delivery reports (NDRs) back to the original sender.
How We Handle Bounces
The process of capturing and processing bounces is handled for you automatically by our servers. We do this by sending your messages using a Variable Envelope Return Path (VERP). This allows our servers to get the messages and pull out the hard failures, so we can add them to the Suppression List, which blocks further messages from being sent to these addresses. Stopping further failed message attempts can improve your reputation as a sender.
Sample of an NDR message from SocketLabs
Why NDR's are Disabled Initially
Since we will be handling the bounces, you will not see any come in to your original return path address. 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.
NDR failure alerts can also cause 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.
- Navigate to the server dashboard.
- Select Configuration->Settings.
- Select "Non-Delivery Reports".
NDRs count toward server message allotment
Each NDR, bounce message, or feedback loop that we forward back to you counts towards 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 message for the initial failure
- 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 allow 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.
Fowarding Feedback Loops
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. SocketLabs processes this feedback loop to unsubscribe complaining recipients.