If you are an email marketer, whether using a service provider or an in-house solution, you’ve no doubt heard the term email authentication lately. With spam and identity fraud via phishing and spoofing showing no end in sight, many Internet Service Providers (ISPs) have turned towards stricter ways of handling/accepting bulk emails to stop such nefarious practices. Unfortunately, as often happens when a group of technology companies try to create new policies, several different standards have emerged, leading the email marketer the unenviable task of trying to make sense of it all. With that in mind, here’s a quick and easy overview to help you sort through the weeds.
IP Based Authentication
IP-based authentication is the most widely used form being offered by ISPs today. It’s as simple as the name implies: mail is filtered based upon the sender’s IP being verified/validated by the receiving mail server. Within this strategy, 2 similar but different forms have evolved, which of which is explained below:
Sender Policy Framework (SPF)
Sender Policy Framework is the granddaddy of all authentication methods. Developed as an open source project, it is also the simplest and most straightforward process used. In this case, the sender publishes an SPF ”record” as part of their Domain Name System (DNS), which is basically the White Pages of the Web, matching up specific IP addresses with a registered domain(s). If a company is sending their own mail, then they add their own SPF record to the DNS registry. If using an ESP, then their ESP must give them the SPF record for them to add to their DNS registry for them. The end result is that the receiver can see, via the SPF record, that the sender is actually who they claim to be in their From Address.
Bottom Line: SPF is the easiest method to implement but has been criticized for being too easy and therefore not as effective as other forms of authentication.
Sender ID Framework (SIDF)
As a response to SPF being too basic to be a true form of authentication, a new standard was developed which combined SPF with Microsoft’s ”caller ID for email” system. In the caller ID portion, the Purported Responsible Address (PRA) is authenticated along with the SPF record. This is also called the visible FROM address as it is the address located inside the message header. To use a snail mail analogy, the SPF is the address on the envelope and the ID is the letterhead that matches the From Address. Recipients also have the choice of accepting the ID and/or the SPF record. Thus, it makes it a bit more secure than just having SPF in place.
Bottom Line: SIDF is a good alternative to SPF and is starting to gain more adoption due to its more complete method but still has issues in terms of security of the message content itself.
While IP-based authentication has been relatively successful in trying to combat the scourge of phishing/spoofing, as noted, these methods do not validate/protect the message itself. Enter cryptographic authentication. Initially, there were two forms of this method that were developed, Domain Keys (DK) – by Yahoo! and Identified Internet Mail (IIM) – by Cisco. However, last year the companies agreed to merge their respective methods into a single, unified format, called DKIM.
DKIM is the newest form of cryptographic authentication, having been implemented in May 2007. As noted above, DKIM is the combination of 2 previous methods – Domain Keys and Identified Internet Mail. The consolidated DKIM is the first end-to-end authentication process, from signing to verification. The sender first digitally ”signs” the messages by inserting a domain key in the header of the message, which is a bit of code that contains the domain being certified and its matching IP address. Major adopters of DKIM include Yahoo! Mail and Gmail.
A private key (meaning a key used solely by the sender) is generated by the sending mail server (MTA), which should include DKIM as part of their technology, such as Strongmail System’s MTA. Once the message is sent, the receiving host decrypts the code via its public key (shared by any ISPs using the DKIM methodology), does a DNS lookup to validate the sending IP and if there’s a match, allows the message to pass through its filters.
Bottom Line: DKIM is quickly being recognized as the preferred method for authentication given its depth and scope. However, in order to use DKIM properly companies must either have their own MTA with the technology implemented or use an email service provider.
In the end, there is no one perfect solution for authentication and as noted above, there is also no one true standard. Keeping up with these changing standards can be a very challenging job for the average email marketer. While some of the methodologies mentioned can be implemented with relative ease, others like DKIM require both programmatic and human interaction to be successfully implemented. Fortunately, there are solutions out there such as mobileStorm’s Brand Authentication and Assurance package that ameliorate the workload involved. Such solutions can be a godsend for email marketers and should be seriously considered instead of attempting the process themselves.