What is Sender Policy Framework (SPF)? – A Bit of History | EasyDMARC

What is Sender Policy Framework (SPF)? – A Bit of History

5 Min Read
What is SPF – A bit of History 1 1

Knowing what SPF is and how to use it can avert phishing, spamming, and email spoofing in your company’s name. 

Do you know what SPF stands for? Well, it’s short for Sender Policy Framework, an email authentication method that synchronizes with DNS or the Domain Name System. 

Adding an SPF record to your DNS will ensure no genuine email is marked as ‘spam’ or bounced back, consequently increasing your domain’s trustworthiness. 

Now, let’s dig into the history and learn more about the sender policy framework‘s origination story.

The Need for Protection

The first time the SPF concept was publically mentioned was in 2000, but it didn’t get much limelight. It was brought up again after two years, in 2002, when Dana Valerie Reese published an SPF-like specification. At that time, Reese wasn’t aware of the previous existence of the concept. 

The following day, Paul Vixie, an American computer scientist, posted his authentication technique similar to SPF. These posts created a buzz and led to the formation of the IETF Anti-Spam Research Group. They drafted a mailing list to further develop the concept of email authentication, eventually leading to the creation and generating of SPF records. 

Multiple proposals were sent to the Internet Engineering Task Force (IETF) Anti-Spam Research Group, including the Reverse MX (RMX) by Hadmut Danisch and ‘Designated Mailer Protocol’ (DMP) by Gordon Fecyk.

The Roots (1997-2002)

SPF, as we know it today, has a long and rich history dating back to the late 1990s.

According to information shared by Paul Vixie, he received an email from Jim Miller sharing the idea of authenticating the SMTP MAIL FROM address on December 14, 1997. His theory was based on verification using outbound-SMTP MX DNS records.

Later, on March 27, 2000, Bill Cole publicly mentioned the idea of creating ‘MS’ (mail sender) DNS records on a Usenet group. The objective was to record the outgoing email servers of a domain for authentication. Vixie also wrote a draft giving due credit to Jim Miller as the first person to put forward the theory to him. 

David Green published his draft Mail-Transmitter RR on the namedroppers mail list in 2002. This draft mentions a new DNS type (MT DNS RR) but doesn’t specify anything about the format. However, it’s the first public mention of the email header field “authorized-by.” 

Paul Vixie responds with a draft of his own the very next day, posting it in the namedroppers mail list.

On December 3, 2002, Hadmut Danisch published the first RMX draft that specified how a new DNS RR type could be used for IP4 network blocking or redirecting the APL record. At this point, Hadmut claimed unaware of Paul Vixie’s and David Green’s SPF proposals.

The Development (2003-2006)

How does an SPF record work? Thanks to the collaborative ingenuity of various parties, it’s quite simple now compared to previous decades.

In 2003, Meng Weng Wong, a Singaporean computer entrepreneur, combined Danisch’s Reverse MX and Feyck’s Designated Mailers Protocol (DMP) with other theories and proposals to draft a more concise version.

This version underwent multiple alterations for the next six months as a large community was focussing on creating the best version of the SPF protocol. Initially, the full form of SPF was ‘Sender Permitted From’ and was also referred to as SMTP+SPF. 

However, the name was changed to Sender Policy Framework in 2004. 

In early 2004, the Internet Engineering Task Force formed the MARID working group to develop email authentication standards. They merged SPF and Microsoft’s CallerID proposal for creating what’s now known as Sender ID, a historic proposal for combatting spoofing.

However, this theory collapsed as strong disagreements led to technical and licensing problems.

The SPF community returned to the original SPF version in 2005, and it was officially approved by the IESG (Internet Engineering Steering Group). The public was also  requested to observe the SPF protocol for the next two years following publication. 

Finally, on April 28, 2006, it was formally published as experimental RFC 448. In 2007, Hotmail spurred on the widespread adoption of SPF when it made SPF and/or SenderID a requirement to send mail to Hotmail users.

Within a few years, SPF became part and parcel of email security.

The Proposed Standard and Beyond (2014 Onward)

In April 2014, the IETF published SPF in RFC 7208 as a ‘proposed standard.’ So what is SPF as we know it today? 

Creating an SPF record allows domain owners to specify the IPs authorized to send emails using their domain name. The receiving mailbox verifies the SPF records before rejecting or accepting emails.

Businesses use SPF to avert spamming, phishing, scamming, and spoofing by blocking all unidentified computers from successfully sending emails. The present-day SPF record structure has three components: Mechanisms, modifiers, and qualifiers. 

Of course, SPF in today’s sophisticated cyberworld isn’t enough on its own. That’s why DMARC exists. The Domain-based Message Authentication, Reporting and Conformance (DMARC) email authentication protocol takes SPF, and DKIM (DomainKeys Identified Mail) protocols one step further.

Find out how EasyDMARC’s user-friendly DMARC solution protects your domain from Business Email Compromise (BEC), email spoofing, and other cyber threats. Plus, with EasySPF, you can easily optimize your SPF records, whitelist your sending sources, and overcome the “10 DNS lookup” limitation. (Use our free SPF verification tool here.)


The concept of SPF or Sender Policy Framework was first discussed in 2000, but it didn’t get much attention. Dana Valerie Reese allegedly published an SPF-like protocol two years later. 

After carefully studying multiple proposals sent to the IETF Anti-spam Research Group, Meng Weng Wong combined the Reverse MX by Hadmut Danisch and the Designated Mailers Protocol by Gordon Fecyk.

Between 2003 and 2006, SPF underwent several alterations, after which it was formally published as experimental RFC 448. 

In April 2014, IETF published the Sender Policy Framework as a proposed standard that’s still used today.

Various authors from EasyDMARC teams have contributed to our blog during company's lifetime. This author brings everyone together.


Inline Feedbacks
View all comments

succees We’re glad you joined EasyDMARC newsletter! Get ready for valuable email security knowledge every week.

succees You’re already subscribed to EasyDMARC newsletter. Continue learning more about email security with us