The return path is an email address specified during the SMTP protocol communication process that determines where the receiving mail server sends back its bounce messages.
There is a wide range of terminology used in place of the term “Return Path” and some of the alternate terms include: reverse path, envelope from, envelope sender, MAIL FROM, 5321-FROM, return address, From_, and Errors-to. This value should never be seen by the end recipient, but the aliases cause common confusion between the return path and the from address in outbound email message headers.
To allow SocketLabs to capture and analyze bounces on your behalf we use a custom return path address for each and every outbound message you send through our network. This means that we encode unique data about each outbound message into an address and use it in the MAIL FROM protocol command. In these cases, when a message is received back to our custom return path address we are able to decode the specific message details from the address. SocketLabs uses this process to ensure that it can properly receive and report on bounce messages.
Provided below is an example of what a VERP address looks like. Note that the domain that SocketLabs uses on all return path addresses is email-od.com, this can be white-labeled via our Custom Bounce Domains feature.
MAIL FROM: <000A.17.LOCAL=EXAMPLE.COM@MX1.EMAIL-OD.COM>
The use of a VERP address is an industry standard practice and improves the deliverability of outbound messages to major service providers such as Yahoo, Hotmail, AOL, and Gmail.
The use of a Variable Envelope Return Path allows the SocketLabs On-Demand platform to better interpret message failures and provide more accurate details about each failure individually. It also
allows for us to provide a single centralized location to view and access the information about all outbound messages processed through the account.
The use of a VERP address enables SocketLabs to ensure that all the outbound messages delivered through our network pass SPF authentication checks at their delivery point, helping ensure proper
inbox placement. This simplifies the setup process and makes it easier for users who are not familiar with email authentication. For more information on email authentication be sure to see our other
article specifically on this topic: Sender Policy Framework (SPF) with SocketLabs On-Demand.
To provide the most specific details about the bounce messages that come back to us we encode the following details into the return path address:
- SocketLabs Server ID
- Recipient Address
- Custom Mailing ID
- Custom Message ID
The use of both Mailing and Message ID values in the encoded return path address means that it is beneficial to keep these values as short as possible. A return path address over 64 characters may impact deliverability. SocketLabs recommends keeping the combined total character count of these values to less than 30 total characters.
Please see our KB article on Mailing and Message ID numbers for more information: Message & Mailing/Campaign IDs
SocketLabs does not disable the use of a VERP address across an entire account or server. In individual cases, at the approval of our support team, we may disable the use of a variable envelope return path to a specific domain. Please contact our support team at firstname.lastname@example.org for more information.
If you are concerned about no longer receiving bounce messages to your own addresses, please see our knowledge base article that details options for receiving forwarded copies of bounces and non-delivery reports: How SocketLabs Handles Non-Delivery Reports & Bounces.
E-Fax services often authenticate messages using SPF and the return path address. Users may experience issues sending outbound e-fax messages through SocketLabs On-Demand and should contact support to ensure the use of VERP is disabled to the domain of your e-fax service provider.
Any other questions or concerns about your SocketLabs On-Demand account should be directed to our support department at email@example.com.