The Importance of using SPF (Sender Policy Framework) for your email domain
Consider the following two common situations and see if you can relate to them
- I sent a mail but I received a bounce stating that the recipient’s mail server rejected the mail considering it to be abuse.
- I keep receiving bounce messages for mail I never sent
When you send a mail using any client, your client (web, desktop, or mobile) connects to the mail server over SMTP and hands over the mail to the mail server to relay to the recipient server. The mail server in turn queues the mail and based on routes established in the setup, it may relay the message to outgoing relay servers who take each mail from the queue, resolve the recipient’s MX server, establish an SMTP connection with that server and deliver the mail.
Mail treated as abuse:
During this transaction, the recipient server does several checks to establish the authenticity of the incoming mail from the sending server. One of these checks is to establish the authenticity and reputation of the sending server’s IP address. If the sending server’s IP address has a bad reputation (is part of one of the RBLs (Resource Blacklists)), the recipient’s server rejects the mail assuming it to be spam.
This is the cause of problem #1 stated above.
Sender Address Forgery:
Another common problem today is Sender Address Forgery. Today, nearly all abusive e-mail messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets diminished and they have to disclaim liability for the abuse or 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.
Sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people’s confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.
This is the cause of problem #2 stated above.
Thus when the recipient server is about to acceptt a mail, it would be nice if it had a way of establishing/connecting the sending server’s IP address with the sender’s domain name (its like a power of attorney by a domain which states that all my mail are sent ONLY by these defined set of servers)
Enter SPF (Sender Policy Framework). The domain owner must specify and publish the IP addresses of the mail servers, which they use to to send mail for their mail domain.
The domain owner publishes this information in an SPF record in the domain’s DNS Zone and when the recipient server is about to accept a mail from an email id, it can verify if the mail is complying with the policy published by the domain owner i.e. the IP from which it originates is one of the listed IPs in the SPF record of the domain.
By using SPF, you reduce rates of email forgery and greatly increase chances of delivery of the mail even if the sender’s IPs are blacklisted in RBLs.
Resources:
Reproduced in part from http://www.openspf.org/Introduction
http://www.zdnet.com/how-does-sender-policy-framework-work-3039149352/