These days, nearly all junk emails messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets affected and they have to waste their time sorting out misdirected bounce messages.
You probably have experienced one kind of abuse or another of your e-mail address yourself in the past, e.g. when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address. Or you nay have received spam mails which have been sent from your e-mail ID.
These types of SPAM technique are called Sender address forgery or Spoof Mail. It is a threat to users and companies.
There is a Solution for that!
SPF: Sender Policy Framework
The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages.
Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together:
(1) The domain owner publishes this information in an SPF record in the domain’s DNS zone, and when someone else’s mail server receives a message claiming to come from that domain, and then,
(2) The receiving server can check whether the message complies with the domain’s stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.
Once you are confident about the authenticity of the sender address, you can finally “take it for real” and attach reputation to it. Furthermore, additional kinds of policies are planned for a future version of SPF, such as asserting that all of a domain’s outgoing mail is S/MIME or PGP signed.
An Example Policy
Let’s look at an example to give you an idea of how SPF works. Bob owns the domain domain.com. He also sometimes sends mail through his otherdomain.com account.
example.net. TXT “v=spf1 mx ip4:10.100.110.201 mx:domain.com a:pluto. domain.com include:mail.otherdomain.com -all”
The parts of the SPF record mean the following:
v=spf1 : this identifies the TXT record as an SPF string. SPF version 1.
mx : the incoming mail servers (MXes) of the domain are authorized to also send mail for domain.com. If you add more MX servers in the future, they’ll automatically be allowed, too.
ip4:10.100.110.201: 10.100.110.201 is allowed to send mail from domain.com.
mx:domain.com: The MX servers for domain.com are allowed to send mail from domain.com.
a:pluto.domain.com: the Host pluto.domain.com is authorized, too send mail
include:mail.otherdomain.com: everything considered legitimate by mail.otherdomain.com (outside mail server) is legitimate for domain.com, too
-all : No other servers are allowed to send mail from domain.com. This is a good default for sites particularly concerned about forgery.
This example demonstrates but a small part of SPF’s expressiveness. Do not take it as a guideline for building your own record — things might not work out as you expect and legitimate messages might get blocked! Instead, learn more about the record syntax, or get the complete picture by studying the full specification or contact your hosting service provider.
Today Gmail, Hotmail, Rediffmail, Microsoft, Redhat, IBM, Citi Bank and most of the leading Service Providers and Companies use SPF and so do we for blocking out unwanted junk emails from reaching our clients inboxes.
Read More about SPF at: