We’ve put together a short overview video about SPF:
This video is part of a larger video series on all things DMARC.
The transcript follows:
This video presents an overview of SPF.
SPF – which stands for Sender Policy Framework – is a free technology that is used to link a piece of email back to a domain.
SPF plays a large role in addressing a flaw that has plagued email since the beginning. The flaw is: it’s very difficult to identify legitimate email from fake email.
Due to the size, complexity, and depth of email’s installed base… which is used everywhere all the time by pretty much everyone… making email easy to identify is a major undertaking. The DMARC technical framework was designed to meet this challenge, and SPF is one of two ways that DMARC uses to try to link a piece of email back to a domain.
To use SPF, the administrator of an email domain publishes a list of senders that are allowed to send email on behalf of the domain. When a sender tries to hand-off email to an email server for delivery, the email server checks to see if the sender is on domain’s list of allowed senders. If so, then a link has been established between the piece of email and the email domain.
If not, then the server has to continue processing the email as usual without this link, as any number of things could be going on. The email might be real, but the list of senders might not be accurate. Real email might have been forwarded which means the email could have come from anywhere and therefore the list of allowed senders doesn’t help too much. OR, the email is fake and unwanted. Too many possible outcomes means that it’s difficult to attach meaning to the absence of the link that SPF can provide.
This is about as much as can be said about what SPF does without going into how it actually works.
SPF is implemented as text-based resources that are published in the Domain Name System. The DNS (as it’s universally referred to as) is the massively distributed global database where people and computers go to when they want answers to questions like “where can I find the servers that are responsible for services like websites and email for dmarcian.com?”. You can query dmarcian.com using the DNS and you’ll get back answers that have been put in place by the operators of dmarcian.com.
In the same way, you can use the DNS to get the text resources for dmarcian.com, and one of those text resources might be an SPF record. Because this video is only an overview of SPF, we won’t get into the syntax of SPF records. Suffice it to say that domain operators can publish a list of senders that are authorized to send email on behalf of the domain.
With the authorized list in place, it’s now necessary to understand what part of a piece of email is checked by SPF. Quite a few moving parts are involved in the delivery of email, and dmarcian has published short videos and other resources to make this knowledge accessible. The thing that SPF checks is first seen during the back-and-forth communication that goes on when servers are passing email between themselves. This back-and-forth is known as the SMTP conversation. One part of the conversation is when the server that is trying to hand-off the email tells the other server “this email is coming from the email address of… let’s say…”support@dmarcian.com”.
This bit of dialogue is known as the MAIL FROM command, and the address of the MAIL FROM command is what SPF looks at. If this address isn’t present — as can happen if the email is a special kind of email known as a Delivery Status Notification — then SPF falls back to checking the hostname that the sending server introduced itself as when the SMTP conversation first began. For the vast majority of the time, though, the address found in the MAIL FROM command is what is checked by SPF.
Just to keep things interesting and to give a nod to email’s rich history and massive footprint, the thing SPF checks is known by quite a few other names. The bounce address (because it’s where bounce messages are supposed to go), the envelope address (because, much like a piece of postal mail, the address is on the outside of the content of the email), the Return-Path (because the address gets copied by the receiving email server into the email itself as the “Return-Path” header), and, when precision is required, as the RFC5321.mailfrom field.
Whatever we call it, the receiving server inspects it, extracts the domain from the email address, and then uses the DNS to query for text resources related to the domain. The text resources are then inspected to see if any of them are SPF records. If one is found, the receiving server will then check to see if the sender is listed as being authorized by the SPF record.
The link that SPF establishes between a domain and a piece of email is then used as input into things like anti-spam scanning, and more importantly, as input into DMARC-based checks.
Whether or not a link is identified, the result of the SPF check is inserted into the email as part of the “Authentication-Results” header, and less commonly as the “Received-SPF” header.
To conclude, SPF is relatively simple and has been in use for quite a few years. SPF’s utility has increased significantly since the advent of DMARC, as now domain owners have access to visibility into how their domain is being used that is in turn used to tune the accuracy of SPF records.
Hopefully, this short overview provided insight into how SPF works and how it’s ability to create a link between a domain and a piece of email is important in the ongoing effort to make email easy to identify.
To get started with DMARC, visit dmarcian.com.
Questions? contact support@dmarcian.com
Social? dmarcian is on Linked-in, G+, twitter, and maybe more.
Thank you for watching!
