Back in the days when SMTP (Simple Mail Transfer Protocol) was designed, it lacked any authentication techniques. Over time, threat actors started misusing email communication channels as they were only protected by passwords, which are easy to breach. As emails became one of the common attack vectors, companies felt the need to devise a solution that could authenticate senders so that only legitimate emails pass through.
Some of the solutions proposed at that time were— Sender Policy Framework (SPF), Sender ID (Microsoft’s initiative), DomainKeys (Yahoo’s early authentication method), and DKIM (DomainKeys Identified Mail).
Of these four, SPF and Sender ID looked like the best solutions; hence, they competed most directly for adoption.
What is SPF and how does it work towards email security?
SPF is an email authentication protocol that allows a domain owner to specify which all mail servers they authorize and trust to be used for sending emails on behalf of their business. Any email sent from their domain using mail servers other than the ones specified by them in the SPF record doesn’t pass the SPF authentication checks. Domain owners instruct the recipients’ servers to either mark such emails as spam or reject their entries. This way, recipients don’t engage with potentially fraudulent emails and get misled.
SPF prevents instances of phishing and spoofing attempted in the name of your business. Apart from ensuring email security, SPF deployment also helps boost your domain’s reputation. The better the domain reputation, the higher the chances that outgoing emails from your domain will land in the desired recipients’ inboxes. This is very important in email marketing and customer support processes. Moreover, SPF is a widely supported protocol, which is why it’s integrated into modern email security standards.
What is Sender ID and how does it work for email security?
Sender ID was Microsoft’s alternative to SPF, developed in the early 2000s as part of its broader initiative to secure email communication. Sender ID was designed to verify the Purported Responsible Address (PRA)—the email address appearing in the ‘From’ field, rather than just checking the IP of the sending mail server like SPF.
The domain owner publishes a Sender ID record in DNS. When an email is received, the recipient’s server checks the PRA against the Sender ID record. If the PRA matches an authorized sender, the email is considered legitimate. If there is no match, the email may be marked as suspicious or rejected.
The advantage of Sender ID is that it focuses on the ‘From’ field, which aligns more closely with user perception. This offers a broader verification approach as compared to SPF.
SPF vs. Sender ID: key differences
| Feature | SPF | Sender ID |
| Authentication target | Checks sending mail server’s IP | Verifies the ‘From’ address |
| Record type | TXT DNS records | TXT or SPF records |
| Compatibility | Works with all mail servers | Incompatible with some mail forwarding setups |
| Adoption | Widely adopted | Faced resistance due to Microsoft’s licensing model |
| Standardization | RFC 4408, later RFC 7208 | Proposed but not widely accepted |
Why did SPF prevail over Sender ID?
Today, SPF is encouraged by all email service providers and is implemented alongside DKIM and DMARC because of the following reasons-
Technical simplicity and compatibility
SPF was designed in a way that it fits well with the existing email infrastructure without requiring changes to email headers. On the other hand, Sender ID relies on the PRA, due to which it wasn’t compatible with the existing standards. It causes issues with forwarded emails and mailing lists.
Open standard vs proprietary licensing
SPF was an open standard, meaning anyone could implement it freely. In contrast, Microsoft attempted to assert intellectual property rights over Sender ID, requiring organizations to license it. This discouraged adoption by non-Microsoft email providers and open-source communities.
Industry adoption and standardization
SPF was standardized in RFC 4408 (2006) and later refined in RFC 7208 (2014). But if we talk about Sender ID, then it didn’t achieve broad consensus despite the fact that it was backed up by Microsoft— the tech giant. That’s precisely why it eventually became a deprecated technology.
Better compatibility with DKIM and DMARC
As email security evolved, DKIM and DMARC were introduced to complement SPF. Since SPF was widely adopted, it integrated seamlessly into DMARC, making it an essential part of modern email security frameworks.
Microsoft’s gradual shift away from Sender ID
Despite its initial push for Sender ID, Microsoft gradually moved towards supporting SPF and DKIM. Today, Microsoft’s email services, including Outlook and Exchange, prioritize SPF and DMARC over Sender ID.
Final thoughts
SPF has succeeded over Sender ID. However, it’s important to consider the fact that SPF alone is not enough. It has its own set of limitations that can be overcome when paired with DKIM and DMARC. Together, these three fortify unauthorized use of your email-sending domain.
