Deliverability versus delivery

Deliverability is a term so many people use every day, but what do we really mean when we use it? Is there an accepted definition of deliverability? Is the concept different than delivery?
At a recent conference I was running a session talking about email delivery, senders and the roles senders play in the email industry and at that particular organization. The discussion went on for a while, and the subject of deliverability versus delivery came up. J.D. Falk had a comment about the difference that resonated with me. Paraphrased, he said:

Delivery is what happens to a particular email. It is what ISPs are most concerned about.
Deliverability is the delivery potential of a particular email. It is what marketers, commercial senders and ESPs are concerned about. Deliverability is more than just “can this email be delivered”, it is the sum total of factors that play into email marketing: relevance, structure, content, and reputation.

This was such an insightful comment. I can help clients improve their deliverability, but only if they’re willing to make some changes to what they’re doing. Deliverability not just telling the ISPs that the mail is good and that it should be accepted, but is more about sending mail that recipients want and that they will tell the ISPs they want.
When thinking about deliverability improvements you can make, remember that deliverabilty is not just the email, but the whole process from address acquisition through purchase.

Open rates climbing, click rates dropping
Campaign stats and measurements

Related Posts

When the script doesn't work

DJ asks in the comments of Friday’s post:

As Seth said, great reminder. For those that have great processes/channels in place, I’ve found incredible success. However, sometimes I’ve found my answer on Twitter (i.e., @godaddyguy). Also, there have been times where I’ve gone through the script (i.e., shaw.ca) and have never heard back. What then?

Read More

Email is store and forward

Many of us are so used to email appearing instantaneous, we forget that the underlying protocol was never designed for instant messaging. When the SMTP protocol was originally proposed it was designed to support servers that may have had intermittent connectivity. The protocol allowed for email to be spooled to disk and then sent when resources were available. In fact, almost everyone who was around more than 10 years ago knows of a case where an email took weeks, months or even years to deliver.
These days we’re spoiled. We expect the email we send to friends and relatives to show up in their mailbox within moments of sending it. We expect that sales receipt or e-ticket to show up in our mailbox within instants of a purchase. We expect that our ISPs will get us email immediately, if not sooner.
But there are a lot of things that can slow down email delivery. At several points in the process an email may be spooled to disk. It stays on the spool until the next part of the delivery process can happen. Other points of slowdown include the various anti-spam, anti-virus and anti-phishing protections that ISPs must implement. Then add in the extreme volume of email (around 10 billion messages a day) and all of a sudden email delivery is slower than many senders and recipients expect it to be. This delay is not ideal, but the system is designed so that mail is not silently discarded.
While individual emails may be delayed, most users will rarely see that delay in the email that they send. Bulk senders, who may be sending thousands or hundreds of thousands of emails a day, may see more delays in a single send than the average user sees in years of sending one-to-one email.
Email is store and forward, not instant. Sometimes that means there is a delay in getting email into the recipients inbox. And, sometimes there isn’t anything anyone can do to speed up delivery, except to adjust expectations of how email works.

Read More

Personal Contacts at ISPs: Part 2

I’ve talked quite a bit recently about working with ISPs and personal contacts. Today I have an example of what not to do.
One of my ISP friends informed me that another blogger published correspondence from an individual at that ISP, including the individual’s full contact information. The correspondence wasn’t a big deal, the blogger was assigned an IP address by their ISP that was previously used by a spammer. The ISP had a block on the address and he was contacting them to get the block removed. It was totally a misunderstanding on the blogger’s part and the blogger removed the info when the ISP contacted him. Still, once something is out on the net, it’s out there forever.
Don’t do that. Really. When someone at an ISP helps you, don’t go publishing their information on a blog somewhere. They will find out, even if it’s just because their mailbox explodes or their phone starts ringing off the hook with multiple calls about an “emergency” situation. It hurts the person who helped you, who now has to deal with a major increase in volume and work load, and they’re never going to help you again.
This also hurts the rest of us, as ISP employees retreat farther and farther away from contact with senders. Even those of us who are careful with contact information may find it hard to get responses when others in the field are spreading info around.
I know some ISPs can be difficult to get any information from. That’s part of my reason for publishing the ISP information page was to help people find the right contact information. I think it’s extremely important for delivery professionals to understand that you don’t need a personal contact at an ISP to resolve most issues. What you do need is a deep understanding of SMTP, a smattering of knowledge about DNS and HTTP, a firm grasp of privacy issues and an understanding of the dynamics of email.

Read More