Sender ID is a combination of Microsoft's Caller ID for Email and Sender Policy Framework. Sender ID and SPF differ in what problems they address. They validate separate header fields and work at different layers of the email system. Sender ID requires SPF in order to work, which makes the framework a higher level protocol.
As with most Microsoft-led initiatives, there has been some controversy. Depending on how Sender ID is implemented, the framework can be incompatible with existing specifications. Microsoft also holds patents on key parts of Sender ID, despite having just placed them under the Open Specification Promise, which can make the patents compatible with free and open source licenses. This should encourage the release of more products and services that use Sender ID technology. According to Microsoft, 5 million domains use Sender ID, meaning that around 36% of all legitimately sent email has been authenticated by the technology. Microsoft obviously uses it to check incoming mail to its own servers, as well as those of MSN and Hotmail. To implement Sender ID on Microsoft Exchange Server 2003 running Service Pack 2, configure the properties of the Message Delivery object under Global Settings.
There are other antispam technologies in development, including signing solutions. DomainKeys, created by Yahoo, uses public key cryptography as part of its authentication process. This technology will certainly prevent some types of attack, but deployment is not going to be as easy. Also, unlike Sender ID, DomainKeys cannot reject a message until the whole body has been received.
So how well does Sender ID stop spam? Well, it's easy to implement and is certainly a significant step toward countering spam and phishing attacks. Sender ID, however, does require everyone to create SPF records for their domains so that senders can be verified, and this process is one that cannot happen overnight, if at all. I don't believe there is a single solution to stopping all spam. Sender ID can certainly be used as a component of a multi-layered approach. Messages that fail checking, for example, can be rejected or subjected to a higher level of scrutiny than those that pass. Mail servers certainly still need to consider past behavior, traffic patterns, and sender reputation, as well as apply conventional content filters when determining whether to deliver mail to the recipient.
Dig Deeper on Email Security Guidelines, Encryption and Appliances
Related Q&A from Michael Cobb
Google is beginning to encrypt data by default on its Android devices. Expert Michael Cobb explains how this change will affect enterprise BYOD ...continue reading
Securing enterprise communications has become a top concern lately. However, finding the application that best suits your enterprise security needs ...continue reading
Expert Michael Cobb provides background on the RC4 encryption algorithm and determines whether a recent RC4 attack signals trouble for SSL/TLS users.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.