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 Records

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., 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.

Be careful when editing your SPF records or changing service providers, as SPF can block legitimate email if the sender's SPF records are not properly configured. Also, make sure all of your mail servers are accounted for and that the TTL (Time To Live) on the SPF record is set to the smallest possible value until you're sure the update is successful.

Even if your records are correct, SPF can cause a false positive if the sender is using their home instead of work computer. So, we recommend setting your antispam system to "soft fail" SPF failure (like modifying the subject with a warning) and letting the message continue on through spam filtering, instead of rejecting or deleting the message.

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 "" has published the following SPF record:

v=spf1 ip4: -all

That means any email claiming to be from anyone at must be sent from a server with an IP address between and If a spammer tries to send an email claiming to be from "" but the IP address in the email header is (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.

More Info

  • If you're using SpamStopsHere or our other hosted email products, or just have general questions about how to configure SPF, please feel free to call our support department any time, 24/7/365 and we'll be happy to help.