VERP (Variable Envelope Return Path) is where you encode the return-path address (remember that from last week) on a per-recipient basis, uniquely changing it for each recipient. If somebody sends an email to two people, you and me, your copy of the email message will have a return-path header with a one code in it, and my return-path header will have a different code in it. (You can find examples over on the VERP Wikpedia page.)
Why? VERP helps email sending platforms (ESPs, CRMs, etc.) more easily track which email messages weren't delivered -- which ones bounced back to the sender.
To understand how VERP helps with bounce tracking, we need to understand how bounces are communicated between senders and receivers. There are basically two ways bounces can be communicated back to a sending email platform.
During the SMTP transaction -- the communication between mail servers where the sending platform is handing off a message to the receiving mailbox provider. The receiving provider can say "no thank you" and decline to accept the message, right then and there. The message usually never gets transmitted. The sending platform can just log that failure (bounce) right then and there. No need to send an non-delivery report via email. The sending platform is in full control of the message transmission, so they know which subscriber was non-deliverable, and they know the exact bounce message that the receiving mailbox provider gave back. Easy peasy. These are often referred to as "synchronous" bounces.
AFTER the message has been delivered via SMTP. The sending platform hands the message off to the mailbox provider. Then, for whatever reason, sometime after that point, the mailbox provider decides that they can't deliver the message to the end recipient's mailbox, so they "bounce" it back -- sending an NDR (non-delivery report) email back to the return-path address. These are often referred to as "asynchronous" bounces.
Asynchronous bounces are a huge pain to deal with. Because spammers often use fake email addresses when sending spam. And that includes return-path addresses. So asynchronous bounces, in that scenario, go .... somewhere. Usually to the wrong place, to the wrong person. An unsuspecting joe, who had nothing to do with the original message. This is called backscatter. If you're lucky, maybe you've never heard of it. That's because mailbox providers and anti-spam providers have tried very hard to stop sending asynchronous bounces, because receiving backscattered bounces makes people unhappy.
Barracuda used to send backscatter, but no longer does. The same goes for AOL. It was not uncommon for email gateways or ISPs to have scenarios where something could fail, an address book lookup might not be available, so they'd just accept the message with the hopes of queuing it for checking later. And if that later check failed...boom, backscatter could happen.
Backscatter still happens, but much less than it used to. Why? Because so many ISPs and mailbox providers have moved away from ever sending asynchronous bounces, if they can help it.
Anyway, what does this have to with VERP? VERP is almost a necessity when it comes to processing these delayed (asynchronous) bounces. It helps the sending platform denote which send to which address cause the bounce message. It's very much a good thing, in that context.
But since delayed bounces are rapidly becoming a thing of the past, do we really still need VERP any more? I mean, it's been around forever. It has its own Wikipedia page, and here's an overview of how VERP works from Dan Bernstein from 1997. That's 25 years ago! About five eternities in email time.
VERP has a bit of a flaw in that most implementations assume every email message they receive and process, to a VERP-encoded bounce address, must be a bounce message. That means that spam to a bounce address can trigger a false positive bounce. Which means that if your sending platform auto-suppresses addresses that bounce, there are scenarios where spam can falsely cause addresses to get suppressed or unsubscribed. (The same thing can be a problem for the mailto: style list-unsusbcribe header.)
You'll find some email service providers and CRM platforms support VERP, and some do not. Don't worry if your email sending platform doesn't support it. It's much less necessary today, compared to fifteen years ago. And particular implementations of VERP can make email authentication more complex (a hard coded bounce tracking domain can impede proper SPF alignment, necessary for DMARC success). So if you want my vote, I vote no for VERP. If you're building a new email sending platform, don't spend the effort to implement VERP. And if you're working on a platform that already has VERP implemented, it might be time to retire it.
VERP (Variable Envelope Return Path) is where you encode the return-path address (remember that from last week) on a per-recipient basis, uniquely changing it for each recipient. If somebody sends an email to two people, you and me, your copy of the email message will have a return-path header with a one code in it, and my return-path header will have a different code in it. (You can find examples over on the VERP Wikpedia page.)
Why? VERP helps email sending platforms (ESPs, CRMs, etc.) more easily track which email messages weren't delivered -- which ones bounced back to the sender.
To understand how VERP helps with bounce tracking, we need to understand how bounces are communicated between senders and receivers. There are basically two ways bounces can be communicated back to a sending email platform.
Asynchronous bounces are a huge pain to deal with. Because spammers often use fake email addresses when sending spam. And that includes return-path addresses. So asynchronous bounces, in that scenario, go .... somewhere. Usually to the wrong place, to the wrong person. An unsuspecting joe, who had nothing to do with the original message. This is called backscatter. If you're lucky, maybe you've never heard of it. That's because mailbox providers and anti-spam providers have tried very hard to stop sending asynchronous bounces, because receiving backscattered bounces makes people unhappy.
Barracuda used to send backscatter, but no longer does. The same goes for AOL. It was not uncommon for email gateways or ISPs to have scenarios where something could fail, an address book lookup might not be available, so they'd just accept the message with the hopes of queuing it for checking later. And if that later check failed...boom, backscatter could happen.
Backscatter still happens, but much less than it used to. Why? Because so many ISPs and mailbox providers have moved away from ever sending asynchronous bounces, if they can help it.
Anyway, what does this have to with VERP? VERP is almost a necessity when it comes to processing these delayed (asynchronous) bounces. It helps the sending platform denote which send to which address cause the bounce message. It's very much a good thing, in that context.
But since delayed bounces are rapidly becoming a thing of the past, do we really still need VERP any more? I mean, it's been around forever. It has its own Wikipedia page, and here's an overview of how VERP works from Dan Bernstein from 1997. That's 25 years ago! About five eternities in email time.
VERP has a bit of a flaw in that most implementations assume every email message they receive and process, to a VERP-encoded bounce address, must be a bounce message. That means that spam to a bounce address can trigger a false positive bounce. Which means that if your sending platform auto-suppresses addresses that bounce, there are scenarios where spam can falsely cause addresses to get suppressed or unsubscribed. (The same thing can be a problem for the mailto: style list-unsusbcribe header.)
You'll find some email service providers and CRM platforms support VERP, and some do not. Don't worry if your email sending platform doesn't support it. It's much less necessary today, compared to fifteen years ago. And particular implementations of VERP can make email authentication more complex (a hard coded bounce tracking domain can impede proper SPF alignment, necessary for DMARC success). So if you want my vote, I vote no for VERP. If you're building a new email sending platform, don't spend the effort to implement VERP. And if you're working on a platform that already has VERP implemented, it might be time to retire it.
Want to learn more about deliverability terminology? If so, be sure to visit the DELIVTERMS section here on Spam Resource.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.