SPF stands for Sender Policy Framework. Don’t go with its name like other terminology where you’ll find written something like ‘as its name suggest’. Because its name won’t suggest you anything for the first time 🙂
It is an Email Authentication technique where the sender can make a stamp on their “Envelope” MAIL FROM (sending domain). It designates for a particular set of mail servers.
In simple word you are telling to internet world that you are going to have an “Envelope” MAIL FROM (sending domain), which will send some amount of emails from a fixed number of mail servers. Now the question is how? Basically, this is done using a TEXT information (also called TXT record) which is stored or published in domain’s DNS zone. The TEXT information is written using a particular syntax so that computer can understand it. This record has all the required details about the mail server. I’ll discuss below how it looks like and how to set up this. But before going into that area let’s see the history of SPF and why actually we needed.
It describes a method of verifying whether a sender is valid when accepting mail from a remote mail server or email client. An SPF check involves verifying the email address the sender is using to send from, and the IP address they connect to the SMTP service with. SPF uses the sender’s domain to retrieve a TXT DNS record (basically a small text snippet) that describes which IP addresses the domain sends on. The retrieved record is then compared to the connecting IP address. And if it matches then the sender is determined to be valid; otherwise, it indicates that the sender is impersonating the sending domain.
In other words, Sender Policy Framework is a method of detecting when an email sender is forging their sender address. It does this by confirming with the sender’s alleged domain (via DNS lookups) as to whether the connecting IP address or other details are valid. For example, if a spammer was sending emails as loot_lo_offer@aol.com, a lookup is done for SPF details against the AOL.com domain. Information returned from this lookup could determine that since the IP address of the spammer is not an AOL IP address then it is likely to be spam. Email can then be marked as likely spam, or not accepted. An SPF record can also be more complicated than just a list of IP addresses, in order to give more flexibility.
History of SPF
The idea of verifying SMTP “Envelope” MAIL FROM has a long history that goes back to 1997. During that time multiple people proposed their own technique which all were almost similar. These were submitted independently at various times. But, the first serious development of this took place in 2003 when the email based communication took a high jump on the internet.
The first draft was submitted by Gordon Fecyk in 2003 and called “Designated Senders Protocol” which then later known as SPF. Originally SPF stood for Sender Permitted From and was sometimes also called SMTP+SPF, but its name was changed to Sender Policy Framework in February 2004. In July 2005, this version of the specification was approved by the IESG as an IETF experiment, inviting the community to observe SPF during the two years following publication. On April 28, 2006, the SPF RFC was published as experimental RFC 4408.
Why we needed the SPF?
If you read the first two lines of this article you must realize why we needed it actually. You SPF is one of the email authentication technique. Using this we mail server can identify that the said email is coming from the original sender? or someone is trying to spoof the sender reputation. If you open your spam folder of your mailbox you can see there are some emails who are claiming themselves as TATA, Honda, Vodafone or other brands and by using their names they want to steal some information from you or they want to do something wrong with you. Don’t worry and you really don’t need to think because this is the reason why they are in your spam folder. So just leave it or delete it.
SPF in details.
To explain further first assume that we have few things as listed below:
Email Sending Domain: mail.universityofemail.com
IPs: 198.10.10.2, 198.10.10.3
Example: How an SPF record looks like –
v=spf1 ip4:198.10.10.2 ip4:198.10.10.3 -all [This is a text (TXT) record which must be populated in sending domain’s DNS Zone ie mail.universityofemail.com]
SPF may looks like –
v=spf1 ip4:198.10.10.2 ip4:198.10.10.3 -all ORv=spf1 ip4:198.10.10.2 ip4:198.10.10.3 ~all ORv=spf1 ip4:198.10.10.2 ip4:198.10.10.3 +all ORv=spf1 ip4:198.10.10.2 ip4:198.10.10.3 ?all Note- These are just a few examples of how SPF looks like so don’t get confused if you see some complex SPF. There are many ways to create SPF.
v=spf1 is the version indicator
198.10.10.[2-3] is the allowed sending IPs
-all: means only allow mail that matches one of the parameters (IPv4, MX, etc) in the record.
~all: means recipients may accept mail from another server as well, but it should be viewed with suspicion.
+all: means allow all mail
?all: No policy statement
Note- "~", "-", "+", "?" these are four mechanisms used in SPF. Meanings explained above, still if you have any doubt just make a comment.
Of course, as said above there are other ways to define authorized IP addresses. Using v=spf1 mx -all authorizes any IP that is also an MX for the sending domain. or v=spf1 a -all for A record of the domain and etc.
mail.universityofemail.com TXT "v=spf1 a -all
This record tells us that the only host that can announce itself as mail.universityofemail.com is mail.universityofemail.com (indicated by the “a”)
universityofemail.com. TXT "v=spf1 a:mail.universityofemail.com -all
This record indicates that there is only one server that is allowed to send mail using the universityofemail.com domain, and that is mail.universityofemail.com. Now that we know that, we look up the IP address of the mail.universityofemail.com host.
mail.universityofemail.com TXT "v=spf1 mx:mail.universityofemail.com -all
Specifying mx:mail.universityofemail.com is generally incorrect unless you truly want SPF validation to look up all the hosts that accept mail for the “mail.universityofemail.com” domain. Usually, there will not be any such hosts, because mail.universityofemail.com is itself a host, not a domain. This will not show up as a syntax error, however, it will simply not match anything.
The correct usage for validating against the MX records for universityofemail.com is mx:universityofemail.com, or if you want to specify a particular mail server’s hostname or IP, a:mailserver.universityofemail.com or ip4:198.10.10.2. Finally, note that when your SPF rule is stored as a DNS record associated with universityofemail.com, then universityofemail.com is the default domain for the rule. So mx on its own (with no explicit domain specified) is sufficient to check the sender IP against all the MX mail hosts listed for universityofemail.com, in that context.
Other SPF records can be included using the include: command; for instance, include:_spf.google.com includes Google’s SPF record. IPs can be in either IPv4 space or IPv6 space by using either the ip4 or ip6 qualifiers: v=spf1 ip4:198.10.10.2 ip6:2001:db8:8:4::2 -all. SPF records can also contain IP ranges in the form v=spf1 ip4:198.10.10.2/25 -all.
