GreenviewData
The Sender Policy Framework ("SPF") is a powerful tool for fighting dangerous email spoofing. Learn about SPF's benefits, limitations and drawbacks, along with some practical tips for email senders and recipients.
The protocol used to transmit email across servers on the Internet is called "SMTP" (Simple Mail Transfer Protocol). SMTP was never designed for proper authentication. In fact, if you look at the RFCs (821, 2821, 3461, etc.) you'll notice the conspicuous absence of authentication.
When one mail server (the "client") passes an email to the next server, SMTP requires the "client" to identify the sender's email address using a "Mail From:" command. However, because the sender can easily provide a fake "From" address (called "spoofing"), there is no way for the recipient's server (only using SMTP) to verify that the email is actually from the alleged sender.
SPF adds a layer of authentication to email transmission. Some of the information in email headers, such as the original sender's IP address, cannot easily be spoofed. SPF lets the owner of an email domain (e.g., @example.com) can publish a list of valid "senders" for that domain. The list can include IP addresses, PTR records, A records, and even another domain's SPF records. To authenticate an email, the recipient's server checks published SPF records for the alleged sender's domain to see if they match information in the header of the email. If there is a match, the SPF check passes, otherwise it fails.
Here's how SPF works. If the receiving server supports SPF, it will then query the domain's SPF records to determine whether or not the client is "authentic". Antispam or other software on the recipient's server can then determine what to do with the email, such as reject it, modify the subject with a warning, delete it, etc.
SPF Example
The owner of the email domain "example.com" has published the following SPF record:
v=spf1 ip4:192.168.0.1/16 -all
That means any email claiming to be from anyone at example.com must be sent from a server with an IP address between 192.168.0.1 and 192.168.255.255. If a spammer tries to send an email claiming to be from "support@example.com" but the IP address in the email header is 10.0.0.25 (which is not in the allowed ranges), an SPF check by the receiving server will fail.
There are many options for allowing traffic besides by IP address. You can allow traffic based on the connecting server's PTR record (often called "Reverse DNS"), if the A record the client claims to be matches (in the HELO/EHLO statement), or even by including someone else's entire SPF record.