The History and Evolution of Sender Policy Framework (SPF)

The digital landscape is ever-expanding, both in a malicious as well as positive sense. Also, communication is an inevitable part of businesses and operations, and email is a common medium for exchanging messages and information. Bad actors have always exploited their intelligence and capabilities to impose themselves as trusted entities and fool people into giving up important information or transferring money. 

The growing number of email-based cyber menaces led to the genesis of the concept of email authentication and verification to ensure that only trusted and authorized senders communicate through a company’s email system. All this started in the early 2000s with the brainstorming that brought forth what we call today the SPF or Sender Policy Framework. This was later complemented with the introduction of DomainKeys Identified Mail or DKIM and Domain-based Message Authentication, Reporting, and Conformance or DMARC

Let’s learn about the genesis and evolution of the first email authentication protocol that keeps spammers at a distance while boosting your domain’s authority and deliverability

The Emergence of SPF; A Chronicle of Secure Communication

The need for email protection through the concept of SPF was felt and discussed in 2000, but not much effort was directed toward this thought at that time. Later, in 2002, Dana Valerie Reese researched and issued an SPF-like technology without the awareness of its previous public mention.  

The next day, an American scientist named Paul Vixie published his SPF-like authentication technique, which accelerated the formation of the IETF Anti-Spam Research Group to develop the protocol for public use. Several experts sent their proposals to IETF, including the Reverse MX (RMX) by Hadmut Danisch and ‘Designated Mailer Protocol’ (DMP) by Gordon Fecyk.

The Primary Phase

December 14, 1997- Ideation

Jim Miller came up with the idea of verifying SMTP MAIL FROM address using outbound-SMTP DNS records. However, the exact date and occurrence of the event are not confirmed as they are based on Paul Vixie’s statement alone.

March 27, 2000- Public Mention of the Idea

Bill Cole took the Usenet newsgroup to articulate the idea of developing Mail Sender DNS records to capture outgoing email servers of a domain

June 1, 2002- Publishing of the Mail Transmitter RR Draft by David Green

David Greens put forward and published a mail-transmitter RR draft specifying the new DNS type MT DNS RR. This first ‘Authorized-By’ draft later found a space in other IETF drafts.

June 2, 2002- Paul Vixie’s Repudiated Mail From Draft

Paul Vixie reacted to David Green’s post and sent a draft called “Repudiating MAIL FROM” to name droppers mail list

December 3, 2002- Initial RMX Draft by Hadmudt Danish

Hadmut Danisch developed and published the first version of RMX, which is a DNS RR for simple SMTP sender authentication. This draft focused on using the then-latest DNS RR type RMX to publish an IP4 network block or redirection to the APL record.

March 28, 2003- Initial DMP Draft by Gordon Fecyk

Gordon Fecyk drafted Version 00 of Designated Senders Protocols that proposed a DNSBL-like technology for allowing the use of RFC2821 MAIL FROM. This was followed by the publication of Version 01 and Version 02, which were later renamed to Designated Mailers Protocol. A few more years later, it started getting referred to as DMP As of version 03 of Fecyk-dsprotocol series drafts. 

June 10, 2003- Meng Weng Wong’s SPF-discussion Mail List

Until 2003, SPF was under development and wasn’t publicly available. In June 2003, Meng Weng Wong stole the limelight by releasing the first-ever public version of SPF which was then an acronym for ‘Sender Permitted From’ and not ‘Sender Policy Framework.’

August 18, 2003- Wayne Schlitt’s ‘mx’ Operation

Wayne Schlitt proposed the idea of the ‘mx’ mechanism

August 19, 2003- David Saez’s ‘spf include’ Operation

David Saez upgraded the SPF’s scope by introducing the ‘include’ mechanism. This allowed domain owners to include the sending sources of third-party vendors who regularly dispatch emails on their behalf. 

October 1, 2003- Beginning of the ASRG Mail From 

Developers and technology enthusiasts came together to discuss the merging of SPF into a unified proposal for checking MAIL FROM to be produced and refined as part of ASRG. 

October 8, 2003- Change of DNS Type

Paul Wouters strongly encouraged the use of the new DNS RR type instead of overburdening the TXT record type. A few days later, Meng also articulated the urgency for the adoption of the new RR type.

October 10, 2003- Beginning of the v=spf1 Version

Meng Weng Wong posted refined concepts by unifying ideas proposed by people on open discussion platforms. 

The Second Phase

The second phase of the Sender Policy Framework’s remarkable journey was bringing in the concept of Sender ID, which was formed by merging SPF with Microsoft’s Caller ID for emails. 

Sender ID, however, faced challenges related to licensing terms, leading to a division within the industry. Many organizations chose to support SPF exclusively, and this division marked a pivotal point in SPF’s evolution. Despite the challenges, SPF continued to evolve, refining its specifications and addressing limitations to improve its effectiveness in combating email spoofing and phishing attacks.

Image sourced from

The Current SPF Standard

As per the current SPF scenario, it prevents bad actors from sending emails by impersonating businesses and their representatives. It allows domain owners to specify which email servers are authorized to send messages on their behalf. SPF has proven effective in reducing the prevalence of email-based threats, particularly those associated with domain spoofing. As organizations and individuals increasingly recognize the importance of secure communication, SPF continues to play a crucial role in the fight against phishing and other malicious activities.

SPF Challenges and Future Prospects 

SPF’s limitations lie in email forwarding as messages pass through multiple intermediate servers. Moreover, it struggles to be in conjunction with cloud-based email services as they involve complex email routing mechanisms

Complementary authentication mechanisms such as DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting, and Conformance (DMARC) have gained prominence in response to these challenges. These mechanisms work in tandem with SPF to provide a more comprehensive and resilient defense against email-based threats.

Similar Posts