Gmail stats graphic courtesy Google Security Blog

Introduction

One of the major problems with email is email spam. Spammers impersonate your identity to send emails that appear to be sent from your email server. This is a major problem that consumes your time, your bandwidth and often will damage your reputation.

In this article we will discuss SPF – Send Policy Framework. This sounds complicated, but it is not. SPF is a simple DNS resource record that tells the world which email servers are authorized to send email for the domain. It is the responsibility of the receiving email server to verify that the sender is authorized to send emails on behalf of your domain.

You will want to combine SPF with DMARC and DKIM to improve the deliverability of your emails.

Also, read my article: Google Domains – Purchasing a Domain Name

Email Reputation

Often the IP address of the sender’s mail server determines the reputation for emails. As the cloud becomes more and more popular, hosted providers such as G Suite, Gmail, Office 365 and mailing services such as Mailchimp, SendGrid, Pepipost are delivering email for more and more customers. This means that IP addresses mean less and domains become a more important measurement.

A sender’s domain reputation increases over time as email messages are sent. The type (content) of the email you send will affect your score. Developing a good reputation thru best practices is very important. This means no unsolicited emails, not purchasing email lists, requiring customers to opt-in for emails, etc. Mostly common sense practices.

An additional method to increase reputation is to implement policies correctly that others can reference. This includes DNS server SPF, DKIM and DMARC records. These records provide information to mail hosts to better determine if your email is likely spam, forged or phishing.

What is SPF?

From Wikipedia:

Sender Policy Framework (SPF) is an email authentication method designed to detect forged sender addresses in emails (email spoofing), a technique often used in phishing and email spam.

SPF allows the receiver to check that an email claiming to come from a specific domain comes from an IP address authorized by that domain’s administrators. The list of authorized sending hosts and IP addresses for a domain is published in the DNS records for that domain.

Sender Policy Framework is defined in RFC 7208 dated April 2014 as a “proposed standard”.

How does SPF work?

From Global Cyber Alliance:

One limitation of SPF is that the Return-Path header is checked and not the From header. Adding DMARC will verify the From header. Adding DKIM adds header signing and verification.

Should you implement SPF?

Yes. SPF records are not required but are recommended. More and more mail hosts reject email from domains that have no SPF records. The time and cost to implement SPF are minor and the improvements towards reducing email spoofing and spamming are worth it.

SPF records are only a suggestion. Receiving email servers can ignore them or override their actions.

What does an SPF record look like?

For G Suite:

v=spf1 include:_spf.google.com ~all

  • SPF version 1
  • Accept email from IP addresses from a lookup of _spf.google.com
  • Soft fail all others

If you are using G Suite and Mailchimp:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

  • SPF version 1
  • Accept email from IP addresses from a lookup of _spf.google.com
  • Accept email from IP addresses from a lookup of servers.mcsv.net
  • Soft fail all others
For Office 365:

v=spf1 include:spf.protection.outlook.com -all

  • SPF version 1
  • Accept email from IP addresses from a lookup of spf.protection.outlook.com
  • Hard fail all others
For your own email servers:

v=spf1 mx a ~all

  • SPF version 1
  • Accept email from MX records for the domain
  • Access email from the IP addresses the domain resolves to (normally a web server)
  • Soft fail all others
For your own email servers:

v=spf1 ip4:175.175.101.101 -all

  • SPF version 1
  • Accept email from IP address 175.175.101.101
  • Hard fail all others
What’s the difference between ~all and -all

Notice that G Suite uses a tilde character where Office 365 uses a hyphen character for ~all.

The difference between a hyphen and tilde character:

  • - Fail, an IP that matches a mechanism with this qualifier will fail SPF (email should not be accepted).
  • ~ SoftFail, an IP that matches a mechanism with this qualifier will soft fail SPF, so the host should accept the email, but mark it as an SPF failure (email can be accepted, but treated as suspect).

Domain forgery can cause a lot of email bounces. The amount of bounced email notifications, sometimes, can take down a small email server. Using a -all can decrease the amount of bounced email notification messages. However, this is up to the email delivery hosts to control and implement bounced message handling properly.

G Suite recommends using a soft fail: ~all.

SPF record for domains that do not send email

To reduce the risk of spam email pretending to be your domain, use the following TXT record:

v=spf1 -all

Email servers that check your SPF record will know to reject all email from this domain. I suggest also adding a DMARC record:

v=DMARC1; p=reject; aspf=s; adkim=s;

If you want to collect data on spoofing:

v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:dmarc-report@example.com; ruf=mailto:dmarc-report@example.com; fo=0:d;

What TTL value is recommended?

The shorter the TTL (Time-To-Live) the higher the load on your DNS servers. Typically, the IP addresses of email servers do not change often. G Suite recommends one hour (3600 seconds).

SPF Tags

This table lists some common values.

TagDescription
v=spf1The TXT record will always begin with this. This defines the version of SPF being used. Currently SPF version 1 is the only available version.
mxIf this is included, then the incoming mail servers (MX) of the domain are authorized to also send mail for that domain.
a:This part should only be included if there are other systems, other than the mail servers, authorized to send mail for the domain.
include: Everything considered legitimate by a trusted external domain is legitimate for the domain.

SPF Limitations

  • There is no mechanism to determine if an email message was rejected or bounced.
  • If only SPF is used (without DMARC and DKIM) emails can still be forged if more than one domain uses the same email servers (hosting provider).
  • Limit of 10 domain names per record. [EDITOR NOTE: Document this]
  • SPF breaks email forwarding if the forwarding server is not published in the SPF record. For more information: Sender Rewriting Scheme. For this case implement DKIM and DMARC so that mail servers can make better decisions.

Testing your SPF records

There are several tools available. I like to use MX Toolbox. Let’s see what it reports for my test domain.

Go to this link: MX Toolbox for jhanley.dev

MX Toolbox generates a very nice detailed report on my domain SPF settings. Each entry has a nice green check mark with an explanation.

NSLOOKUP

You can use nslookup to view DNS records. For my testing domain:

nslookup -querytype=txt jhanley.dev

Which results in this output:

As an exercise, try nslookup -querytype=txt google.com:

Additional Resources

Special Mention

OPENSPF. This site is a treasure trove of information.

This site is down and has been for a few months. I am including two links. The original site and a web archive link.

 

 

 

Related Posts