It was August 1982 when E.T. the Extra-Terrestrial closed off its eighth record-setting weekend, grossing over $10M – a record amount. The most popular home computer was the Commodore 64. Also, that month, the late Jon Postel published the standard for internet email, known as RFC821.

In 1982, each internet user’s email address, telephone number, and mailing address was published in a thin book called the ARPANET Directory. If you got an email from Jon Postel or anyone else, you could trust it came from them. And if you weren’t sure, you could just take out the ARPANET Directory, give them a call, and verify it yourself.

On today’s internet, how can we be sure that someone is whom they say they are when we receive an email message from them? Sender Policy Framework (SPF) helps to address this problem of “sender authentication,” by allowing domain name owners to specify a list of valid locations from which their email can originate. Using SPF with your domain can help you achieve better email delivery by giving receivers some confidence that the message they received has come from a trustworthy place, weeding out some forms of impersonation that might otherwise make your email less trustworthy.

What is an SPF record?

Domain owners publish SPF information in the Domain Name System (DNS) – a globe-spanning database of internet information – in something called an SPF record. Boiled down, an SPF record specifies in computer-readable form a set of rules that email receivers can use to verify that an email sent from your domain originated from a server that is authorized to send on behalf of your domain. In its simplest form, an SPF record can just be a list of IP addresses. SPF records also allow for the inclusion of other SPF records – for example, to incorporate a large list of IP addresses for a service like Google Workspace or Microsoft 365. You can even use fancy macros to write little programs that automate more complex address matching.

Whether your SPF record is simple or complex, the core concept to understand is that SPF allows the email receiver to verify whether an email coming from your domain was sent by a server that you authorized to send on your behalf. If a receiver gets an email from some other server, then the receiver can apply a higher degree of scrutiny on that email message, or block it entirely.

Why you should add an SPF record to your domain

While SPF has its limitations, research shows that email delivery is better when an SPF record is associated with your domain. Email receivers have a tough job sorting good emails from bad emails. SPF weeds out a whole category of address spoofing, letting receivers focus their filtering efforts on other things like message content and IP reputation. Having one less thing to worry about makes it more likely that your message will be routed to the inbox, rather than the junk folder.

What’s next?

While SPF is an important, if not vital, part of improving your email deliverability, it’s not the end of the road. SPF communicates only very limited information about your domain: the list of places from which your email can validly originate. It does not specify what you want receivers to do if they get an email from somewhere else on the internet. Thus, if you only publish an SPF record, it will be entirely up to the email receiver as to whether they deliver or block messages that come from places not authorized by your SPF record.

To complete the email authentication posture for your domain, you also need to use Domain-based Message Authentication, Reporting, and Conformance (DMARC). Handily, we have written a guide to teach you more about DMARC and why it’s so important.