Based on our experience here are 5 key components that are critical in providing good deliverability for bulk email and consistently getting into the Inbox:

1. Sending Rules – most if not all of the large ISPs have specific limits as to how many connections and number of messages per connection they will accept from a single IP address.  By not obeying these limits you can get into trouble quickly. These limits change periodically as well so you need to keep on top of the changes.
2. Email Authentication – having properly formatted SPF DNS records, SenderID, DomainKeys and DKIM in place so an ISP can validate your identity as a sender helps build trust with the ISP.
3. Accredited IP Addresses –  having your IP address(es) on an accredited list that is leveraged by the ISPs helps build additional trust with the ISP.  SuretyMail and ReturnPath are 2 good ones.
4. Remove Bad Email Addresses and Complainers – two things that can really hurt deliverability is passing too many bad email addresses or having too many people complain about your email and categorize it as spam.  Immediately removing these addresses from your email lists will help ensure good deliverability.
5. Only Send Email to People Who Have Opted-In to Receive Your Specific Email – sending to purchased or rented lists, old lists, borrowed lists, collected feed lists, etc… WILL harm your reputation and adversely effect your deliverability GUARANTEED!

We’ve found at SocketLabs that we can manage and control 1 thru 4 but, we need the cooperation of our customers to manage and control #5.  There are no shortcuts to good deliverability!

Here are the top 10 indications that someone might be a spammer:

10. They refer to SpamCop (or even ReturnPath) as the Internet mafia – and are pretty emotional about it.

9. They refer to sending email as “blasting”.

8. They use profanity. i.e. F&*#ing yahoo is blocking my email.

7. They refuse to openly give out information about themselves or their business and use a freemail address.

6. When you ask for their web site address, they have a big explanation.

5. Any email they send you goes into YOUR spam folder.

4. They use the word “leads” or “acquisition”.

3. They are not afraid to throw wads of cash your way. (lots of money and no place to spend it)

2. They are eating (and chewing sloppily) while on the phone with you.

and finally…

1. They lead the conversation with: “I’m fixin’ to send me some email.”

This is funny and sad, but absolutely true as well. A good portion of our time is used to vet out the numerous new customers that come our way and determine who is acceptable and who is not.

By keeping only the cleanest of senders we are able to provide spectacular deliverability rates for our customers.

Gotta go, someone is on the phone who needs to send 5 million messages today. : )

Follow me on Twitter: @johnalessi

Now there is a great resource for most of the known bounce codes to help simplify your tracking and processing. The eec’s Deliverability Roundtable has put together a repository of common and available bounce strings senders might see from current ISPs (email receivers).

The forum is setup on Get Satisfaction as a dynamic and interactive site that allows users to request information and update bounce strings as they change. The ISP serving the bounce, the bounce string text and next steps for a sender are written out by bounce code here.

http://www.getsatisfaction.com/deliverability/tags/bounce_codes

Return Path did not state where they believe the email to be, but we suspect that it is floating in deep space, possibly captured in the crystal prison of the three Krypton prisoners from Superman.

Some other notable points from the study:

• It is easier to deliver to US ISPs than Canadian ISPs. Inbox placements of mail sent to US ISPs was 82% in contrast to 75% sent to Canadian ISPs.
• B2B delivery rates are less than that of B2C email 72% vs 79%. This is in strong opposition to what has normally believed to be the case. Accounting for this is the fact that businesses are being protected by ever advancing systems like Postini, Synamtec and MessageLabs.
• In the US, Gmail is the hardest ISP to penetrate and Cox is the easiest.
• In Canada, Primus.ca was the hardest ISP to penetrate and Telus was the easiest.

I encourage you to download the full study, which is brief but very informative, and includes colorful charts and graphs:

Return Path Deliverability Benchmark Report

fbl-test@service.socketlabs.com
Auto responds to From address with a feedback loop report in ARF format.

bounce-test@service.socketlabs.com
Auto responds to the Return-Path with a bounce message.

As a side note, the autoresponder was built using the .Net API in Hurricane MTA Server.

First, now our new Dynamic Block Rules are a part of the Smart Delivery Rules. Now, protecting your reputation is automatic. You can read more about Dynamic Block Rules here.

Second, Smart Delivery Rules can now be updated easily from within the Hurricane MTA Server interface without having to update the entire application.

The Administrative configuration page has a new option to download and apply the latest set of Smart Delivery Rules directly from our database.

With these two enhancements it is now easier than ever to leave things up to us and still be assured of the highest deliverability possible. Enjoy!

Dynamic Block Rules are a new part of Hurricane MTA Server’s Delivery Rule system. Hurricane MTA Server’s Delivery Rules enable traffic shaping to specific ISPs. The new Dynamic Block Rules are a subset of a Delivery Rule. The Dynamic Block Rule system scans ISP responses for known codes and text which indicate that the ISP wants you to pause sending them email. The Dynamic Block System then automatically pauses delivery to that ISP for the time period setup in the block rule.

Multiple Dynamic Block Rules may be specified for each Delivery Rule and they are evaluated in the order of their priority, top-down, until a match is made, in which event that rule is activated. Only one rule can ever be active at one time. Each time a Dynamic Block Rule is activated, a Delivery Alert will be posted to the Hurricane MTA Server alert system. There is also a Dynamic Block Rule option to “Only Alert” without pausing delivery.
Each rule consists of the following pieces of information:

So what are some of the reasons why an ISP would want you to stop delivering mail? This could be the result of sending too much mail per hour, receiving too many complaints about your email, trying to deliver to bad email addresses or various other reasons. The important thing is that the ISP wants you to pause sending and failure to do so can damage your reputation.

The Dynamic Block Rule system is a part of the latest release of Hurricane MTA Server. There is also a new Dynamic Block Rule log file that can be enabled via the log settings for each account. A future post will outline that log file and show you how it can be used to analyze the effectiveness of your Dynamic Block Rules and and fine tune them to obtain the highest deliverability possible.

Within the next month we will incorporate block rules into Hurricane MTA Server’s Smart Delivery Rule list. Smart Delivery Rules are a set of Delivery Rules defined and periodically updated by SocketLabs to properly shape traffic to the large ISPs.

Until then, you can try your hand at creating your own Dynamic Block Rules to get a feel for how the system works.

This has not been an easy task in the past, but with the new features in Hurricane MTA Server it just became a whole lot easier. Hurricane MTA Server is now capable of intercepting feedback loop report messages from ISPs, which it will automatically analyze and process. The results of the analysis of each feedback loop report received are logged, passed to a new plugin API event and also included on the brand new built-in feedback loop report.

Feedback Loop Report

A new plugin API event (courtesy of the new IDynamic plugin interface) can also be handled to push the results right out to your own databases in real-time.

Hurricane MTA Server has the ability to process feedback loop reports that are in the Abuse Feedback Reporting Format (ARF) such as Aol, Yahoo, Comcast and others as well as non ARF feedback loop reports from Hotmail and MSN.

Feedback loop reports are specific to each ISP so you must sign up with each ISP separately. Normally you are required to fill out a form on each ISP’s web site proving that you are the owner of the IP addresses you wish to monitor and providing an email address to send the reports to. Once your feedback loop is setup with the ISP, you must configure Hurricane MTA Server to accept and process the messages.

The email address you choose must have its mail exchange set to the IP of your Hurricane MTA Server and Hurricane MTA Server must be configured with the same address so that it knows to accept the messages. Feedback loops are configured in Hurricane MTA Server in the new FBL tab of the account settings. Once setup correctly Hurricane MTA Server will start accepting the reports and parsing them.

Feedback loop configuration is per account.

When feedback loops are processed the results can also be put into a feedback loop log file (enabled in account log file settings) or processed by your code in real time with the new feedback loop plugin API event

See our list of feedback loop signup links.

Good luck!

The following code illustrates how the event can be handled by your code. If you have not read about the new IDynamic plugin API interface yet I would suggest that you do because it contains the basic information on the OnDynamicEvent() method which is used to fire the feedback loop events.

public class Feedbackloop : PluginBase, IDynamic
{

     public object OnDynamicEvent(DynamicEventId eventId, ref Dictionary eventParams)
     {
         //Tell the system we only want to get feedback loop events
         if (eventId == DynamicEventId.Init)
         {
             eventParams[DynamicEventId.OnFeedbackLoopParsed.ToString()] = 1;
         }
         //Handle feedback loop event
         if (eventId == DynamicEventId.OnFeedbackLoopParsed)
         {
             string OrignalRecipient = eventParams["OriginalRecipient"].ToString();
             string OrignalMessageId = eventParams["SystemMessageID"].ToString();
             string CustomMailingID = eventParams["CustomMailingID"].ToString();
             string CustomMessageID = eventParams["CustomMessageID"].ToString();
             string UserAgent = eventParams["User-Agent"].ToString();
             string Type = eventParams["Type"].ToString();

             /// To-do: Do database work to unsubscribe user.

         }
         return null;
     }

}

Also, in cash you missed it, find out all the info on the new feedback loop processing and reporting in Hurricane MTA Server.

AOL FBL
http://postmaster.aol.com/fbl/

Hotmail / Windows Live JMRP
http://postmaster.live.com/Services.aspx#JMRPP

Road Runner FBL
http://feedback.postmaster.rr.com/

Yahoo!
http://feedbackloop.yahoo.net/index.php

USA.net
http://fbl.usa.net/

Cox
http://fbl.cox.net/index.php

Comcast
http://feedback.comcast.net/