The Sender Policy Framework (SPF) is an open internet standard and a mighty tool to proactively fight mail spoofing. As the owner of a domain, you can publish IP addresses of authorized senders. Whenever a mail is delivered to a server, it is automatically cross-checked to determine whether the IP address of the sending server is authorized. The technical implementation uses a simple TXT record in the domain's zone on your domain name server (DNS).
Besides the list of authorized IP addresses, the SPF record also contains a custom-defined policy rule. It tells the receiving mail server what to do when the sender IP is not authorized. For example, to discard the email. This is called a “fail” or sometimes “hardfail.” Alternatively, the policy can be set to “softfail,” which tells the receiving mail server that something is fishy but there is the possibility the sender is legitimate, so to flag the email instead of discarding. Some administrators have decided to mark the email, for example, by adding “Possibly Forged Sender” to the subject line and letting the user decide.
So you might think that the basic SPF architecture is the solution for all your spoofing problems? Well, maybe. Our experience shows that there are several pitfalls.
The good news is that the SPF standard is pretty flexible. Instead of only listing IP addresses by hand, you can also link to MX or A records. You can even include other SPF records to reference the provider that is sending those newsletters on behalf of your domain. Of course, each of those will cost the receiving mail server additional DNS queries. For security reasons, the SPF standard limits the amount of allowed DNS queries per mail to 10:
SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the “include” mechanism or the “redirect” modifier. If this number is exceeded during a check, a PermError MUST be returned. The “include”, “a”, “mx”, “ptr”, and “exists” mechanisms as well as the “redirect” modifier do count against this limit.
RFC 4408, sec. 10.1, https://www.ietf.org/rfc/rfc4408.txt
While this limitation makes absolute sense to avoid overloading a DNS server, companies nowadays often have many service providers sending emails on their behalf. Think for a second about your company. Marketing has one newsletter provider, fulfillment emails are sent from another partner, and not to mention all those cloud providers running helpful third party business tools.
SPF Guru addresses this technical limitation by offering an alternative and more flexible way to verify sender authenticity. We evaluate your SPF record, resolve all authorized IP addresses and cache the result in a white-list. When an email is received, the mail server only has to perform an “Is this IP authorized” lookup and our DNS servers are able to answer with a simple “yes” or “no.” Regardless of how many email providers your company operates.
SPF only makes sense when you have a “hardfail” policy, otherwise the receiving mail servers will not discard an email that is spoofed. But switching your policy to hardfail can have severe consequences when your SPF record is incomplete or constantly being revised in a growing firm.
With SPF guru, we ensure that your security requirements and business needs are no longer in conflict by offering a reliable way to know who is sending emails on behalf of your domains and helping you maintain an accurate and complete SPF record.