Sender Policy Framework (SPF): A Layer of Protection in Email Infrastructure Luke Martinez April 24, 2015 Best Practices // SUMMARIES ?> When email is sent from one server to another, simple mail transfer protocol (SMTP) is used to get a message from the sender to the receiver. As an SMTP service, SendGrid facilitates this process. One security weakness in the infrastructure of email is the ability of any sender or host to identify themselves, and their email, as any domain that they wish. This makes it difficult for receivers to trust that a message is actually from who it says it’s from. It also makes senders uneasy knowing anyone out there can send mail from their domain and potentially tarnish their brand’s reputation. The problem this creates is a diminishing trust in email as a viable form of communication. Part of the solution is the Sender Policy Framework (SPF) record that’s stored in a txt record in the DNS. What is an SPF Record? An SPF record is a short line of text that the administrator of a domain adds to their txt record. The txt record is stored in the DNS (domain name system) alongside their A, PTR, and MX records. An SPF record looks something like this: “v=spf1 ip4:184.108.40.206 include:example.com -all” What does that line of text actually do? The above line of text is used to tell the receiving SMTP server which hosts are allowed to send mail from a given domain. The SPF record is usually checked very early in the SMTP conversation, well before the body of the message has been transmitted. When an attempt is made to send a message, a TCP connection is opened between the sender and the receiving server. Once the connection is established, a HELO command is issued, which essentially tells the receiving server which domain is trying to send it mail. This is followed by a MAIL FROM command that tells the receiving server what email address the message is coming from. The domain found in the MAIL FROM (also known as the envelope from and return path) command is the domain used for the SPF record check. So suppose a message has been received, and the MAIL FROM address is firstname.lastname@example.org. The receiving server will check the public DNS records for example.com and look for a TXT record that begins with v=spf1. If there is no TXT record that begins with v=spf1, authentication will pass. If there is more than one TXT record that beings with v=spf1, an error may occur. Assume one is found, and it looks like our example from before: “v=spf1 ip4:220.127.116.11 include:example.com -all” The receiving server will now check to see if the IP address of the SMTP client trying to send the message is included in the SPF record. If the IP address is listed, the message will pass SPF authentication. The Nitty-Gritty: Breaking down each piece of the SPF record An SPF record is made up of various mechanisms, including: INCLUDE – Always followed by a domain name. When the receiving server comes across an include mechanism, the SPF record for that domain is checked. If the senders’ IP shows up in that record, the mail is authenticated and the SPF check is over. If it isn’t found, the SPF check moves on to the next mechanism. A – Also followed by a domain name. However in this case, the SPF simply checks for IP addresses associated with that domain. If it matches the sender’s IP, it passes, and the SPF check stops. If not, it moves on to the next mechanism. MX – Similar to “A.” It is always followed by a domain name. If the domain listed resolves to the sending client’s IP address, authentication passes, and the SPF check is done. If not, it moves on to the next mechanism. IP4 and IP6 – Always followed by a specific IP address or CIDR range. If the sending client’s IP is listed after any IP4 or IP6 mechanism, authentication will pass and the SPF check is done. If not, it moves on to the next mechanism. PTR – Should never be included in SPF records. For some technical reasons, they are prone to errors, and cost a lot of memory and bandwidth for receiving servers to resolve. Some servers will fail an SPF authentication based on the presence of a PTR mechanism. REDIRECT – while technically a modifier, not a mechanism, this allows the administrator of a domain to point a domain to another domain’s SPF record. If the REDIRECT function is used, no other mechanisms can be included in the SPF record, including the “all” mechanism. Sample redirect record: “v=spf1 redirect:example.com“ The “INCLUDE,” “A,” “MX,” “PTR,” “EXISTS,” and “REDIRECT” mechanisms all require DNS lookups, so there can be no more than 10 of these. This seems simple enough, but this also includes nested DNS lookups, meaning an “INCLUDE” that leads to another SPF record that has two more “INCLUDE” mechanisms would count as three DNS lookups. They add up fast! What about SendGrid customers? Most of our senders have set up a CNAME that points their sending domain to sendgrid.net. This means the receiving server sees the CNAME pointing to sendgrid.net, and checks that SPF record instead. So do not be surprised if most of the SPF records you query are identical. How do I check my SPF record? Copy the Return-Path domain into the search field at: http://www.dmarcian.com/spf-survey/ This tool will let you know if there are any errors present in the SPF record associated with the domain. Even if there are no errors, send yourself a test message and check the “Authentication-Results” header. If you see anything other than “pass,” the sender could have some infrastructure or SPF problems that are worth looking into. Visit the SendGrid Support Center to learn more about SPF and other steps you can take to protect and improve your sending reputation.