I’m a lover of magic.  When illusions appear creative, bold, and clever, they seem worthy of being shared with everyone.  On the other hand, if it’s a trick that everyone knows—one that has been around for decades—the “magic” becomes cheap and hollow, unlikely to fool anyone. When it comes to the standardization of email metrics, the question arises: is this truly noteworthy, or simply another case of “Pay no attention to the man behind the curtain?”  Smoke and mirrors won’t work in this case; complete transparency is necessary to address this issue.  It’s time to put all of our cards on the table and examine various aspects of the argument surrounding standardization.

 

Independent email consultants Luke Glaser and John Caldwell, as co-chairs of the DMA/Email Experience Council’s Measurement Accuracy Roundtable, have marshaled a group of industry players to launch an email standardization project.  For what it’s worth, that project is gaining momentum and earning some serious ink within the industry.  This is not the same old dog and pony show we’ve seen in the past; these guys really have their act together.  Think of them as Siegfried and Roy of the email industry.  Their “S.A.M.E” project (Support Adoptions of Metrics for Email) has bent the ears of industry pundits, and their formula for encouraging ESPs to adopt the standards seems to be fooling everyone.  And in this context, deception is a good thing. Learn more about the S.A.M.E project here. 

 

Sleeveless in Seattle 

 

As with any new industry related project, many challenges surface, but without early adopters, we’d be left sleeveless, a nightmare for any magician.  Two ESPs, MassTransmit/EmailTransmit and AllWebMail have already committed to adopting the industry standard for metrics which was released by the DMA/eec in March 2010.  Since then, a dozen other high profile ESPs claim that they will allegedly adopt the standards in the next six months or so, including, but not limited to, BlueHornet, Silverpop, Blue Sky Factory, Bronto, SubscriberMail, and YesMail.  When you think about early adopters, companies like these help pave the road for the rest of the industry to benefit.  As interested ESPs begin to track the progress and milestones achieved by the S.A.M.E project, momentum will build and the benefits will galvanize the industry.

 

“Adoption is not just a semantics game,” says Stephanie Miller, Vice Chair of the DMA/eec and an active member of the Roundtable (her day job is at inbox deliverability solution provider Return Path).  “Marketers usually find out that there are no standards when they go to benchmark their performance, or when they change vendors and realize that all those numbers they’ve been betting their bonus on – they don’t mean what they thought they meant!

“It’s about time our industry stepped up and supported standard metrics just like any other direct marketing discipline,” she says.

 

Deliverability Will No Longer be a Selling Point for ESPs

 

Once the implementation of email standards leads to congruency across the industry, ESPs and marketers will find themselves on a level playing field.  This means marketers will spend more time searching for the right ESP, but once a match is made, marketers will be less likely to move from one ESP to another due to inconsistency in metrics.  This means attrition rates for switching ESPs will fall, which will direct ESPs to focus on supplementary services that will help customers achieve a higher ROI. Examples of such services include compelling creative copy and perhaps a monthly or quarterly SWOT analysis provided by the ESP to each marketer.  Higher performance of the channel benefits all of us.

 

S.A.M.E Project Goals

 

Once a magician takes his oath, he must never reveal his secrets.  However, if aspiring participants are willing to learn magic, they, too, can join the “magic club.”  ESPs face a similar choice.  They can remain on the outside looking in, simply observing the progression of the S.A.M.E project, or they can choose to be an active part of the club.  John and Luke’s first goal is 10-15% of the ESP market adopt the standards.

 

Nowadays, when an ESP reports on the “state of the industry,” they analyze metrics only of their own campaigns, like a magician who looks in the mirror and declares himself successful.  Industry standardization will introduce accountability to the industry, providing the digital marketing community with sterilized benchmarking and consistent reporting.  The spotlight now shines bright on Luke and John, along with other industry veterans and aspiring ESPs involved with the S.A.M.E project. It is their mission to deliver what the email industry yearns for: a final levitation act that will wow the crowd and inspire mass adoption.  They hope to prove that they are master magicians—if they perform their act well enough, even the skeptics will believe. 

 

Here’s How to Get Involved:

 

Marketers:  Send this article to your ESP and encourage them to adopt the standards.

ESPs:  Study the new standard definitions and set a goal for yourself to adopt them.  Be part of the program here:

 

Now, where did all the Rabbits go? J

 

Fred Tabsharani

Port25 Solutions, Inc.

@tabsharani

Our good friend, Ken Pfeiffer Director of Deliverability for Blue Sky Factory, asked us this year if he could do a guest blog post here and of course we jumped on that great opportunity to have a well respected and trusted person in the industry post for us. Thanks to Ken and the Blue Sky Factory team for sharing this!

___________________________ 

As the Director of Deliverability for Blue Sky Factory, an Email Service Provider (ESP), the question I get asked the most often is, "how fast can you send my mail?"

This is a great question with a very simply answer; one that is the same every time I respond: We can deliver as fast as the receiving mail server will accept. This can be a little difficult for some people to understand. 

Most of us are accustomed to near instantaneous delivery. Think about it. If I send a one-off email to you, it's likely that you'll receive it within minutes, if not seconds. There may be a slight delay, but for the most part after you click your send button that email shows up in quick order to the recipient. ESPs on the other hand are senders of bulk email. So rather than just sending email to one recipient at a time, ESP’s send and transmit multiple emails at one time to the receiving mail server.   When I say ‘multiple’ I mean hundreds or thousands or even millions!

Nearly all ESPs use Mail Transfer Agents (MTAs). An MTA is software that is used to transmit email from the sender server to the receiving server.  ESPs use MTAs to optimize email delivery and a good MTA will allow configuration based on the limits of the receiving mail server.  The larger Internet Service Providers (ISPs) have published settings for bulk mailers that will outline how many emails over what period of time they will accept.   Many ISP publish these settings on their postmaster FAQ pages for example (http://security.comcast.net/get-help/comcast-post-master-page.aspx  and http://postmaster.info.aol.com/faq/mailerfaq.html#msgconn).  These are the ISP’s way of saying – if you want to send bulk mail to us, this how you should do it. 

Take for example AOL – they state you can’t send email to more than 100 recipients per message and no more than 1,000 recipients per connection.  The senders MTA should be configured with these values in order to follow with AOL’s specific limits.  If you try and send 2,000 emails to AOL over one connection they will start rejecting your email.  Another scenario to mention is rate limiting.  Some ISP’s rate limit the number of messages you can send for a given time period.  Road Runner limits you to 1,000 messages per hour to non-whitelisted IP’s.  So if you have to send 10,000 emails to Road Runner subscribers you better make sure you only send to 1,000 per hour or you will see your email bounce.  If an ESP were to ignore these settings then most likely Road Runner would begin to reject connections and the emails would bounce.   A bounced email is not what a sender is paying an ESP for. Part of our job is to help clients give their emails every opportunity - for a technology perspective - to be delivered. Whether their emails get blocked or bulked due to content is another story. 

Another factor that can influence delivery time is simply just how busy is the receiving ISP.  ISP’s receive massive amounts of email daily, they like you have limited amount of computing power at their disposal. 

They are only capable of processing so many emails.  Think of it this way: ISP’s are a lot like your local highway.  It’s usually pretty easy driving, except during rush hour where there are just not enough lanes of traffic to handle all of the cars. So a drive that normally takes 15 minutes might end up taking 45 minutes to an hour.  During heavy marketing periods (think Christmas) campaigns that normally in your subscribers’ inbox in 10 minutes might take 30 minutes. 

Keep in mind that each ISP will have different limits, so proper MTA configuration is essential.  If you have concerns or questions, ask your ESP about their connection settings.   From the sender standpoint the best advice I can give is to plan your campaigns carefully with the above factors in mind. If you have a time-sensitive email campaign, be sure to give yourself plenty of lead time to avoid any congestion around sending thresholds and seasonal volume. You may want to consider breaking up your send into a few batches.

I hope I was able to shed a little light on some of the inner workings of email and how it can affect your campaigns and provide a full answer to a question I’m asked all the time. 

___________________________

Ken Pfeiffer

Director of Deliverability

Blue Sky Factory, Inc.

 

Don’t just deliver, engage!

 

I was digging through my closet today and found this hat. The hats were given out as chachka at a unique email industry meetup hosted by the Berkman Center at Harvard University on a very cold winter day in January, 2004. I think Trevor Hughes was responsible for the hats.

I believe this meeting was one of the first times that SPF, Sender-ID and Domain Keys were revealed publicly. I remember Hans Peter Brøndmo speaking about the vision of Project Lumos a lot of passionate debate about the future of email and the need for Authentication, Accreditation and Reputation systems.

My how far we've come! 6 years later SPF is gone, Sender-ID is predominantly used by Microsoft, and DKIM has been adopted by Google, Yahoo! and many others. Authentication is real. Return Path is the de-facto reputation system and also provides accreditation services along with Goodmail and others.

Back then all reputation was IP based. Now we're finally seeing significant movement towards domain based reputation authenticated with DKIM.

Did it "solve" the spam problem? Certainly not. I do think it has helped the overall ecosystem and it surely has made it easier for legitimate senders to get reliably email deliverability.

Were you at that meeting on the cold January day in 2004? What do you remember? What do you think about how far we've come?

Mark Brownlow posted a great series on the future of deliverability at his site Email Marketing Reports.
He started off with getting some well known deliverability experts in the industry together (and I am humbled to have been one of them), got our thoughts and opinions on certain topics ranging from authentication to recipient engagement to spam complaints.  And then, he put it all together in a nice chronological series coming out with a new post every week or so giving you time to digest the previous one.

This is a fantastic tool and resource for folks who aren't as savvy in email deliverability as they'd like to be.  Or, for those who just need a primer to brush up on their skills and knowledge.  As we all know, one of the things that keeps the world of email deliverability so fun and exciting is the ever changing landscape while everyone from senders to receivers tries to figure out what to do next.  We're still pioneering email, folks.  There's a lot of uncharted territory out there just waiting to be discovered.  So, without further adieu, I give you Mr. Brownlow's series broken down by post and topic.

• Future of deliverability: 1. The role of user interaction (click)
• Future of deliverability: 2. The role of authentication (click)
• Future of deliverability: 3. The role of domain reputation (click)
• Future of deliverability: 4. The role of certification (click)
• Future of deliverability: 5. Sender reputation and B2B email marketing (click)
• 192 email deliverability resources (click)

I would especially make sure you have that last link bookmarked as it's chalk full of places to go and people to reach out to if you find yourself in need of further help around deliverability.

Chris Wheeler
Director of Deliverability at Bronto
@ChrisAWheeler

A feature of many mailing programs is the ability to auto-detect the recipient’s email client and then send email that meets the recipient’s capacity to render HTML. In some respects the auto-detect feature is a legacy hangover from the days of text-only email clients. We didn’t all wake up one morning to an email client that was fully capable of displaying complicated CSS driven layouts and pretty graphics. The update was a gradual process and as people adopted more robust email clients marketers began to send more robust emails with increasingly complicated code.

Today we ooh and aah at the beautiful emails our design and production departments generate in hopes of garnering clicks and conversions, but a brief look under the hood reveals a glaring hole caused by some auto-detect systems: sending only one part of a Multi-Part MIME message may cause your email to be filtered as spam.

MIME (Multi Purpose Internet Mail Extensions) extends email by supporting message bodies with multiple sections and varied encodings among other features. This means that you can send both an HTML portion and a TEXT portion in the same message. The recipient’s email client will render the one it is a) capable of rendering and, b) the portion the recipient prefers to see. Contrary to popular belief, not every single person in the world wants to see HTML in their email.

So what’s the problem you ask? The problem is simple: marketers are sending Multi-Part MIME messages but omitting the TEXT part of the MIME. When you send a Multi-Part MIME you are declaring that you are sending more than 1 MIME part—leaving out the TEXT part, or in the rare case that you only send the TEXT part minus the HTML you are in essence breaking the standard.

By not sending both parts of the MIME you run the danger of having your messages flagged by a heuristic filter that specifically checks valid MIME headers that include TEXT & HTML. SpamAssassin score increases, due to triggering this rule, could be as high as 1.672! When you consider that your total heuristic spam score must be under a 5 to deliver to certain ISPs this single rule alone could put you over the top, leaving your carefully crafted email in the spam folder!

Following best practices and technical specs will ultimately help you achieve higher ROI by helping more of your email reach the inbox. Taking short cuts like omitting necessary MIME portions in the hopes of minimally shrinking your message size will probably hurt you more than anything else. Yes, it takes a bit more time to craft the text portion, but look at it this way—you are casting a wider net in hopes of reaching more of your fans and customers that really do want to read your message, even if they’re still using Pine or some other antique mail client.

So not sure how many of you here have been following this, but Microsoft has made an announcement saying that the rendering engine will CONTINUE to be WORD in the next version of Outlook. This of course will continue to heavily impact how your emails will render or not render for several years (did I mention I use a MAC).

I make the assumption here that many already understand the issues with Outlook 2007:

• no support for background images (HTML or CSS)
• no support for forms
• no support for Flash, or other plugins (not that this is a big thing and I don't advocate it)
• no support for CSS floats
• no support for replacing bullets with images in unordered lists
• no support for CSS positioning
• no support for animated GIFs

This information obviously prompted an interesting grassroots use of social media (twitter) Fixoutlook.org where you can file a petition against this.

People like email-standards.org have been advocating a list of recommendation the Outlook team should consider and also posted some GREAT examples of what this will do to your email rendering.

The Outlook team themselves have even posted a response to all this titled "The Power of Word in Outlook"

Now, I know this might be a bit early in the development process and say specifically that this will hopefully NOT continue to happen, but my past experiences with a large company like Microsoft is that they will do what they want no matter how much of a cry is put out there. I for one am still not happy about their community involvment even over the past 10-15 years in email. Please visit http://www.fixoutlook.org and let the Microsoft Office development team know your thoughts.

-Dennis

Eloqua

Don't Just Send, Deliver!

The Email Senders and Providers Coalition (of which I am the co-chair of  the Technology committee) announced today that all members must support MD5 suppression lists by the end of the year. Most ESPs support this already, but there are still some laggards.

Download the full document at http://www.espcoalition.org/042309encryption.php

When the CAN-SPAM act was passed in 2004, it created a new requirement for email marketers to share suppression lists with other companies who do marketing on their behalf. Suppression lists are email addresses of consumers who have clicked on the unsubscribe link. Many companies just share these lists in plain text, which is very insecure and is frequently abused. Spammers steal these lists and send them more email!

Using MD5 to encrypt the email addresses before they are shared protects against spammers abusing them. This was one of the main reasons why I created UnsubCentral - to create a safe, central repository for securely exchanging suppression lists and complying with the CAN-SPAM act.

What does this mean for you?

If you are an Email Marketer

Talk to your email service provider about it! Make sure that you are securing your suppression lists with MD5 and that you are not exposing your users to extra risk and yourself to unnecessary liability. Just because your ESP supports MD5 does not mean that they use it by default. In fact, most ESP's require that you ask them to turn it on.

Talk to your affiliates about it! Make sure that any affiliates who send email on your behalf know that this issue is important to you and that they need to be prepared to accept MD5 suppression lists from you.

If you are an Affiliate Marketer

Make sure you are ready to accept MD5 suppression lists. Make sure your email software or email service provider accepts MD5 suppression lists for your mailings. If your mailing software doesn't support it, you might find it helpful to use this free desktop application from UnsubCentral that lets you compare to MD5 files on your hard drive.

If you are an Email Service Provider

Make sure you support MD5 suppression lists for one-time upload, permanent upload, and for download. This means that a list owner should be able to upload an MD5 encoded file of email addresses into your system as permanent unsubscribes or just to suppress against one single mailing. It means that a list owner should be able to easily download an MD5 encoded suppression list of all the unsubscribes their list has received through your system.

Educate your customers about why they should use MD5 and how it can help protect their subscribers from spam and themselves from legal liability and deliverability challenges. By using MD5 instead of plain text, you make it less likely that a suppression list will get abused and your sending reputation gets tarnished.

How does this affect deliverability?

Lashback tracks unsubscribe compliance by IP address and if your customer's suppression files end up in the wrong hands it will reflect poorly on your IP address reputation. Lashback's UnsubScore is one component of Return Path's Sender Score - so getting a blackmark from them could affect your deliverability at many ISPs.

I have been noticing a rash of emails lately from companies which tout a “private sale”, “email exclusive”, “family and friends” or some sort of exclusivity in their offer because you are an email subscriber. Then, only to find out I have been duped because when I go to the companies site, I notice that my “private sale” is not so private in that everyone who visits the site gets to take advantage of the private sale or the family and friends event is really for every family or every friend who happens to just land on the site.

Here is the deal. If its an email exclusive, make it an email exclusive and not open to the world. If I am a subscriber to your email, make me feel special and offer me something that not any Joe can get just by showing up. As an email subscriber, I took the time to subscribe and read your email and when I joined (hopefully when I got your welcome email) I got this little note saying that I would be receiving exclusive deals in my email.

Touting something that is exclusive when its not is like giving me a photocopy of the Mona Lisa. Give me something unique or just send me an email with your logo and link in it or soon enough, I will tune out your noise

Before you dive into all this information I want you to understand my purpose here of this post. While the majority of you in the email industry tend to focus on the day to day email operations around best practices (complaints, hard bounces, blocks, etc), I feel as if many of you haven't taken the time to see what's next on the horizon for us. There is a new compliance issue coming and it's not as simple as the email stuff you deal with today. Some of you here have a great opportunity to learn something new and take your careers even further still being attached to email and marketing. I have two things I am responsible for here at Eloqua, email best practices for clients and our company and privacy issues for clients and our company. They go hand in hand in a lot of ways and in others they do not, but the compliance aspect of both are VERY similar when it comes to email. So, as you read this... think a little outside your email box today and see what you need to be auditing your clients and company for.

I know some of you email heads have been making sure you have a privacy policy that accurately describes all use of the data you collect and the internet technologies you use and how you monitor that any affiliate or partners that advertise your products, services or website are honoring their imposed can-spam requirements (you’re not free from their actions), but has anyone read or been concerned with some of the impending state legislation about email or website tracking? Now don't be scared just yet...

If your not aware of this, states like New York (NY AB 1393/SB 0616 - Assembly Committee on Consumer Affairs and Protection) are seeking bills to regulate online advertising networks and online preference marketing. It restricts the collection and use of information for online preference marketing, including barring the use of Personally Identifiable Information (PII) in preference marketing, except for PII provided with consent, and requiring the ability for consumers to opt out of the use of their non-PII in online preference marketing. The bill also would require clear and conspicuous privacy and opt-out notices. Sounds easy enough? Well it is and is well supported throughout the advertising industry.

The New York bill like many others are similar if not identical to the Network Advertising Initiative (NAI) principles. The NAI Principles detail the consumer protections its member ad networks agree to provide with regard to the use and collection of personally identifiable and non-personally identifiable information for the purposes of targeting marketing efforts. Included in this framework are the principles of consumer notice, choice, and fair dispute resolution. Here is a graphical representation from the NAI on this if you don't have time to read the above linked principles.

If you not also aware, on February 12, 2009 the Federal Trade Commission (“FTC”) released a revised set of four principles for the self-regulation of online behavioral advertising. Goodwin Procter did a GREAT breakdown/client alert of these principles here.

The highlights from that alert:

Transparency and Consumer Control 

This Principle provides that a website utilizing behavioral advertising should provide a clear, concise, consumer-friendly and prominent statement that behavioral data is being collected. Such a statement should also provide that consumers can choose whether or not to participate. Websites are encouraged to provide  consumers with a clear method for exercising the opt-out option.  

 

Security and Data Retention Policies 

Websites that collect and store user data are encouraged by this Principle to use reasonable security measures to guard that data. Factors to consider in determining the appropriate level of security include the sensitivity of the data, the risks a company faces, the nature of the business and the availability of reasonable protections to the company.  

 

Express Consent for Material Changes 

The company should obtain consumer consent before it uses previously collected data in a way that differs materially from the privacy policy that existed at the time the data was collected. For example, if an acquisition prompts a change in the use of collected data, this Principle encourages the surviving corporation to obtain consumer consent for the new policy. 

 

Express Consent to Use of Sensitive Information

The fourth Principle urges companies to collect sensitive data via behavioral advertising only after a consumer expressly consents to its collection. Such data would include, for example, health information, Social Security numbers and information about children.

So where does your clients and company stand in all of this? Are you in support? Can you comply? Can you stay in business with the methods you use today? This isn't like dealing with Can-Spam here folks. For many this is a whole new ball game for you.

Talk to your attorney's or compliance people  about this.

-Dennis

Eloqua

Don't Just Send, Deliver!

Think that soft bounces are caused by a full inbox? Then think again!

Dela Quist
Alchemy Worx

Most email marketers do not view soft bounces as being a major cause for concern, so rarely, if ever, have any specific strategies been in place for dealing with them. Soft bounces are a very strong indication that one or more ISPs were concerned enough about the reputation of the IP address you are using,  your mailing volumes or the level of SPAM complaints you are generating to temporarily block your campaign.

Over the last two years our agency has begun to take soft bounces very seriously indeed. Compared with soft bounces, hard bounces are relatively straight forward - there are far fewer reasons for their occurrence and only one way of dealing with them, which is to remove them from your list.

The reason so many people don’t treat soft bounces seriously enough seems to be because most definitions of a soft bounce are outdated.  

Here are but two typical examples of the definition of a soft bounce taken from well respected sources:

• A soft bounce just means the recipient's email account was 'temporarily unavailable'. Maybe their server was busy, or the recipient was away on vacation, or their account was too full.

• A soft bounce occurs when the recipient's mail server replies with an error other than 5xx, or never replies at all. An example of a soft bounce error could be caused by a server that overloaded or a user whose mailbox is full.

Most current definitions of a soft bounce do not really convey any sense of urgency or importance, worst of all they seem to indicate that the bounce had nothing to do with your mail marketing practice at all. After all what can you do to stop someone’s server crashing or being taken down for maintenance or a subscriber’s mailbox filling up while they are on holiday?

Some ESPs set the default for removing soft bounces at 10 or more and best practice guidelines typically suggest removal after 3 subsequent bounces, further reducing the sense of urgency.

General definitions of a soft bounce and guidelines for dealing with them haven’t changed for at least five years!

In this time inbox sizes have dramatically increased so 'mailbox full' messages are highly unlikely to occur; Gmail currently offer 7GB of storage! I don’t know anyone who has exceeded their Gmail or for that matter Yahoo or Hotmail storage limit and even if there are such people, they are hardly representative of the average consumer. Even if you have a large number of people using their work email address, how many companies start bouncing potentially valuable communications without letting the user know that their inbox is due a spring clean.

I also suspect that bounces caused by overloaded ISPs (Hotmail etc.) or corporate servers are not as common as the definitions quoted above would seem to indicate.

This means that the most likely cause of soft bounces is ISP blocking.

The way ISPs deal with spam has become much more aggressive and incredibly sophisticated. For a start they are very quick to start blocking emails when they identify suspicious patterns of behaviour from a given sender, IP address or range.

Typical causes of blocking are: lack of authentication or accreditation; poor or unproven IP reputation; fluctuations in the volume of messages sent from the IP address you are using and spam complaints attributed to your IP address. It's important to bear in mind that you may incur soft bounces because of the behaviour of companies sharing your IP address, making the way your ESP handles its shared IP addresses very important.

Emails blocked in this way are recorded as soft bounces, so your soft bounces are important indicators of how 'Spammy' ISP’s think you are at a given point in time. They are an indication of a drop in reputation for the IP address you are using, uneven mailing patterns and/or an increase in the level of SPAM complaints your email is generating.  All of these things are things that you and your ESP can do something about!

The purest definition of a soft bounce is 'A delivery failure with a 4XX/Transient bounce code' examples of which are:

• 421 Grey listing = Re-try now and send again

• 451 no reverse DNS = Re-try now and send again later after you fix your DNS

Soft bounces should be regularly investigated because we believe that they are more likely to be caused by temporary ISP blocking than temporary problems related to individual subscribers.

I would strongly recommend that anyone wanting to get a better understanding of where soft bounces fit in the overall scheme of deliverability should read the excellent 4 part series of articles on 'How Email Works' by Dennis Dayman of Eloqua

-Dennis
Eloqua

Don't Just Send, Deliver!

If you have been just sitting around waiting for the next part of this series, apologies are in order – the industry has been hopping during the month of October.  On the other hand, if you had overlooked the delay, perfect!  Glad to catch up with you!

Hoping that you have had the opportunity to take part in some industry-related event in this past month.  Personally, I have been privileged to speak at numerous events in several states.  I was also proud to take part in Eloqua’s first annual customer event in Las Vegas.  It was hugely successful, and a good time, too!
As you might recall, the plan to tackle the broad topic of “How Email Works” was to break it down into the following sections:

• How MTAs (Mail/Message Transfer Agents) Communicate
• What is a “Bounce?”
• How MTAs Handle Bounces
• How Bounces Can Affect a Subscriber’s Status

We left off in the series discussing “What is a Bounce?” Today, I wanted to talk briefly (yeah, right!) about how bounces are handled in the underbelly of the Internet.

Let’s break it down this way.

When you send a postal letter through the United States Postal Service (USPS) there are five (5) specific locations that will be crucial to the exchange.

1. Your mailbox
2. Your local post office
3. The road with the postal trucks on it
4. Your recipient’s local post office
5. Your recipient’s mailbox

Similarly, when you send an email in the simplest form, there are five (5) specific locations that will be crucial to the exchange.

1. Your inbox/outbox
2. Your mail server or ISP
3. The Internet
4. Your recipient’s mail server or ISP
5. Your recipient’s inbox/outbox

If we stick with our snail mail analogy, a bounce could easily compared to a letter marked “return to sender.” When you send a letter to an intended recipient at a home or business, but your friendly local postman finds that person is no longer at the requested address, the post office sends the letter back to you explaining that the letter, for one reason or another, is undeliverable. The letter will probably now bear a red stamp on it that describes why they couldn’t deliver it. It usually says something like “Return to Sender – no person at this address.”

Thankfully, when you sent the letter, you also included a return name and address block in the top left hand corner of your letter so that:

1. Your recipient knows who sent the letter before opening it.
2. If something were to go wrong and the postal service couldn’t deliver it, they know how to return it to you.

When you send an email, the same concept is applied.

1. You include a FROM or Return-Path address block so the recipient knows who sent the email.
2. If something goes wrong and the Internet Service Provider (ISP) is not able to deliver the email because the person is no longer on that service, they know how to return and notify you.
3. The “bounce,” or your “return to sender” notification includes a bit of information describing why the email could not be delivered. The most common bounces are 4xx (i.e., 421 Mailbox Full) and 5xx (i.e., 550 Recipient Not Found) errors. These can widely vary depending on both the ISP that is sending the email back and the sender’s systems.

Without getting into all the nuts and bolts of the specs, according to the RFC (Internet Standards) specification, all 4xx class errors are considered to be temporary failures and should be retried later. Again, by RFC specs, all 5xx class errors are permanent failures and should not be retried.

Okay, let's take a look at a couple of bounce messages. Buried in the myriad of letters and numbers, are a few important things:

Let’s say you attempted to send an email to a friend at example.com.  If your MTA (Mail Transfer Agent or your mail server) receives a bounce from this email, it should look something like this.

----- The following addresses had permanent fatal errors -----
<somewhere@example.com>

----- Transcript of session follows -----
... while talking to smtp.example.net.:
>>>> DATA
<<< 550 5.1.1 <somewhere@example.com>... User unknown
<<< 503 RCPT first (#5.5.1)

Here's a bounce from another mail server, which attempts to be friendlier:

Hi. This is the qmail-send program at example.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<somewhere@example.com>:
10.10.10.10. does not like recipient.
Remote host said: 550 MAILBOX NOT FOUND
Giving up on 10.10.10.10.

The part of the messages that read "MAILBOX NOT FOUND" or "User unknown" are key. Depending on the reason for the failure, these might actually be one of several different messages.

Again, just like your local postal office, when the letter is returned to them by the recipient’s post office (because they couldn’t deliver the letter), they:

1. Look at the return name and address block to see who originally sent the letter.
2. Look at the red stamp that was put on the letter by your recipient’s local postal office.

Your local postal office can then make a determination on what to do with your letter. In this case, the protocol is to return the original letter to your postal box at home, so you can take an action on it. Maybe it’s time to update your address book, or double-check your penmanship.  Once you have cleared up the mistake, you can then resend the letter.  (Or you could convince your friend that email would be much better than postal mail anyway.)

In the email world, when the email is returned to your mail server (or ISP) by your intended recipient’s mail server (or ISP), they:

1. Look at the Return-Path or bounce address it was sent from when it bounced to see who to send a notice to.
2. Look at the codes stamped in the bounce by the recipient’s mail server (or ISP) to determine the reason for the bounce or failure to deliver the message.

Your mail server (or ISP) will then send you the original email with a set of stamps (550 User Unknown) as shown above telling you what happened so you can take an action it. Maybe that action is to remove that person from your address book or double check the email address you had typed.  (Thankfully, this time your poor penmanship is not to blame.)

One of the most common solutions for a bounced email, (aside from checking to be sure that you are sending to the right address, of course), is to "wait a while and try again". The email system, while somewhat random, is also somewhat self-healing. If there's an email server with a problem, chances are it will get fixed or eventually bypassed, especially if it belongs to a larger ISP. For temporary problems, email servers will typically keep trying for up to four (4) days before giving up and will let you know if they have indeed given up with a bounce.

Now let’s talk about how this effects you on a day-to-day basis. How does my ESP or in-house solution handle my bounces for my campaigns on such a large level? Most companies today offer a “best in class” bounce handling system that goes beyond simple 3 digit (550 or 421) error processing. They want to ensure the best possible deliverability to each of your recipients. Most should be attempting to read not only the error codes, but also the description of the error, like “User Unknown” or “Mailbox Full.” So, their system should go the extra mile and continue to retry temporary failures automatically for you, or should stop trying to deliver email to bad email accounts. They should also be very THOROUGH in their reporting of email failures to you so you can understand the problems or trends in your email marketing programs (hard, soft, blocks, technical, etc failures). This also means they should retry failures intelligently, making sure they do not overload the receiving system in the process.

So, that’s it for today.  That is how email servers handle bounces in a nutshell. If you have any questions, please do not hesitate to email us to get further clarification on this subject, submit a topic idea, or plain just post a comment to us.  Looking forward to How Email Works, The Final Chapter.  (Coming soon to a blog post near you.)

-Dennis
Eloqua

Don’t Just Send, Deliver!

A big thanks to my wonderful wife for editing this document for me.  She rocks.  and I have the t-shirt to prove it. (she wrote that part, but it’s true)

So one of the documents we received in the email tracks at the Marketing Prof's Digital Mixer last week in AZ was one called "On the Shoulders of Giants: Leaping Pitfalls and Harnessing Best Practices When Managing an Email Program". I thought it was cleanly put together document that I needed to scan and share. I hope no one minds.

MODERATOR:
Karen Talavera, President, Synchronicity Marketing

PANELISTS:
Doug Williams, Director of Marketing, Lane Bryant Catalog
Daryl Nielson, Commercial eMail Marketing Manager, Hewlett-Packard
Lori Keller, VP, Marketing, Pacifica Hotels

Just like every other marketing program, your email campaigns sometimes get driven by the needs of the organization rather than the interests of your customers. What does that do to the chances for an open, click or response? Not much. They talked how both B2B and B2C companies could optimize their email marketing results by creating relevancy, optimizing cadence, reaching the inbox and conducting effective tests and data analysis.

Download pitfalls_and_harnessing_best_practices_when_managing_an_email_program.pdf

-Dennis
Eloqua

Don't Just Send, Deliver!

GREAT piece from our friend J.D. Falk of Return Path. Please take some time out to read this.

http://www.returnpath.net/blog/2008/10/the-root-of-all-email.php

-Dennis
Eloqua

Don't Just Send, Deliver!

So, I know I never did get to the second post of this series as soon as I wanted, but I also hadn't expected so much travel to pop up between the time of the first post and now.

As you hopefully recall from 30 days ago... we wanted to break into sections how email works

• How MTAs (Mail/Message Transfer Agents) Communicate
• What is a “Bounce?”
• How MTAs Handle Bounces
• How Bounces Can Affect a Subscriber’s Status

Today we are taking on the second part of this series What is a "Bounce"

So what is a bounce? One aspect of good Email Marketing practice is being able to interpret and respond to the machine responses (referred to as “bounces”) when email fails to be delivered to its intended recipient. Bounces occur because the recipient's mailbox is full, the mail server is temporarily unavailable, or the recipient no longer has an e-mail account at that address. Bounce usually appears as a new note in your inbox when you send a personal or work related email.
 
Typically, a bounce message will contain several pieces of information to help the original sender in understanding the reason their message was not delivered:

• The date and time the message was bounced
• The identity of the mail server that bounced it
• The reason that it was bounced (e.g. user unknown or mailbox full)
• The headers of the bounced message
• Some or all of the content of the bounced message

AOL has a good example of one here.

For most ESP's and large bulk senders, the bounces that are sent back include a codified message in the form of a  numeric series (550 or 421) and an expanded description sometimes called a DSN (Delivery Status Notification, such as “User Unknown” or “You’re blocked”). In order to comply with the established ISP Acceptable Use Policy (AUP) and to further distinguish your emails from spam, many sending systems like Eloqua and MTA providers like StrongMail have established efficient and updatable capture and reporting mechanisms for reading and accurately interpreting these bounce messages and then report on them in a categorical way that might normalize the data and organize it into logical categories, such as hard (permanent) bounce, soft (transient) bounce, block, and technical failure. As my industry colleague and friend Dave Lewis said in an article, "a good system will then map these delivery failures into subcategories, such as “unknown user” under hard bounce or "URL block" under block". By interpreting or categorizing these bounces, actions can be taken in regard to the bounces and will range from unsubscription of invalid addresses on the first hard bounce to limiting mailing to a domain where a block or some other form of service denial has been detected to removing bad or unknown user addresses.

So what does the number mean? what does the words means?

Well the numbers basically are a way to tell a mail server to re-try or NOT re-try an email if it fails.

Anything that is 4xx like 421 is a temporary failure and can be re-tried immediately. Could be for a quick server outage, greylisting, etc.

Anything that is 5xx like 550 is a permanent failure and SHOULD NOT be re-tried immediately. Usually for a long term block or unknown user or bad email account and should be looked at later for reasoning and whether or not the email should be re-tried again based on the DSN.

The DSN or wording is just a bounce to help humans read the bounce when it comes back to your email client vs. an ESP bounce system. Tells you more as to why it bounced.

So some examples:

• 550 User Unknown = Don't re-try now and don't send again
• 421 Greylisting = Re-try now and send again
• 550 Your blocked = Don't re-try now and send later after addressing why block occurred
• 451 no reverse DNS = Re-try now and send again later after you fix your DNS
• 552 message to big = Don't re-try now, but send again later after reducing size

and the list of examples go on.

One thing to consider here; capture all data streams. Make sure that your system collects all bounce data streams – both synchronous (sync) and asynchronous (async) bounces. Synchronous bounces happen immediately during the email transmission. For example, if your sending system connects to an ISP and tries to send an email to nouser@domain.com and if the ISP's mail server is configured for synchronous bouncing, it will immediately pause the transmission, and tell you that the address is bad and not allow for anymore data to be sent.

Asynchronous bounces work in the opposite way. Using the example above, domain.com would accept your email and try to deliver it to its internal address records. Once it realizes that the email address is bad, the ISP's mail server will then send your mail server an email letting you know. You asking yourself why do it this way?  Spammers often use a form of dictionary attack, sometimes known as a Directory Harvest Attack, for e-mail address harvesting. For example, a spammer may try sending messages to adam@example.com, barbara@example.com, carl@example.com, etc. Any addresses to which messages are delivered, as opposed to being bounced back during the first half of the send, can be added to the spammer's list of known-valid addresses if it doesn't bounce in the sync process. So many ISP's move that bounce processor till later as an async so they can monitor those who have spammer looking activities. Statistically we see more ISP's bouncing email synchronously.

Now another thing that you need to consider here is that when the standards for how bounces should be sent and used was created to ONLY address technical failures such as server outages, full mailbox's, bad email address, etc. It was never intended to handle policy based bounce such as spam or phishing blocking. This wasn't something intentional, we just never though this far ahead nor could we. In MAAWG we are looking at this now to understand how we can build to fix issue like this on the existing infrastructure. Come to San Francisco MAWAG to see!

TIPS:

Make sure when creating or buying into an ESP or in-house solution that the bounce management system can

1. Capture all data streams such as syns and async
2. Correctly interrupt the data that can be confusing in itself in the above bullet examples
3. Organize and normalize the data to handle the upon 1,000's, upon 1,000 of bounces you might get
4. Make the data and reporting actionable to the user. Remove the email address? re-try the email?
5. Be updateable since bounces can change over time and ISP's are always changing.

Again, Dave Lewis said "With a bounce management system that meets these requirements, you’ll be in a position to properly evaluate your performance, manage your list and improve your practices – all of which translate into better bottom-line results. And you’ll be well on your way toward mastering e-mail deliverability"

MORE information can be found here http://en.wikipedia.org/wiki/Bounce_message

-Dennis
Eloqua

Don't Just Send, Deliver!

I recently wrote a whitepaper for the Email Experience Council (EEC) with some GREAT contributions from Michelle Eichner of Pivotal Veracity, Andy Goldman of Ogilvy, John Alessi of SocketLabs, Tim Chase of Goodmail Systems, Chris Harris of Blackbaud, Stephanie Miller of Return Path, and Aaron Smith of Smith-Harmon on How to Revive a Stale Email List And Why You Should Avoid "Soft Touch" List Cleaning Services. I did this based on a question that was raised on a call where a certain college, who is a major sender of email, wanted to use a list that hadn't been touched in OVER two (2) years.

In this paper we discuss:

• Why and when the issue comes up
• The right way to re-active old subscribers
• Deal with subscriptions issues
• How to keep your list clean on-going
• Remove inactive or unemotionally subscribed
• Some warnings/problems about third party list cleaners

Check out the opening blog posting for the paper... http://blog.emailexperience.org/2008/08/how_to_revive_a_stale_email_li.html

Yes, you have to buy it unless you a member of the EEC, but hey...what's $49.00 for a paper compared to 20o miLLion EMaiL ADDRESS oN a Cd for $99?

-Dennis
Eloqua

Don't Just Send, Deliver!

My good friend and colleague Spencer Kollas, Director of Delivery Services for StrongMail Systems, posted an interesting question.

What is really SPAM?

"Getting a consumer's opt-in isn't enough. New research indicates your legitimate email promotions are still being discarded as spam. Here's what you can do about it...."
http://imediaconnection.com/content/20316.asp

-Dennis
Eloqua

Don't Just Send, Deliver!

The Board of the Internet Corporation for Assigned Names and Numbers (ICANN) announced Thursday that they will be expanding the Internet landscape by offering the opportunity for individuals to register new top level domains (TLDs).

Currently, there are 21 TLDs available for users to register and the new proposal will allow for the purchase of new generic TLD's so that companies or organizations could add their desired name to their domain, instead of having to have a TLD like .com, .org, .net, .net.nz, .co.nz etc. ICANN expects at least some of the new domain names to reflect the industry trying to register them. For example, .travel for travel Websites, .food or .restaurant for restaurants. This will allow for companies looking to brand themselves more prominently on the Web to such.

Applicants are not automatically guaranteed a trademark on their newly registered domain name, but we would hope though that  ICANN would give priority to companies and Organisations with Trademarked names. New domain names will not be sold to users, according to a statement from ICANN. Anyone who wants to register a new domain name will submit an application to ICANN which will go through a vetting process and prove that they will be able to operate a TLD before being approved. Experts predict it could be in the region of $50,000 USD to register a new TLD.

Here are some FAQ from ICANN's website

1. Are you selling these new names?

ICANN is not "selling" new top level domain names. There will be a limited application period where any established entity from anywhere in the world can submit an application that will go through an evaluation process. It is anticipated that there will be additional rounds relatively soon after the close of the first application round.

2. What's to stop others registering my brand name?

Trademarks will not be automatically reserved. But there will be an objection-based mechanism for trademark owners where their arguments for protection will be considered.

3. How did this proposal get developed?

ICANN has a multi-stakeholder policy development process that served as the foundation for the process design. It involved consultation with domain name industry, trade mark attorneys, the business sector, users, governments and technicians.

4. How will offensive names be prevented?

Offensive names will be subject to an objection-based process based on public morality and order. This process will be conducted by an international arbitration body utilizing criteria drawing on provisions in a number of international treaties. ICANN will not be the decision maker on these objections.

5. When will all this happen?

ICANN is working towards accepting the first applications in the second quarter of 2009

-Dennis

Eloqua

AOL announced today that they are converting all feedback loops (FBL) to the Abuse Feedback Reporting Format (ARF) on September 2nd 2008.

The Internet draft on ARF "draft-shafranovich-feedback-report-01.txt" has a GREAT introduction to why this was created. "As the volume of unwanted email has grown network operators have begun to exchange feedback among themselves and other parties. This feedback takes the form of complaints about spam, unsubscription requests, reports of email-borne viruses and other feedback. ARF is a machine-readable MIME format for feedback reports intended to allow easy automated handling of reports by recipients, but also includes support for feedback loops, virus reports and other similar activities". For those who are new to this, one use of this mechanism takes the form of the famous "this is spam" button. When someone clicks that button, a report is sent back to the sender of the message basically notifying the sender that someone complained and that you should either remove the person. Other forms will be used to notify ISP's about viruses spewing from customers machines. The extensible format will allow us to create many ways to notify system owners about a multitude of problems they are causing.

You need to make sure that

1. You apply for feedback loops from ISP's like AOL
2. Have an infrastructure that can parse and report on ARF feedback loops.

To understand more about ARF and how it is used at AOL please click here. To learn more about the ARF mechanism itself, join discussions, or find tools to create or parse these reports...please visit the Word to the Wise ARF support site here

-Dennis
Eloqua

With the fundamental shift from content to reputation based filtering, it becomes even MORE important today to make sure that all customers understand their failures or behaviors when it comes to email. Their failures could be classified as things such as unknown users, complaints, blocking, technical failures, and temporary problems. The way we know these things is by bounce processing. When there is a problem delivering your message to its destination you receive an error message included in the mail returned from a receivers system. A bounce message, or Delivery Status Notification (DSN) message, aka Non-Delivery Report/Receipt (NDR), Non-Delivery Notification (NDN), or simply a bounce is an automated electronic mail message from a mail system informing the sender of another message about a delivery problem. The original message is said to have bounced.

Example coursity of Wikipedia, the free encyclopedia

Imagine that Jack (jack@example.com) sends a message to Jill (jill@example.org) at a different site. (Note that these are two different domains: Jack uses a COM domain while Jill is using an ORG one). Once Jack's mail server has accepted the message, it must either pass it along to Jill's mail server, or else deposit a bounce message in Jack's mailbox.

Let us say that Jack's mail server passes it on to Jill's mail server (at example.org), which accepts the message for delivery. However, unfortunately, a moment later the disk on the example.org server fills up, and so the mail daemon cannot deposit the message in Jill's mailbox.

The example.org mail server then must send a bounce message to jack@example.com, informing Jack that his message to Jill's mailbox could not be delivered.

Had the example.org mail server known that the message would be undeliverable (for instance, if Jill had no user account there) then it would not have accepted the message in the first place, and therefore would not have sent the bounce. Instead, it would have rejected the message with an SMTP error code (bounce still). This would leave Jack's mail server (at example.com) the obligation to create and deliver a bounce

There are many reasons why an email may bounce. One reason as stated above is if the recipient address is misspelled, or simply does not exist on the receiving system. This is a user unknown condition. Other reasons include resource exhaustion — such as a full disk — or the rejection of the message due to spam filters.

Typically, a bounce message will contain several pieces of information to help the original sender in understanding the reason his message was not delivered:

• The date and time the message was bounced,
• The identity of the mail server that bounced it,
• The reason that it was bounced (e.g. user unknown or mailbox full),
• The headers of the bounced message, and
• Some or all of the content of the bounced message.

RFC 3463 describes the codes used to indicate the bounce reason. Common codes are 5.1.1 (Unknown user), 5.2.2 (Mailbox full) and 5.7.1 (Rejected by security policy/mail filter).

When a receiver bounces a message, they will always send it to the “Return-Path:” header. This header is hidden behind all that pretty HTML and IMAGES you stuff into your emails these days and normally contains an email address for the author of the message so they are notified of the problem. In the case of BULK sending that email address is usually an email address pointing back to an automated system and not a person due to the amounts of bounces that might occur in such large mailings (let's just hope it's WAY much less than 10% of your entire database).

In cases of bulk sending, ISP’s and other receivers REQUIRE that you

1. Accept ALL bounces sent to you in a timely manner
2. That you take action or adhere to the bounce message request or suggestions.
   • This include removing users when they say they don't exist there.
     • 550 "username" Is Not Accepting Mail From This Sender
     • 550 Mailbox not found
3. They you do not second guess what they are trying to tell you

If you do not, then the IP sending the email that generated the bounces will be blocked. In some cases, the domain being used in the emails or other aspects of the sending system will be blocked.

-Dennis
Eloqua

So this was an article/blog post that I wrote while at StrongMail (best in-house solution out there) that I think has some good points and history in it. I am re-publishing this from their site.

As you may know, email is thirty years old and its underlying infrastructure was never built with security and accountability in mind. No one ever thought that email would become as widely used as it is today, that the Internet itself would be subject to so much abuse.

The original email and Internet systems that we know today weren't invented by Al Gore, but by our own government missile defense system group called the Advanced Research Projects Agency (ARPA), whose primary job was to handle research for all space and strategic missile research. NASA was then formed, and the activities of ARPA moved away from aeronautics and focused mainly on computer science and information processing.

One of ARPA's goals was to connect mainframe computers at different universities around the country so that they would be able to communicate using a common language and a common protocol. Thus the ARPAnet -- the world's first multiple-site computer network -- was created in 1969. In order to have an account on these systems you simply asked for one and they just gave it to you almost without ANY questions, completely overlooking security and accountability.

Well, obviously, as time went by and the systems got larger and more interconnected, some people figured out the vulnerabilities and started to send out the first of many billions of unsolicited messages now known as SPAM. The question now comes down to how we can possibly patch a hole this big. Email authentication technologies like DKIM (DomainKeys Identified Mail) are a start.

DKIM is a signature/cryptography-based sender authentication protocol developed in order to address the problem of forged email messages (missing security and accountability) and to allow an organization or individual to take reasonability for the message it sends, which has given rise to the concept of email reputation. Now, I won't bore you with the details of email reputation and authentication, but I do want to focus on why we got involved in this early on.

Email is now about as mainstream as any technology can be, yet the viability of email is continually being threatened by viruses, spam, spoofing, and phishing. All of these threats are shaking the confidence in email as a viable tool for communications and conducting business, and StrongMail is committed to help protect it. We have been participating in the DKIM standard since day-one, and we are proud to have our own employees acknowledged for their hard work in the standard.

StrongMail was the first technology provider to integrate support for all emerging authentication protocols into its outbound email products to simplify compliance with whatever standards are mandated. DKIM has since gained a lot of traction, and AOL, GMAIL, and Yahoo! now use it successfully in production.

Unless you're a member of the CIA, a Matrix super fan, or a cryptographic expert, signature-based authentication can be difficult to understand. In StrongMail, you don't have to think about any of that stuff, since we make it as easy as 1-2-3 with our step-by-step interface, which will either create, upload, or use the existing keys needed to properly sign and verify any email.

In fact, StrongMail is specifically designed to make it easy to work in the complex and ever-changing world of email standards. You even have the ability to apply authentication to certain email streams or campaigns based on your needs. Our offering is so simple that anybody with a mouse, keyboard, and monitor can institute email authentication.

Overall, DKIM brings accountability to the sender, establishes a reputation and confirms whether they should be sending email from a certain domain. By doing this, receivers can better separate mail streams from those who are good and those who are bad, which enables better anti-spam technologies and reduces false positives.

-Dennis
Eloqua

We need a real way of measuring relevance in email. e-Dialog and Responsys have both come out with their own methodologies, but they seem to be a subjective self-assessment rather than an objective measurement.

In both examples, email marketers fill out a short survey where they rank themselves on various criteria. While I'm sure this is an interesting exercise, I don't think it's going to have a huge impact on the relevance of emails that people send. This is just another way to identify best practices and new ideas, but not a measurable, actionable score. It's an interactive whitepaper.

What we really need is a metric that is objective like deliverability. I'm sure we would find that the two metrics are tightly correlated.

The challenge is that relevance is hard to measure. It would probably be a subset of traditional email reputation - less focused on bounce rate and more focused on open rate and other indicators of user activity.

I don't think this is the answer, but here is a stab at the type of thing I'm thinking of:

Relevance = (Unique Opens / Total Valid Recipients) + (Unique Clicks * 3 / Unique Opens) - (Unsubscribes / Unique Opens) - (Spam Complaints * 10 / Total Valid Recipients)

So if you sent a message to 100,000 recipients with a 5% bounce rate and got a 10% open rate with a 10% clickthrough rate, 1% unsubscribes and 0.1% complaint rate, the Relevance Score would look like:

Relevance = (10,000 / 95,000) + (1,000 * 3 / 10,000) - (950 / 10,000) - (95 * 10 / 95,000) * 100
Relevance = 0.11 + 0.3 - 0.1 - 0.01 = 0.3 * 100 = 30%

A message to 100,000 recipients with a 1% bounce rate and a 30% open rate with a 20% clickthrough rate, 0.5% unsubscribes and 0.05% complaint rate, the Relevance Score would look like:

Relevance = (30,000 / 99,000) + (6,000 * 3 / 30,000) - (975 / 10,000) - (49 * 10 / 99,000) * 100
Relevance = 0.3 + 0.6 - 0.1 - 0 = 0.8 * 100 = 80%

It's possible to get over 100%, but it would be unusual. A message to 100,000 recipients with a 1% bounce rate and a 50% open rate with a 30% clickthrough rate and no unsubscribes or complaints would have a Relevance Score of 140%.

A message with a 100% open rate and 100% clickthrough rate would have a Relevance Score of 400%. You could normalize this further by putting a max value of 1.00 for each of the 4 contributing calculations (opens, clicks, unsubs and complaints).

I don't think this is the perfect equation (yet). But I think this is the kind of thing we need to be looking at when we talk about Relevance. What other factors should we be considering besides opens, clicks, unsubs and complaints? How would you weight each item?