Archive for April 29th, 2011
Sender Policy Framework (SPF) is a DNS record that’s used to authenticate who is allowed to send mail appearing to come from a specific domain. It is used to help prevent email spamming and spoofing, and works by making available a list of what domains, mailservers, and IP addresses are authorized to send mail from a domain, and what to do with mail that does not match those rules.
SPF is a DNS text record, and is added to your DNS records for the domain that matches the part after the @ sign in the email address. For example, for @example.com, the SPF TXT record should be added to the example.com domain.
I’m not going to cover every possible SPF setup, simply the ones I use most often and the rationale behind them. You can check the documentation links below my examples if you want to build more elaborate or specific SPF records.
In the below examples, substitute
with your web server’s IP address in dotted-quad format without a space. E.g.
IP:10.1.2.3. You can also specify a CIDR range such as
Allow from the domains IP, it’s listed mailservers, and a specific IP. Soft-fail all others (Messages that return a SOFTFAIL are accepted but tagged). The recommended configuration for most dedicated/VPS web server environments. Used when you send/receive mail at your domain, and software on your domain may send mail out as you, but no other mail server or mail exchanger will send mail as you. Users of shared hosting environments will probably want to ask their web hosting provider for the recommended SPF record to use.
v=spf1 a mx ip4: ~all
Include Google’s SPF records, if you use Google Apps as your domains mail. Add
include:_spf.google.com, similar in rationale to the above, but used if you use Google Apps for email, and your software on your web server may also send mail as you.
v=spf1 a mx ip4: include:_spf.google.com ~all
Fail all mail. Used only if you send no mail. Example: a parked domain or a domain that is not used in email at all.
In all the examples above except for the last, I denote soft-fail (
~all) instead of fail (
-all). This is because you may inadvertently make a mistake or misconfiguration, and soft-failing will not prevent mail from being delivered, it will simply flag it in the email headers. You can also specify neutral (
?all) as an alternative.
Here’s an example email header from Gmail which includes the SPF record’s lookup result. I’ve edited the email address and IP, of course.
Received-SPF: pass (google.com: domain of firstname.lastname@example.org designates IP as permitted sender) client-ip=IP; Authentication-Results: mx.google.com; spf=pass (google.com: domain of email@example.com designates IP as permitted sender) firstname.lastname@example.org
By this example, you can see the SPF record matched and was passed.
SPF records are a good tool for many reasons. They give mail servers the ability to authenticate your email to your domain, which helps keep it out of recipient’s spam folders, and they help prevent others from spoofing your domain in email, which could cause serious trouble.
Also, SPF records do not decide whether or not to accept mail for delivery — they only serve as an authentication mechanism for who is allowed to send mail appearing to come from that domain.
- SPF Project Overview
- The SPF Setup Wizard (Wizard to build SPF records quickly and easily)
- MediaTemple – HOWTO: SPF – All Purpose (Pre-built SPF records for MediaTemple customers)
- Wikipedia – Sender Policy Framework
- SPF Record Testing Tools
- SPF Records – Google Apps Help
Questions, comments, or feedback about the above SPF records or how they’ve been explained? Please share your thoughts in the comments below! Thank you.