Sender Policy Framework or SPF is a technique that the makes falsification of the sender of an e-mail on SMTP is more difficult. So basic thing is, Sender Policy Framework is a way to prevent email spam by detecting its IP address from the header.
How Sender Policy Framework (SPF) works
Sender Policy Framework is in the DNS zone of a domain, it is a resource record named SPF and TXT with information about which computer are allowed to send e-mails for this domain. With this information the receiving servercan verify the identity of the sender. Sender information in always there in the e-mail headers, in case of having a Sender Policy Framework record, most e-mail servers gets them by default.
Sender Policy Framework can thus facilitate the traceability of e-mails to combat spam and aggravation of phishing. Sender Policy Framework, however, only claim to prevent sender address forgery, not to fight, just spam.
Sender Policy Framework needs to be supported only by the receiver system – on the mail transfer protocol (SMTP) will change anything. The publication of Sender Policy Framework records is voluntary for a domain, mail from domains without Sender Policy Framework records are classified by non-negative recipients, although these domains remain inherently vulnerable to such address forgery.
Known issues with Sender Policy Framework
There will be problem with e-mail forwarding if Sender Policy Framework is used. End users generally do not turn on whitelisting as they lack the knowledge of the existence of Sender Policy Framework and the need for whitelisting. Integrating these processes into an existing infrastructure is costly and time taking. Many people want to use their private e-mail addresses from their employers, etc. out of their office. Quite obviously, adding a Sender Policy Framework prevents it. This is painful but a good feature of Sender Policy Framework as no ex-employees can abuse the e-mail system of the company’s domain name.