How to Configure SPFv1: Explained for the Masses
Kent Ickler and Derrick Rauch* //
Sun Protection Factor
Err… wait a second.
Sender Policy Framework
Ladies and Gentlemen of the class of 1997, Wear Sunscreen…I will dispense my advice, now: “
Email “forging” exists in the web today, thanks @ustayready. Sender Policy Framework (SPF) was created with origins back in 2005 (RFC 4408) with more recent version updated in 2014 (RFC 7208) and DKIM and DMARC updates. It attempts to thwart forged emails by providing recipient-mail-servers, a method to determine if the origination of the email was authorized to send mail on behalf of the domain in the FROM field of the email. Recipient-mail servers then had the opportunity to determine if the inbound email should be considered more-likely forgery/phishery or if more-likely legitimate.
If a recipient-mail-server receives email with a FROM address of an SPF authorized server, it has reason to believe its a valid/”good” email.
If a recipient-mail-server receives email with a FROM address of an SPF unauthorized server, it has reason to believe it is an invalid/bad email.
SPF records can also “inform” the recipient-mail-server what to do in case mail is received from an unauthorized mail server. It can continue to deliver the email, mark it for suspicion (increase its risk rating), or outright deny the email. Of course, the SPF record isn’t the golden-rule. The recipient-mail-server can follow whatever methodology it cares to take when considering the weight of SPF records.
The Marketing Spiel:
So Marketeers often struggle with this. It’s a SendGrid, MailGun, MailChimp, ect dilema. They bought this fancy new marketing email solicit tool but everyone keeps marking their campaign emails as spam! If your Marketing group didn’t take their time to ensure their SPF records for their FROM domain is accurate, emails being received could more easily be considered spam/malicious and sent to the Spam box, ever to be forgotten.
Forward Thinking:
Sender Policy Framework isn’t dying, but it does have new brotherly love in the anti-spam and the anti-phisery departments. DKIM and DMARC are newer frameworks that extend the validation that SPF started back in the day. Together they attempt to build a network of trust between domain-ownership and recipient-mail-servers. Check out future blog posts for discussion on DMARC and DKIM.
Domain Name Server Record:
The SPF record that “authorizes” a mail-server/relay to be delivering emails is a DNS TXT record that must be entered on the Name Server as designated by the registrar. Because this implies domain ownership, it allows the owner of a domain to tell recipients if mail received with their domain in the FROM field was delivered by a mail server they expected.
The DNS record we discuss below must be created on the domain’s name server as defined by NS record on the domain’s registrar.
Syntaxing:
There are lots of tools to help you build SPF records,but you still need to know what’s going on. SPF records are read by SMTP-Recipients left-to-right. Upon first match, the record analysis stops with the configured result.
DNS record type = TXT
Host = @ (whatever your primary TLD is, or whatever domain you’re trying to protect).
Value= [SYNTAX]!!
The value key is where the meat of the record is so lets take a look:
“v=spf1 “ [Mechanism-Action] [Mechanism-Who] [Mechanism-Action] ]Mechanism-Who]…
Mechanism-Action:
The action parameter tells the recipient mail server what to do. Its syntax is below:
+ Pass email: SPF record designates host is authorized (mail accepted) - Fail email: SPF Record designates host is not authorized (mail rejected) ~ SoftFail: SPF Record designates host is not authorized but, meh, maybe (mark/increase-risk). ? Neutral: SPF Record designates that it has no idea, double-meh. (mail acepted_ Other action/reults
Mechanism-Who
There are a lot of options here:
all Everserver, everywhere ip4:<IP Address of mail server> Ip4:<ip address>/CIDR-Style ip6:<IP6 address> ip6:<ip address>/CIDR-Style a:[domain] Include all A-records of [x-domain] a:[domain]/CIDR Include the /CIDR network of all a-records of [xdomain] a Include all a records of this domain. a/CIDR Include the /CIDR network of all a-records of this domain mx Include the mx-records of this domain mx/CIDR I nclude the /CIDR network of all mx-records of this domain mx:[domain] Include all mx-records of [x-domain] mx:[domain]/CIDR Include the /CIDR network of all mx-records of [xdomain[ ptr Include the IP of the ptr record of this domain ptr:[domain] Include the IP of the ptr record of [x-domain] exists:[domain] YES/NO trigger. If an A record exists = Pass redirect :[domain] Replace this entire SPF record with the SPF record of [domain] include:[domain] Include the SPF records of [domain]. Match = pass, no match=fail. This type record is used in most cases for large mail providers like Google, Office, ect. This is also commonly used for mail-relays like SendGrid, MailGun, etc.
The include: is a trust mechanism. It allows you to proxy trust of who is authorized to send email from your domain/organization onto the SPF records of another domain/organization who you acknowledge to be responsible for sending your email. These organizations often blanket their SPF records to cover all of their possible mail servers.
Examples:
v=spf1 +mx -all Accept email from this domains mx record, reject from anywhere else. v=spf1 +a:AnotherDomain.com ?a:google.com -all Accept email from a-records of AnotherDomain.com, meh on a-records of Google.com, but reject everything else. v=spf1 exists:AnotherDomain.com -all Accept email if an a-record exists for AnotherDomain.com, but reject if it doesn’t. v=spf1 -all Reject email from this domain, regardless of who sends it. v=spf1 include:mailgun.com include:sendgrid.com -all Follow rules in the SPF-Record for mailgun.com and sendgrid.com, reject all others. v=spf1 redirect=AnotherDomain.com Follow only the rules in the SPF-Record of AnotherDomain.com
Marketeering, again:
Back to that Marketing bit, what are MailChimp, MailGun, and SendGrid doing?
Interestingly there’s something to be said here if you’re using a mail-relay or mass-mailing service. The email *can* be considered authorized and you can break-through spam boxes. But, the red-teamer inside me would have to ask…
Can a third party just create an account over at a third party I’ve trusted and send email on my behalf without my explicit approval?
Well, Yes… and no.
These services can send email on your behalf if you configure your SPF record to authorize their mail server. They each do some diligence to ensure that a third party cannot send email with your from address. They do this by forcing users to validate their FROM domains prior to sending email on behalf of that domain. Each service does this differently. Some make dns records on their domains that should be included as +a:yourdomain.mailrelayservice.com which can provide you some reassurance. Ultimately though, you need to trust your mail servers, and if you feel you can’t do that, well… its a tough world and paralyzing paranoia will set in.
For more information on SPF Records and the like, check out the links below. Also stay tuned for our upcoming blogs on DKIM (RFC 7372) and DMARC (RFC 7489)!
SPF Record Generators
There are platforms out there that can help build SPF records to fit your specific needs. Most work very similar to each-other… some even want money$$! I wouldn’t suggest paying for helping you create an SPF record, but as always, be careful when using free services. That said, MXToolbox has been in my SysAdmin and Blue-Team toolbox for years and hasn’t let me down.
Build SPF Online: https://mxtoolbox.com/SPFRecordGenerator.aspx
Links
Open Sender Policy Framework: http://www.openspf.org/Project_Overview
Build SPF Online: https://mxtoolbox.com/SPFRecordGenerator.aspx
SPF V1: RFC 7208 (obs 4408, 6652) https://tools.ietf.org/rfc/rfc7208.txt
SPF V1: RFC 6652 (obs by RFC-7208) https://tools.ietf.org/html/rfc6652
SPF V1: RFC 4408 (obs by RFC-7208) (2006) https://tools.ietf.org/html/rfc4408
https://www.ietf.org/rfc/rfc4408.txt
Upcoming Blogs Reading: DKIM, DMARC!
Domain-Based Message Authentication, Reporting, and Conformaice: https://dmarc.org/
SPF V1: RFC 7960 – Interoperability of DMARC https://tools.ietf.org/rfc/rfc7960.txt
SPF V1: RFC 7489 – DMARC https://tools.ietf.org/rfc/rfc7489.txt
SPF V1: RFC 7372 -DKIM (updated 7208) https://tools.ietf.org/rfc/rfc7372.txt
But trust me on the Sunscreen . “
________
*Kent & Derrick are part of our sysadmin team – what would we do without them?
Want to learn more mad skills from the person who wrote this blog?
Check out this class from Kent and Jordan:
