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?

"Permission is not enough; list engagement list is the key to deliverability. ISPs have stated they’re measuring such things as viewing time."

"Over-mailing = complaints = negative reputation at ISPs. Diversify less critical messages using Social Media. Save the good stuff for email."

"Drop the noreply@. Gmail’s begun testing turning on images for senders who have received two replies from a user; other ISPs should follow."

"Let the customer drive. From the onset and through Preference Centers let them dictate how much and what sort of email they want to receive."

"Stop marketing, at least occasionally. Actual content is likely to score better as ISPs look at engagement and complaints when filtering."

"Test, test, test. Day of the week, time of day, and level of personalization and segmentation will all improve engagement and pay dividends."

"Authentication will continue to be a major factor. Senders who have not adopted DKIM as their auth method of choice should do so this year."

"Just like DKIM, domain-level reputation is on the rise. For portability’s sake, make the From: and Friendly From as consistent as possible."

"Even though engagement, DKIM, and domain-rep may be on the rise they’re not the only factors. IP-based reputation still matters -- a lot."

"ESPs can do many things but your content and frequency aren’t among them. What/when/how you mail is largely dependent on your deliverability."
 

- Scott Hardigree | Indiemark | @indiescott

The email industry's latest buyout happened a few days ago and we witnessed a highly reputable email monitoring and deliverability reputation company Pivotal Veracity agree to buyout terms from Unica, an Email Service Provider with  gunpowder. Unica is attempting to be a "one-stop shop" for marketers that utilize their suite of services and with the acquisition of Pivotal Veracity, Unica may have completed it’s mission of also providing email reputation and deliverability services to its core clients.

What amazes me about this transaction is that Pivotal Veracity was really making strides in becoming a thought-leader in this small field,  and was competing closely with archrival ReturnPath.  I believe the buyout could potentially alienate a number ESP's from eventually partnering with Pivotal Veracity.  As a result of the buyout, ESPs will be very cautious in their approach to working with Pivotal Veracity. However, this by no means diminishes Pivotal Veracity's tremendous accomplishment and a huge congratulations is in order to everyone associated with Pivotal Veracity including but not limited to Deirdre Baird, Michelle Eichner, Jordan Cohen and Len Schnyder.  It certainly looks like Pivotal Veracity accomplished their goal and executed on their exit strategy perfectly.  For many successful companies, "stage five" constitutes an exit strategy of some kind. This process usually happens after key executives and members of the board vote on such an initiative.  I just think that stage five might have come a bit early for Pivotal Veracity.

All evidence seems to show that the real winner in this transaction is ReturnPath.  ReturnPath no doubt also has an exit strategy, but they appear unwilling to divulge a strategy or partner with an ESP at this point, given their unique leadership position and respected voice in the industry.  Although Pivotal Veracity has many well spoken and thought provoking leaders on their staff, I think ReturnPath and their consummate staff are the real superheroes here.  From  Stephanie Miller, the passionate and relentless email advocate to the outspoken J.D. Falk, whose innate knowledge of email technology and deliverability illuminates us all.  Then, of course, there is the self-proclaimed spamfighter himself, Neil Schwartzman. Without a doubt, ReturnPath’s luminaries saturate the industry with reliable and balanced messaging every time.

Furthermore, with leading services in place that are more robust than ever (such as the latest from Sender Score outlined here by Spencer Kollas), and definitive plans in place for maximizing and monitoring domain reputation for senders, the future looks promising.  When you take emails bright future into account, it appears that  ReturnPath is poised for many quarters of strong growth.  I don’t want to sound like an analyst here, but I really think ReturnPath has what it takes to raise the bar for the entire email community and further develop its existing reputation services.

With these developments, ESPs will now will look to ReturnPath as the consummate leader in the email reputation monitoring space and see one fewer rival, one fewer choice to make.  Senders and ESPs will find that ReturnPath is the only high level and sovereign conduit for stellar email deliverability monitoring and reputation.  The allure of ReturnPath is its stout independent position in our space (a positon that only those in our space truly appreciate.) Certainly Matt Blumberg, George Bilbrey and their hardworking crew can now navigate the email reputation landscape exclusively.

At some point in the future, I’m sure ReturnPath also has an exit strategy in mind and that strategy is not for us to surmise. I would venture to guess that as the industry continues to mature and consolidate, ReturnPath may consider filing for an IPO, especially as we see continued consolidation in this space.   I think what matters most is to enjoy the exciting journey that ReturnPath is paving for our industry.  We now have two choices: we can either watch or we can help them build a company of which we can all be proud of. 

Fred Tabsharani

Port25 Solutions, Inc.

@tabsharani

(The Deliverability Forum is a series of interviews I hosted with industry leaders and luminaries over the past few months.  It came to closure last week and I have shared the final post with takeaways and highlights from the Bronto blog.)

It is with a bit of ennui that I must close this series.  Many thanks to everyone who contributed to the blog posts over the last few months and gave their uncensored opinions around what they find valuable, in need of change or what interesting developments are in the pipeline.  As we began, so we will end - you may not have direct access to these industry leaders but I hope the conversations I've shared have given you insight into the minds of those who have direct influence over the email industry from a sender's and receiver's perspective.  And thank you for the comments and readership thus far.

If you missed any of the blog posts, they are laid out below in chronological order with a high level summary of the post and my takeaways for you as a reader to glean from the interview.  Also, I've included a "definition" section at the bottom of this post if there are any acronyms that you might be uncertain about.  Please scroll down to access it.

The Players:

The FTC (post) describes in the US government's own voice how spam is regulated and counteracted.  Ethan Arenson, the FTC Spam Coordinator, spells out the very serious consequences of not being CAN-SPAM compliant and where to go for their exacting interpretation of what exactly is required of all commercial mailers.  It also shows the government's willingness to help curb the problem of unwanted email by enforcing industry standards such as authentication in a non-legal but best standard way.

My take: While most commercial emailers are compliant with the law (especially if using an ESP such as Bronto), it remains in your best interest to stay cognizant of the law and have someone you trust and can defer to when you're not sure if what you're doing is legal.  Also, the FTC regularly updates the Act's provisions so make sure to stay abreast of the latest rules that are voted in by the FTC commissioners.  We are talking about law here with real civil and criminal consequences if broken.  You don't want to find yourself being accused of a federal crime wherein ignorance of the law won't hold much water!

Pivotal Veracity's (post) President and CEO, Deidre Baird, explains the importance of both authentication and user engagement.  Pivotal Veracity is neither an ISP nor an ESP, but rather a deliverability intermediary services company with deep expertise around content and email disposition.  Also, Pivotal Veracity is a partner of Bronto.  As the interview mentions, without a conscious eye towards the emerging shift in ISP deliverability patterns, specifically around user engagement and authentication, you'll find your program in trouble.

My take: As AOL puts it, "send relevant email to people that want to receive it!"  Are you doing everything you can from an infrastructure standpoint to ensure your email doesn't attract negative hits when being scanned and determined for acceptance by the ISPs?  And, once delivered, is the email being received well by your recipients?  If you can't categorically answer in the affirmative to both of those questions, you have some major homework to do or else risk your mail being deemed irrelevant and sent off to the bulk folder or bounced back.  Both cost money.

Razorfish (post) chimed in from a email content and strategy perspective.  Whitney Hutchinson, Group Director, Strategy and Account Services, sums it up nicely by hitting on these key points: engage your recipients with appropriate creatives, have a holistic marketing approach for the relationship management and take into account the "stacking effect" which is a result of the newly emergent communication technologies available to market to recipients through.  Email is now one of many.

My take: While email is now just one piece in a wide breadth of technologies (i.e., Twitter, Facebook, LinkedIn, Google Wave, SMS, etc.), it is still the most important and most trusted conduit of content that recipients most engage with consistently over time.  It has proven itself as a reliable protocol, even older than the internet itself (history)!  But, recipients have become increasingly savvy with its adoption so making your content stand out amongst the sea of email users get is at the vanguard of a successful marketing program.

ReturnPath's (post) President, George Bilbrey, still believes email is the "killer" app.  ReturnPath, while not an email sender or receiver, hosts a suite of services ranging from ESP to ISP products and plays a significant role with its liaison relationship between both senders and receivers.  He poignantly breaks down the exacting metrics ISPs use to measure user engagement (i.e., open rates, click rates, spam complaints, panel votes, etc.) along with the idea of domain reputation.  ReturnPath is a partner of Bronto.

My take: Authenticate, watch your complaints and make sure your domain reputation is healthy.  Yahoo! and AOL have already moved over to using domain reputation as a determining factor for deliverability - so to even ignore those two at this point with their combined estimated 142.4 million unique inboxes is perilous.  ISPs are fighting off spam and user interpreted unwanted email; don't let your mail take on these smarmy characteristics.

Cloudmark (post) occupies a very distinct space in the email industry as being a provider of anti-phishing, spamming, virus and other threat vector services to ISPs only.  Jamie Tomasello, Abuse Operations Manager, posits that authentication doesn't actually imply good mail but rather mail that is verified as coming from the declared source.  Interestingly, she adds that user engagement is not a net positive measurement - you can have negative user engagement as well depending on what the user does with your mail that is perceived by the ISPs and companies such as hers when it's not wanted.  Permission is tantamount.

My take: Bronto and many other responsible ESPs require permission based marketing as the only source of email addresses senders can email to.  Why?  Because it shows the true intent of the recipient to actually want your email; they've taken an action that is clear and deliberate to let the sender know they want the email.  By assuming recipient desire and emailing recipients who haven't given permission is casting a large net that will cause deliverability issues.  Think about it.  When was the last time you marked an email as spam or deleted it when you didn't knowingly sign up for it?  That's what I thought.

LashBack (post) rounded up the series as the final contributor with James O’Brien, Director of Marketing.  LashBack is dedicated to monitoring unsubscribe requests, suppression list abuse and whether an unsubscribe mechanism exists.  This directly ties into CAN-SPAM compliancy as well as being inline with email marketing best practices - when a recipient communicates to you they don't want your email anymore, you should honor this request without question or judgment.  Also, LashBack is putting together the first Email Compliance Summit which should be highly anticipated by senders and ESPs who want to stay on the cutting edge of unsubscribe policy.

My take: With the unsubscribe mechanism being one of several ways a recipient can directly and easily communicate intent with the email sender (others being complaints lodged with the respective ISP or direct email to the sender's role accounts), it is a very useful metric to measure the impact your mail is having on recipients.  Are you sending too much?  Too frequently?  Not targeted enough?  It's the job of the marketer to find that sweet spot where relevancy, recency and frequency are met with the recipients to not drive them to unsubscribe from your mail.

Definitions:

• CAN-SPAM: Controlling the Assault of Non-Solicited Pornography And Marketing Act of 2003 is the law the federal US government enacted to combat spam and other unwanted and malicious email.

• FTC: Federal Trade Commission is the arm of the federal government in charge of enforcing and maintaining the CAN-SPAM Act.

• ISP: Internet Service Provider of which the largest B2C ISPs are Yahoo!, Hotmail/Live, Gmail and AOL.  Email provider or receiver.

• ESP:  Email Service Provider such as Bronto.  Email senders.

• SPF: Sender Policy Framework is a type of email authentication that is path based and validates the sending entity.

• DKIM: DomainKeys Identified Mail is a type of email authentication that is encryption based, validates the content of a message hasn't been tampered with while in transit and can be tied back to a sending domain.

I hope that the Deliverability Forum and this wrap up have helped you with your deliverability programs.  Still have questions?  Comment below and let's keep the conversation going.

Chris Wheeler
Director of Deliverability at Bronto
@ChrisAWheeler

The Final Word on DKIM and Deliverability

By: J.D. Falk of Return Path

Seems like every week, I see another industry colleague asking for a detailed list of how each DKIM option affects deliverability. Everyone who's asked for this is a smart person, generally clueful, but this question stumps me. Perhaps it's that while I learned about email technology as a way to get a message from one autonomous system to another, he learned about it in the frustrating context of trying to figure out why his mail was being blocked -- so it has never before crossed his mind that new email technology might be invented that won't make delivery of his marketing messages more difficult.

See, DKIM isn't some wacky new anti-spam method intended to reduce your ability to get mail delivered (that's what that made-up word "deliverability" means, after all.) It's authentication, designed to make it easier to identify the good senders.

DKIM only answers two questions:

1. Does the message have a valid signature?
2. If it does, what domain signed it?

The signing domain, identified by the d= tag in the DKIM signature header, is the only part of the DKIM signature where the choices you make now will directly affect the continued deliverability of your messages. This is because d= is how you tell the receiving system who you are.

With a valid signature on the message, if the receiving system has a domain-based whitelist, and your d= is on it, the message gets in. If they have a domain-based blacklist, and your d= is on it, the message will be rejected. Few mailbox providers have either of those today -- but if they have a domain-based reputation system, which we know the big mailbox providers are working on, then delivery depends on reputation. It's exactly the same as with IP addresses today.

And just as with IP addresses, consistency is critical. If you want to separate different mailstreams, then instead of sending from different IPs like you were before, you can now sign with different domains: shipping.example.com, marketing.example.com, corporate.example.com. Within the context of authentication, each of those is an entirely separate entity. Reputation assessment systems will quickly figure out that there's a relationship between everything that's part of example.com, though, so you can't use this to escape the much-deserved bad reputation of a bad mail stream.

If you send through an ESP today, chances are they sign with their own domain. This means that if you switch to another ESP, you can't take your reputation with you. However, it also means you can borrow the ESP's reputation as long as you're their customer. Work with your ESP to choose the configuration most appropriate for your situation.

So you can stop worrying, sign your mail, and get back to the important work of making sure your recipients are happy to receive the messages you send.

If you're interested, here's a rundown of all the other options in the base spec -- RFC 4871 -- and what effect they're likely to have on delivery of signed messages. If you haven't read the introduction and the terminology and definitions section yet, please do so now.

There's currently only one acceptable value for the version (v=) tag. If yours isn't 1, then the DKIM signature isn't valid. Effect on deliverability: none if it's 1, otherwise the message will be treated as if it wasn't signed.

The algorithm (a=) is very important to cryptography geeks, but we're not talking about ICBM launch codes here. Unless you remember why DLG2209TVX was replaced with CPE1704TKS, accept whichever algorithm and key size your mail software vendor or ESP recommends and be done with it. (Just watch, someone will comment that rsa-sha1 is insecure because someone could decrypt it in a matter of months -- per message.) Effect on deliverability: none.

Canonicalization (c=) is a sneaky way to get around the fact that sometimes an intermediary mail server will make minor changes to a message, like capitalizing header field names or snipping empty lines at the end of a message. With the default "simple" algorithm, those changes would cause the signature verification to fail. With the "relaxed" algorithm, those changes may pass. Effect on deliverability: none unless the message fails.

You can choose to specify, in the h= tag, which header fields you're signing. There's a good description in the base spec of why you might or might not choose particular fields. If you use this, I'd go with the headers that users are likely to see in their mail client, plus anything you use for tracking. Effect on deliverability: none.

Similarly, you can copy all of the signed header fields into the signature with the z= tag. I'm not sure why you would, except for debugging. Effect on deliverability: none.

The selector (s=) is just a way to look up which key you're using, allowing you to use multiple keys with the same domain. You might have different keys for different offices, or systems, or create a key that you can give to your ESP to sign on your behalf. The selector is also useful for changing keys periodically, in case the private key is no longer private -- for example, you could change selectors every other month, removing old ones a few months after you've stopped using 'em. Effect on deliverability: none.

A somewhat controversial option is the body length limit, designated by the l= tag. This allows the signer to say "I signed this much of the message, but there might be more content after that -- and if so I'm not responsible for it." It's a reaction to discussion list software which may automatically add an informational footer to the end of a message. Thing is, these lists invariably make other changes also -- new headers, et cetera -- so the signature would be broken anyway. And, if your focus is on keeping the recipient safe (as it is for all mailbox providers), why would you deliver a message where the top part is from a trusted sender and the bottom part could be malware? Effect on deliverability: could be bad. Don't use this.

The q= value is easy: it can only be "dns/txt". Anything else is invalid. Effect on deliverability: none if it's dns/txt, otherwise the message will be treated as if it wasn't signed.

There are two optional tags referring to time: t= is the time the signature was created, while x= is when it expires. Both of these are designed to catch stupid criminals. If the signature was (allegedly) created after the message was received, it's not valid. Or if the message is received after the signature expires, it's not valid. While it's not entirely clear what will happen in the wild, I'd recommend skipping both of these. Effect on deliverability: none if the times match up or the tags aren't used; otherwise, the message will appear suspicious.

A formerly controversial feature is the i= tag, which looks like an email address -- but probably isn't. As I explained back in March, Cisco uses this to identify individual users: i=santaclaus@cisco.com, if Santa Claus worked for Cisco. And you know, he might. More common, I'd expect, senders will use i= to denote distinct mailstreams or internal divisions for their own tracking purposes: i=transactional@example.com, i=marketing@example.com, i=nyc-office@example.com. Thing is, there's simply no way for anyone on the receiving side to know whether marketing@example.com is a mailstream, a department, a individual email address, or simply a string of randomly generated characters. As such, reputation is more likely to accrue to the d= value. Effect on deliverability: probably none.

So unless you use l= or have unrealistic expectations about i= or s=, as we discussed above, d= is the only thing that matters. See? Nothing to worry about.

------------

-Dennis
Eloqua

Don't Just Send, Deliver!

So, what are the benefits to a solid domain-based reputation?  What are the ramifications of a suspect domain? Will an ESP still send for me if my domain reputation is less than stellar? How will the actions of my subscribers influence my deliverability?  Is my domain portable? 

The dawn of domain-based reputation is upon us and legitimate senders everywhere are celebrating, albeit soberly.   In a recent Pivotal Veracity report, many leading ISPs have begun to employ domain-based reputation as an effective technique of measuring a sender’s reputation by computing assorted spam-related variables and, perhaps more importantly, subscriber engagement actions.

As Chris Wheeler eloquently breaks it down for us here, ISPs currently base a user’s reputation at the IP level and have only recently begun to show that email authentication as an enabler for domain reputation, along with positive subscriber actions, will increase deliverability to the inbox.  Domain based reputation is a boon for the deliverability landscape and is rife with opportunity for ISPs, ESPs, reputation services, and marketers alike.

If and when ISPs choose to compute your sending reputation, this computation will become your domain score.  For now, let’s call it The Domain Reputation Index (DRI).   This index will essentially be a quick reference to show how ESPs and reputation organizations will track your deliverability and subscriber engagement. Simply put, the DRI will become part of your domain DNA.

Domain Portability: A Boon for Marketers and ESPs  

For example, marketers who have a high DRI index (relative to industry benchmarks) will be able to leverage this score, and (assuming their domain name is portable) essentially have ESPs clamoring for their business. When a switch by a marketer occurs, ESPs will naturally gravitate toward DRI, much like a client with a good credit score who intends to find the best interest rate possible on a mortgage.  

In a recent comment on a Clickz article, Jim Fenton comments that  “Portability is but one of the advantages of domain-based reputation, but the extent to which reputation is portable between ESPs depends on how the respective ESPs work.  Some ESPs send as, for example, newsletter.brandname.com, which would be portable if brandname decided to switch. But others send as brandname.espname.com, which would not be portable. The extent to which the brand wants to be portable needs to be considered when choosing ESPs.” 

ESPs, on the other hand, have much to gain from the DRI windfall.  Properly managed, ESPs can manage preconditions to their clients that meet or exceed better than average DRI scores.  ESPs also have the ability to dictate the level of portability for domains.  This decision is ultimately that of the domain owner, but ESPs may help influence new customer adoption of the portable domains by offering “portability” as a standard or premium service.  The rising popularity of domain portability raises an important question: Should all domains be portable?

Furthermore, ESPs that have large domain sets (many clients) will have a “front row seat” to look into their senders’ DRI, and will  prescribe methods for developing a higher reputation score.  Clients of ESPs will adhere to stricter policy controls dictated by ISPs, knowing that their DRI is at risk if they continue to send suspect mail. DRI is also in danger when recipient engagement metrics fall below industry benchmarks.   When suspect senders realize that their DRI is below average and ISPs have shown them little mercy on delivering to the inbox, suspect senders will have no choice but to proactively engage or seize operations with ESPs.  The dilemma for ESPs is whether or not to maintain a relationship with marginal senders who are well paying, conscientious clients. Each ESP will have to decide where to draw the line on this type of client..   ESPs who stay vigilant will have the most to gain.

 It’s 1849 for Reputation Services

The Domain-Reputation Index (DRI) may be governed by independent 3^rd party entities who will aggregate data of millions of domains.  Companies that could represent such an index may include, but are not limited to, Pivotal Veracity, ReturnPath, GoodMail,  Email Data Source, ESPC, and others.  I did not mention DNS because that system is taxed already.  All of these companies may consider entering into the attractive DRI market, and establishing benchmark DRI thresholds that define, good, bad, and marginal sending behavior.  Among the various other reputation tools in their arsenal would be the ability to certify and publish millions of DRI domain records for the email industry.  Such a collection of records would cause these companies to become the most trusted throughout the industry.  

Think of the big three credit reporting agencies, and then compare them to these email reputation-based organizations.  These entities will have rich warehouses of deliverability and engagement data that will span many verticals and benchmarks.  We’re already seeing traces of this with the latest Pivotal Veracity report on your email engagement index, which is based on multiple sources that are aggregated monthly across authenticated domains.  These reputation agencies will develop a hierarchy of domain reputation building blocks and become a trusted resource as leading advocates for legitimate senders.   

As the email technology and deliverability landscape evolves in a direction that prioritizes individual consumer engagement, marketers must create more relevant communications than ever before to ensure they get into the inbox, creating better ROI.  Certainly, a deliverability index is imminent, whether we call it a DRI, or another name.  Organizations such as Pivotal Veracity, ReturnPath, EEC, MAAWG, CAUCE, or ESPC should begin to consider forming governing bodies focused on Domain Reputation.  The development of the domain reputation index is beneficial to the continued development of  legitimate senders. 

It’s truly going to be interesting to see how the ISPs choose to develop a moniker for the concept of Domain Reputation.  Hopefully, this blog has answered some questions about the need for the domain reputation index in the email industry.  In theory, there are lots of advantages; however, the advent of DRI also gives rise to many more challenging questions.  How will domain-squatting or “domain look-alike” have an effect on DRI?  Do you limit the number of domains a corporate entity would require?  One would think that an effective DRI would exist by rolling up these “sets of domains” for larger corporate entities and developing “one” corporate DRI.  What would that entail? What about domain limits or regulation?  

Also, there is disagreement about whether or not we need further regulation by limiting how many domains a corporate entity would have, given the versatility and the importance on branding.  Since a registry (which currently assigns and maintains domains) does not have the necessary systems in place to measure the use of a domain, what body, (government, or non-government) would be the likely prevailing body? 

 

All of these questions will need to be pondered as the use of domain reputation in the email industry continues to unfold.  Undoubtedly, there will be bumps in the road along the way that need to be worked out.  Nevertheless, it is important to support the continuing development of the domain reputation index because, in the end, your reputation is all that you really have.

Fred Tabsharani

Port25 Solutions, Inc.

@tabsharani

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

So a few weeks ago, GMAIL launched a beta test called "Sponsored mail with enhanced content" which in basic terms means that if your an approved vendor by GMAIL that your marketing or transactional emails will also have a little icon to the side of the email showing off your recognized branding.

Also, supposedly if the sender authenticates their email (SPF/DKIM), the branded content will help identify emails as being legitimate and not spoofed (GMAIL will only show branded content when the sender authenticates their mail).

Do I think it's worth wild option? perhaps, but only time will tell. If I knew more about how GMAIL is preparing to "approve" vendors so they may have their icon showing that might make it easier to understand or know whether or not this will help them address some of the phishing emails or mistaken marking of email as spam. What I can say about this is it might be a cheaper option to having some of your email arriving in the inbox and recognized. Could this be a pay for enhanced whitelist?

I also hope it doesn't complicate the email anymore in terms of how it loads or what browser support you might need.

I for one might take more time to read an email that had a branded icon to the side of it vs. a overused blue ribbon (not attacking GoodMail Systems). I'm overloaded on email (1,000 per day). Lists, corporate, personal, etc.

• What happens if your using IMAP or POP to see your GMAIL email in a thick client like Thunderbird, Outlook, or Apple Mail? Do you see the icons there? Probably not. I use IMAP with Apple Mail so I can see all my email accounts while I travel.
• What happens if you forward this trusted email within GMAIL to another GMAIL user? to an outside user? Does the icon or trust survive? probably not since the author has changed.
• What happens if now senders have to buy into all these enhanced programs like Sender Score Certified, GoodMail Systems, GMAIL's icon whitelist? Who's next in this AOL? HotMail?

thoughts anyone?

-Dennis
Eloqua

Don't Just Send, Deliver!

UPDATE
Gmail adds in sole unsubscribe feature in message details. So, there are two ways to have Gmail notify a sender about a recipient's request - one via the message details (pic below) and the other via marking it as spam and getting the unsubscribe option.
It's been spreading around the net like wildfire, but the rumors were finally put to rest this afternoon when Gmail itself officially announced it's usage of the unsubscribe feature within their web client. For senders, this requires DKIM and/or SPF authentication, a good reputation (as decided by Gmail) and a List-Unsubscribe: header in the form of an email address.

What I'm dying to see is this in action.

I haven't been able to reproduce this myself (after trying with a bunch of senders in my Gmail account) and would love to hear back from anyone who has.

Full post from the horse's mouth here.

Chris Wheeler
Director of Deliverability, Bronto Software

So my new friend Fred Tabsharani of Port25 Solutions wrote a paper that should help give readers a clearer understanding behind email authentication and its potential value. We would love to hear from you on this!

------

The nature and origins of an email message are often falsely presented by email senders and as such present a host of challenges to legitimate marketers, both large and small. 

The adoption of DKIM (Domain Keys Identified Mail) an initiative produced through a merger of Yahoo!’s Domain Keys and Cisco’s Identified Internet Mail (IIM) provides a foundation for distinguishing legitimate mail and develops a means of associating an identity with a particular message.  With this identity in place, a receiving MTA (Message Transfer Agent) can make decisions about the further handling of the message based upon an assessment (using reputation and accreditation services) of the identity that the message is associated with. 

Receivers who successfully verify the DKIM cryptographic signature can use information about the signer as part of a program to limit spam, spoofing or phishing, or any other unwelcome conduct.  The integral role of DKIM is to determine the verified identity as taking responsibility for the message.

Verifying Identity

Consider an attack against your organization, or even customers of your organization. The name of your organization is linked to particular internet domains and attackers may leverage this either by using the legitimate domain name, without authorization, or a “sister” domain name that is similar to, but not controlled by, your organization.  A receiving organization that employs DKIM can differentiate between domains used by known organizations and domains used by others.  In this role, DKIM positively identifies messages associated with justifiable identities rather than negatively identifying messages with problematic identities.  However, whether a verified identity belongs to a good or bad actor is a question for later steps in the validation process, owned by reputation services. 

DKIM, by itself, does not necessarily increase the chances of a message arriving in someone’s inbox.  What it does, in its simplest case, is validate the integrity of the message, assuring that it has not been tampered with during transit.

DKIM Enables Trust

Email receiving services and organizations are faced with a very basic decision once a message arrives: whether to deliver the newly arrived message to the indicated recipient or not?  Behind this decision is the question of whether the receiving service trusts the message enough to label it as “safe.” Most receiving transfer agents offer services that allow for such a quality assessment.  These agents use reputation and accreditation services such as ReturnPath or Pivotal Veracity to further evaluate the sender.  As the engine processes information, it either raises or lowers its trust assessment for the message.  For example, trust is increased based on the reputation of the sender by IP address. 

The next step, as I see it, is for reputation services to evaluate digital messages by domain as well.  Evaluating messages based on “domain-reputation” instead of IP addresses can better define who the sender is, since IP addresses incessantly change: suspect senders (spammers) still have the ability to utilize different IPs at a moment’s notice.

In order to determine reputation information, established identification is required.  When using an IP address, accuracy is based on the belief that the underlying communications or infrastructure supplies an accurate address.  When using domain-based reputation data, some other form of validation is needed, since it is not supplied independently by the infrastructure.  DKIM satisfies this requirement by declaring a valid “responsible” identity about which the engine can make a quality assessment and by using a digital signature to ensure that the use of the identifier is authorized.  However, by itself, a valid DKIM signature neither lowers nor raises the level of trust associated with the message.  But it allows other mechanisms to approve the message. 

Establishing Message Integrity

Middleman attacks are few and far between; however, it is possible for a message to be modified during transit.  DKIM’s cryptographic method validates the message integrity.  If, for any reason, it has been changed, the message will not be verified successfully on the receiver’s MTA without using DKIM.   DKIM’s authentication of email identity can assist in the global control of “spam” and “phishing.”  There has been a trend to using more than one mode of authentication too.  For example, Ralph Lauren and Southwest Airlines, both use Domain Keys and DKIM to authenticate digital messages.  This theory allows for senders using dual mode to “cover their bases” as fewer receivers rarely check for both Domain Keys and DKIM.

As DKIM gains traction in the digital messaging marketplace, organizations and ISPs are likely to develop business rules that reward senders and receivers that use any one of these authentication methods.  In a recent OTA (Online Trust Alliance)  town hall meeting, hypothetical solutions for when organizations choose not to authenticate messages were discussed.   Many ideas were proposed and the discussion of their merits is on-going, but one interesting thought to come out of this meeting was the idea that organizations choosing to bypass authentication may be subject to a digital tariff.

-Dennis

Eloqua

Don't Just Send, Deliver!

Google announces they're rolling out their own version of anti-phishing protection - the super trustworthy, anti-phishing key . Unless you're a financial institution, you probably won't be able to get this for your own email for some time. But, at least you'll know it might be coming out of beta at some point.

From Brad Taylor, Gmail's Anti-spam Czar:

"Super trustworthy...means 1) the sender, usually a financial institution, is a target of phishers, (2) all of the sender's email is authenticated with DKIM, and (3) Gmail rejects any fake messages that claim to come from this sender, but actually don't."

Full story here.

With all the different technology Obama's administration has been using during his first months in office (including Twitter, Facebook and blogs), their heavy use of email as a communication channel is no surprise. However, it was surprising to see their email updates subscribing to Goodmail's CertifiedEmail service. I saw the following on David Axelrod's announcement yesterday driving traffic to Obama's latest international diplomatic speech in my Yahoo! webclient.

(If you don't use Yahoo!, the Learn More link above takes you here.)

Now that the White House has implicitly backed one of these services, it will be interesting to see if this has any affect on the rest of the email industry. If it's good enough for the President...

GovDelivery, the White House's ESP, is hosting the services. It would be interesting to see if this new addition helps drive down what I could only imagine being a plethora of phishing or spam attacks claiming to be from Obama and his staff. Also, the email is very image/link light so it would seem this effort was less around enabling users to take immediate action and more about reinforcing the identity and inbox delivery of the email.

Many e-commerce and multichannel retailers need to go to greater lengths to prevent deceptive e-mail and phishing scams, according to industry group the Online Trust Alliance (OTA).

The organization released a report last week claiming that 56% of .gov Web sites and 45% of leading e-commerce sites are not taking appropriate e-mail and domain security measures....

--MORE--

http://www.dmnews.com/Companies-must-take-e-mail-authentication-seriously-to-protect-brands-and-domains/article/130754/

-Dennis

Eloqua

Don't Just Send, Deliver!

George Bilbrey over at ReturnPath blogged about a new white paper published on the conversion and delivery rates of three symbolic spam campaigns. Since he always has great insight to the analytical nature of email, I had to read it.

Disclaimer: this is a very technical and empirical overview of the lower level protocols measured when sending email. You could probably just skip to the conclusion if you want to bypass the framework of the experiment and get to the point, although I would highly suggest reading the entire paper to spur ideas on how we in the email industry can measure the affect of spam on our email at ISPs. While none of us reading this blog presumably send blatant spam, we are directly impacted by the defenses ISPs put up and constantly change to thwart new spam attack vectors. This directly impacts email deliverability.

A few thoughts:

• The team who executed this test explained how their approach was ethical. By only acting as a proxy, not originating any new spam email (but rather capturing mail already in flight) and rewriting URLs to be benign, they side stepped a potentially dangerous situation. From my experience, granted it's nothing compared to the researchers who have a lot more education than me, punishing recipients or introducing a punitive bias doesn't work in the business world. It just pisses people off if and when they find themselves at the receiving end of an experiment they didn't opt in to and can run afoul of the law in this case.



• No authentication was tested as an additional variable to the spam delivery rates. It would be interesting to see how the presence of DK/DKIM/SPF/SID would affect this.



• No open rates were measured. It would seem that if links could be rewritten in the message body, spacer images could be inserted to indicate an upper bound of emails being rendered on client email programs.



• The CBL (Composite Blocking List) was heavily monitored during the time frame to see when blacklisting occurred and at what rate. It would be interesting to measure other RBLs as well to show the efficacy of one v. another.



• Finally, the presumption that the TLD (or ending extension of the recipient's email address such as .au or .com) shows where the recipient is actually located is a bit limiting. I'm not sure how you could avoid this, other than some sort of geo IP mapping with the calling IPs for links/images, but there are definitely recipients who get an email address at one regional ISP but take that with them when they move to another region. For instance, in my experience with EU addresses, there is a tendency for recipients to get a .com (usually US) address regardless of where they are located. Although a small segment, this would directly correlate to the causation of the spam education affecting lower spam conversion.

Net of the paper is that while spam might be a revenue generator, the amount of profit derived from the spam campaigns tested (pharmacy, post card and April Fools) is driven down by the amount of expenses associated with keeping an email infrastructure in place. The cost of hosting bad domains over a period of time and setting up/maintaining alternate routes of detection is considerable.

This is good news for legitimate senders in that spam doesn't directly cause one to become rich and thus decreases the appeal to entering into the business in the first place. Or at least I hope.

I joined Genius.com a few months ago as a member of their Deliverability and Anti-Abuse team. My focus is on deliverability and managing the email servers. Genius has a great application that gets marketers and sales people working together. The Genius application relies heavily on emails being sent to the right people at the right time.

In addition to email deliverability, I have a background in system admin, programming (among other nerdy pursuits) and I am active in the technical (and sometimes political) Internet community which helps me in the world of deliverability . I look forward to sharing my experience with you over the coming weeks.

The world of DKIM: Domain Keys Identified Mail.

One of the challenges in identifying suspicious email is knowing reliably where it came from. With email coming from a wide variety of machines, it’s possible that a machine has been compromised and a malicious sender is spoofing mail headers, injecting false headers and essentially misrepresenting a third party. A lot of spam is generated by compromised machines which are part of botnets, networks of thousands (even millions) of remotely controlled machines. Some of these machines can be even legitimate mail servers, some can send email via ISP or ESP mail servers (ISP: Internet Service Provider, ESP: Email service provider). How do we know who is who? Who should we complain to? Some services like spamcop.net, try to analyse emails headers and figure out who was responsible for sending the email but they often also target whoever is managing the networks used to relay the emails. They aim wide, to ensure they will alert someone that will care and fix the spam source.

Would it not be easier to know who is sending emails?

There are some old techniques like Pretty Good Privacy (PGP) and S/MIME but they are heavy to implement because they require the cooperation of all of the users. Besides, we often do not need to authenticate the emails, but have a way to validate where the email is coming from. That is, to identify which system administrator configured the mail server that sent the email. This is the person we want to talk to for any problem. Hopefully he/she is a little bit more clued than the user who sent the email and can take remedial methods. Fixing problems on the Internet involves often finding the person that understands what you want and knows what action to take. End users are rarely in this category, but systems and network administrators are.

Several industry groups tried to solve this problem, the two main technologies that emerged were DomainKeys and Sender Policy Framework (SPF).

Ideally, emerging technologies will evolve to become standards. The Internet Engineering Task Force (IETF) does not generally create new Internet technologies, but they are very good at taking something that a group submits for standardization and making it rock solid because the peer review is strong. This has been the case for example for http (the web protocol), ssl/tls (securing connections between applications) and many others.

They did the same thing with DomainKeys and SPF and issued the DKIM specification. DKIM is now in the Internet Standard track of the IETF. It means if you like it you have a fixed specification you can follow that will work with various and disparate systems. It really become a de-facto standard when a large group implements it.

The main problem with SPF (and a bit with the Sender-ID upgrade) is that emails move from machines to machines before reaching the final destination. In many cases there are only two mail servers involved. The sender and the receiver. SPF inserts a header that tells if you check this domain, it will tell you that this IP address (of the sender) is authorised to send emails for this domain. But if you add a mail relay server, the whole scheme falls flat, as the receiver will have the ip of the mail relay not of the original server. On the other hand DomainKeys has another problem, it can only validate headers that contains the same domain name as the signature. So for instance you can relay a signed message but you cannot sign a message that you relay (like for a mailing list).

DKIM solves all these issues.

At the moment the DKIM Working Group at the IETF is working on specifying a standard for defining policies for the use of DKIM. But first you noticed, I did not say that DKIM authenticates an email, as it is not true. It just validates some headers. It is up to the receiver to process the email based on the successful validation of certain headers and deliver it to your inbox, junk folder, etc. DKIM allows a mail admin (or rather a mail server) to take responsibility for sending/forwarding an email and let other servers know.

This is convenient for instance, to build reputation based on who takes responsibility for sending/forwarding the email. For instance AOL has announced that they will move from IP based reputation to Domain based reputation using DKIM. Similarly, Yahoo provides a feedback loop based on the domain validating the email using DKIM. It does not matter which IP the email comes from.

But what are DKIM policies?

For instance, e-Bay and Google have announced that all the e-Bay emails will be DKIM validated and that Google will use this information to trash any email supposedly from e-Bay which is not DKIM validated. Imagine if all the banks were following this policy. It would seriously reduce the amount of phishing.

Third party validation.

I spoke earlier, that a relay mail server can validate an email. For instance in the case of mailing lists. The mailing list software receives an email, and decides to use its reputation to forward the email to all the subscribers. It can do a third party validation on an email it is forwarding. There is no requirement that any headers in the email (From, Sender, …) contain the same domain name as the domain name of the mailing list. This opens other possibilities. Let's take the bank example, instead of each bank having their own DKIM validation, they could also have a validation done by a bank confederation, authority or regulator (third party). This would add another level of reputation on the email (while they can still add their own DKIM validation to the email).

Genius is providing third party validation on all our customers’ emails. We are taking responsibility for the emails we send on behalf of our customers by ensuring they are DKIM authenticated. There is no silver bullet in ensuring a high rate of email deliverability and DKIM is just one of the layers that help deliverability from a technical perspective. The Genius Email Deliverability and Abuse team in addition to DKIM ensures high rates of deliverability through close and proactive management of its customers email campaigns, education and best practices.

PS: feel free to contact me with comments and suggestions and email delivery related topics you'd be interested in learning more about.

AOL announced its plans to begin DKIM verification sometime this next year during an ESPC call moderated by Ben Isaacson of CheetahMail with special guest Mike Adkins from AOL.  DKIM is the next generation of DomainKeys, an encryption based authentication method, which is picking up adoption in the receiver community.  Currently, AOL uses an IP based reputation algorithm to determine the propensity of outbound mail to be spam. Under the new paradigm, a sender’s domain will be verified against the DKIM signature with inbox success being determined by that domain’s reputation.  Mike proposed that by the end of the first half of 2009 an initial version checking the signature will be in place. 

 

It is important to note that the current IP based reputation filters and delivery metrics will continue as they have been with a regular and enhanced whitelist.  DKIM will follow the same pattern with a domain whitelist explicitly requested by senders providing information about the domain and an enhanced domain whitelist that will be dynamically controlled by AOL (also coined an organic whitelist).  Domain reputation will be looked at as the first layer of the onion and, absent DKIM, will fall back on IP based reputation scoring.  It was also mentioned that SPF will be actively used as another data point providing information about a sender, whereas now SPF is checked but not used in the reputation algorithm. 

 

You can use *@dkimtest.aol.com to test whether your outbound mail is DKIM signed properly (the * is a wildcard character meaning anything can be used, such as test123@dkimtest.aol.com). There are some other special provisions that will be included with the DKIM verification in regards to some third party accreditation services which inject headers into the envelope.  It’s important to note that the first revision of DKIM with AOL will only help to add value to senders’ efforts for delivery but won’t punish senders who don’t currently sign.  But, as Mike stated, they want to keep their email recipients “safe and happy” and to that end, the likelihood that DKIM will be used in greater force in the distant future is very possible.  Net – get your email DKIM signed sooner rather than later!

 

To keep up with the latest on AOL, check out their blog.

Dancho Danchev rightfully scolds the 60% of the Fortune 500 who still aren't using authentication on their primary domains to prevent phishing attacks.

Many of the readers of this blog send email marketing on behalf of the Fortune 500, and I'm sure that most of that email is authenticated with Sender ID or Domain Keys / DKIM. But most of that email is not sent from the primary domain of company - it comes from news@mktg.ford.com instead of news@ford.com or something like that. We do this to help with email deliverability, but our primary concern is not protecting the domains that we don't use from phishing (we care, but we don't get paid to care).

The lesson for marketers is that we should be educating our customers more about why and how to set up Sender ID and DKIM for their primary domains in addition to the ones that we send mail from. While it may not affect us on our next campaign, it will protect the long term viability of the customer's email reputation and will make you look smart to your customer!

Anne Mitchell of ISIPP posts "How the Email Deliverability Accreditation and Reputation Industry is Eating Itself Alive" a screed about how some in the space are dissing the competition to make sales.

While some negatives are inevitable in comparison shopping materials provided by sales types, this type of thing reminds me of something a boss of mine once said: Referring at the time to the small amount of money we had to divvy up among the various departments under his control, he quipped 'when the water runs out, the animals around the watering hole look at one another differently'.

Quite so. I have to wonder if such desperate tactics are brought about by a monetary compression at a given firm, or if they speak to portended industry health. Actually, I tend towards the former explanation rather than the latter; I don't think email has anything to fear, indeed, it is probably a growth area in a receding market. While all indicators for the over-all economy may be downwards trending, as the cost of travel increases, and face-to-face becomes ever more dear, surely the ability to communicate from afar will become ever more valuable.

Emails are sent from a mail server (a MTA) to another. The receiving MTA chooses to accept or not the email, hence deliverability issues. Most antispam filters are based on the idea than a given mail server has a specific probability of sending spam. For instance, a mail server sending Viagra spam has either a security breach (enabling spammer to use it) or is a spam server. In both cases, the receiving MTA should reject emails coming from this server.  (As we all know, this approach has its limitations but this is not the point of this post.) Therefore each IP sending mail is scored with respect to its history.

But using an IP address as the unit (the grain) for scoring introduces some important problems. For instance,

• IP address are usually not « owned » by email senders (whether ESP or corporate customers), hence they are unreliable over time.
• IP address changes over time: new servers are added, some are deprovisioned
• No authentication are « embedded » inside the score.
• A lot of email senders are sending their emails on a lot of different IP addresses.

For instance,

• It is easy to bypass the reputation system to send phishing emails.
• Enabling or deprovisioning a mail server is complicated.
• Shared mail servers are not handled at all in this system: what can you infer from  a shared email servers with different sending patterns?
• An ESP using three different IP addresses can have some emails accepted while others would be rejected.

A system abstracting IP address and binding an email sent to this system would solve these issues. The good news is that it is already here: it is the domain name system or DNS.

Currently SMTP (the email protocol) provides no way to bind an email to a domain name (for instance you can send email from Gmail servers with any domains you want). This is why some new protocols have been issued.  The main ones are SPF, SenderId, Domain Keys and DKIM.

Each has its own set of specificities but they all share some common traits: they bind an email sent to a DNS entry. Because of this binding, antispam filters can score now the domain names instead of the IP address (reflecting for instance a specific sender).

SPF and SenderID are using IP addresses while DK and DKIM are using a public/private key system.

It seems that antispam filters will not stop using IP addresses but the importance of the domain name will grow. In a further post, I will examine what it means for ESP, their customers.