How to set up SPF for added email authentication

SPF stands for Sender Policy Framework. According to Wikipedia, SPF is a framework that aids in protecting forged emails from a given domain. It was first introduced in early 2000 but wasn't officially standardized until 2014, with the publication of RFC 7208. In simple terms, SPF provides a way for receiving email servers to validate that email sent to them is legitimate, which cuts down on email SPAM.

SPF is implemented by adding several TXT Domain Name Server (DNS) records for a given domain name sending emails.

Let us look at how redhat.com uses SPF with dig:

$ dig +short redhat.com TXT | grep spf

"v=spf1 ip4:103.23.64.2 ip4:103.23.65.2 ip4:103.23.66.26 ip4:103.23.67.26 ip4:107.21.15.141 ip4:108.177.8.0/21 ip4:13.111.0.0/16 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:148.105.8.0/21 ip4:148.139.0.2 ip4:148.139.1.2 ip4:148.139.2.2 ip4:148.139.3.2 ip" "4:149.72.0.0/16 ip4:149.96.1.26 ip4:149.96.13.2 ip4:149.96.132.2 ip4:149.96.133.2 include:spf1.redhat.com -all"

Look at the TXT record returned. There are four keywords that you need to understand:

• v=spf1
• ip4 - Provides the IPv4 addresses of all the email servers from which the given domain can legitimately send email. The format can be a single IPv4 host or an IPv4 network with a CIDR subnet mask.
• include - Provides additional sub-domains approval to send email on behalf of the parent domain.
• -all - Specifies that no other IPv4 address should be trusted as a valid email sender.

There are three options for all:

• -all - Also known as "dash all," again, means emails sent by IPv4 addresses not specifically listed in the TXT record should be rejected.
• ~all - Also known as "tilde all," means emails sent by IPv4 addresses not specifically listed in the TXT record should probably be flagged as SPAM.
• +all - Also known as "plus all," means emails sent by any and all IPv4 addresses from a given domain be authorized. This is highly discouraged.

When thinking about security, less access is more. Please configure the SPF domain records with legitimate, authorized email servers for sending email. This helps protect that domain from being victimized.

[ You might also like: A sysadmin's guide to configuring an email server ]

How it works

A Red Hat employee sends an email via a Red Hat mail server to a Google Gmail recipient. Google's email protection server layer performs an SPF inquiry via a DNS TXT record lookup against redhat.com DNS. The redhat.com DNS responds with the following TXT record:

"v=spf1 ip4:103.23.64.2 ip4:103.23.65.2 ip4:103.23.66.26 ip4:103.23.67.26 ip4:107.21.15.141 ip4:108.177.8.0/21 ip4:13.111.0.0/16 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:148.105.8.0/21 ip4:148.139.0.2 ip4:148.139.1.2 ip4:148.139.2.2 ip4:148.139.3.2 ip" "4:149.72.0.0/16 ip4:149.96.1.26 ip4:149.96.13.2 ip4:149.96.132.2 ip4:149.96.133.2 include:spf1.redhat.com -all"

The Google SPF inquiry parses the response, looks at the email envelope-sending email server address, and tries to match that against the IPv4 addresses in the list provided. If it matches, Google knows this is a legitimate email sent from an approved Red Hat email server. If the information doesn't match, then it assumes that the email envelope has been forged/altered and blocks or marks it as SPAM to protect the recipient.

How to implement

To create an SPF record for a domain name, you need to provide the following DNS record in your domain's authoritative name server.

example.com. IN TXT “v=spf1 ipv:192.168.100.200 -all”

This record now advertises that legitimate emails will only be sent via the IPv4 address of 192.168.100.200 from the domain example.com. All others should be rejected.

[ Want to test your sysadmin skills? Take a skills assessment today. ] 

Wrap up

SPF is one of three common DNS-based configuration options email administrators have at their disposal. Stay tuned as I introduce Domain-based Message Authentication (DMARC) and DomainKeys Identified Mail (DKIM) configuration options in future blog postings.