Sender ID Framework is an email authentication protocol designed to keep spammers out of the inbox. It’s pretty similar to Sender Policy Framework (SPF), but with one main difference; Sender ID verifies sender identity based on the Purported Responsible Address (PRA) domain using the From: or Sender: header fields. For those a little less technical, it’s simply a different way to identify the legitimacy of a sender.
Sender ID was developed by Microsoft to help prevent spammers from duping unsuspecting customers into downloading malware or giving away their personally identifiable information. By authenticating your email streams with Sender ID, you are helping mail receivers sort through the barrage of spam they receive on a daily basis. There had been some talk that Sender ID was dead, but Sender ID continues to provide important benefits to both senders and receivers.
How Sender ID Works
Sender ID verifies the origin of the email address based on IP address and domain, and then uses the validation results to determine email delivery. When a sender deploys a message, the inbound mail server checks the DNS entries to obtain the SPF Record. It then checks the record to see if the IP address matches the sending server. If there is a match, then the messages pass authentication and can be delivered. However, if there is no match, authentication will fail and the email will either be rejected or delivered to the spam folder. To easily create an SPF record, check out these wizards.
Figure 1: SIDF process courtesy of Microsoft
Sender ID vs. SPF
You may be asking, why implement Sender ID if it’s just like SPF? That is a good question and since they use very similar methods to authenticate mail including the same syntax for their policy records. However, Sender ID addresses a very different problem than SPF.
Unlike SPF which validates against the envelope’s return-path address which is the root or subdomain, Sender ID validates based on the PRA and uses the header field with the email address to identify the visible sender of the message. Since headers are not required by the SMTP protocol, Sender ID uses the content of the message to provide an extra layer of protection against spammers and phishers that is very different from SPF which validates on the domain or connection level.
In sum, it is not an either/or scenario when implementing Sender ID or SPF. In fact, both should be adopted along with DKIM. These methodologies complement each other and in doing so, provide the best protection against phishing and help best email deliverability.