We’ve all had our fair share of emails that made us reconsider whether we’re going crazy or the company sending this email had something wrong with breakfast. Emails that shouldn’t hit your inbox in the first place, emails that are clearly spam – maybe even a legitimately looking call-to-action with a phishing link. Don’t start questioning your sanity; this company’s domain might have been spoofed due to the lack of good domain protection.
A significant problem with email is that domain names (@yourbusiness.com) can easily be spoofed. Sending emails on someone else’s behalf isn’t rocket science. Since email is a fairly old system (it’s been around since the ’70s!), many protective measures have been developed over the years. One of these measures is SPF: The Sender Policy Framework.
The Sender Policy Framework (SPF)
An SPF record is a piece of text in the DNS settings of your domain (yourbusiness.com) that protects it from being spoofed (misused by others). Many spam filters and mail servers use an algorithm to mark emails as wanted or unwanted, often based on this record. The Sender Policy Framework tells the receiving mail server (like Gmail) that the domain is used by someone who can do so.
Email without SPF
Email communications happen between two mail servers: yours and the one your recipient uses – the SMTP protocol. Your server hands over the information you want to send to your recipients. However, the problem is that a sender can use any name or address. We could easily fake the sender and say we’re Google, Amazon, or any other big brand, a.k.a. spoofing.
Email with SPF
With the Sender Policy Framework (SPF) in place, the receiving server can check whether the email you send actually comes from you. The SPF record holds a list of IP addresses allowed to be sent on your behalf. If the sender sends the email from an IP address that isn’t on that list, it will not pass the SPF check. Later on, we’ll explain how that works.
Explained by an expert
Email expert Lars Sandbergen from DMARC Advisor tells us in under 4 minutes what SPF is, why it is needed and what it does.
The Sender Policy Framework RFC
How SPF records work is found in RFC7208. This documentation describes how SPF works in communication between two mail servers: Publishing on one side and authorizing on the other. The communication happens mainly during the so-called SMTP transaction, where one mail server (MTA) offers an email to another mail server. During authorization, the receiving mail server checks evaluates, and provides feedback about the sender.
Publishing an SPF record
The sending domain publishes the SPF record, including authorized IP addresses. These addresses are allowed to send emails on behalf of the respective domain. During the email transaction, the names “HELO” and “MAIL FROM” are used. This ‘greeting’ allows the sending mail server to be known to the receiving mail server.
Authorizing the SPF record
According to the RFC, the receiving mail server should (not every receiver does) check for the availability of an SPF record. The two identities (HELO & MAIL FROM) are examined during this check. It then determines whether the sending address can send this email on behalf of those identities. Most receiving mail servers check the identities in chronological order. “HELO” (smtp.yourcompany.com) is a somewhat “easier” identity to verify. If that identity is confirmed and passes authorization, the “MAIL FROM” (info@jouwbedrijf.nl) doesn’t need to be checked. However, if the HELO cannot be verified, the receiving mail server must verify the more complex MAIL FROM.
Evaluating the SPF record
The receiving mail server also determines its following action by evaluating the SPF record. There are seven possible outcomes of this evaluation:
- None: no SPF record or no valid DNS domain was found during the SMTP transaction;
- Neutral: no check could be done on whether the sending IP address is authorized;
- Pass: indicates that the sender is authorized;
- Fail: suggests that the sender is not allowed;
- Soft fail: a mitigated fail because no firm policy could be found in the SPF record;
- Temperror: A temporary connection error to DNS could be fixed in the second attempt.
- Permerror: The domain could not be interpreted correctly. Requires the DNS administrator of the sender to correct the problem.
The evaluation described above is the default evaluation. However, each recipient’s response to a failed SPF check may vary. Some receiving mail servers require having a solid SPF record, whereas others value it way less.
Feedback
When the SPF record has been checked and evaluated by the receiving mail server, an email passes or gets blocked. If it passes, the mail servers will communicate it’s “delivered.” However, when the SPF check fails, the receiving mail server has two options:
- Give a (temporary) error so that the sending mail server knows the message doesn’t need to be sent again (rejection) or whether there is a problem of a temporary nature (“try again later”);
- Let the message pass and therefore give “delivered” feedback – but add a header indicating that it is a suspicious message – a.k.a. the spam flag.
The structure of an SPF record
An SPF record always consists of three types of content: the version, the mechanisms and the qualifier. The ‘version’ is always the same (since there’s only one version available) and is always the first thing to mention in the record. If it is not, the receiving mail server will not recognize the TXT record as an SPF record and will fail the check. The version is always “v=spf1”. Therefore, the SPF record in your DNS starts with:
TXT |v=spf1You can only have one SPF record, as the RFC mentions:
A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record.
Mechanisms in an SPF record
To allow domains & IP addresses to send emails on your behalf, you need to use so-called mechanisms. These define the way you add trusted senders to the list, and how you want to deal with IP addresses that are not on that list. There are two types of mechanisms; basic mechanisms and designated sender mechanisms.
Basic mechanisms
Basic mechanisms are a part of the SPF record, but are not used to authorize IP addresses:
- all: this mechanism closes off the SPF record. It defines what to do with IP addresses that are not mentioned in the SPF record (read more about Qualifiers below). Always put this mechanism at the end of the SPF record!
- include: this mechanism refers to another domain (with an SPF record), but is not ‘part of’ the original SPF record. Though the name ‘include’ suggests otherwise, the SPF record check will for the validity of the included domain separately.
Designated sender mechanisms
Designated sender mechanisms are used to identify and authorize a set of IP addresses to send emails on your domain’s behalf:
- a (records)
- mx (records)
- ip4 (addresses)
- ip6 (addresses)
- ptr (out of use)
A and MX records
The records (a and mx) refer to the respective records of the subsequently specified domains. These records contain IP addresses that the receiving mail server will look up and check. This applies to both the specified domain (yourcompany.com) as well as its subdomains (mail.yourcompany.com):
TXT |v=spf1 a mx yourcompany.comIP-addresses (IPv4 / IPv6)
You can also specify IP addresses and ranges for both IPv4 and IPv6 addresses in an SPF record. With this you grant permission to these addresses to sends emails on your behalf. This methods also saves on the number of lookups (max. 10); the IP addresses that may email on behalf of the domain are already in the record itself.
For IPv4-addresses, e.g.:
TXT | v=spf1 ip4:30.83.248.91For IPv4-ranges, e.g.:
TXT | v=spf1 ip4:30.93.0.1/14For IPv6-addresses, e.g.:
TXT | v=spf1 ip6:2a01:7c8:3:1337::27For IPv6-ranges, e.g.:
TXT | v=spf1 ip6:2a01:7c8:3:1337::27/96Include
The fifth option is to refer to a domain where your SPF record is specified. This is what we did for one of our domains. The SPF record for flowmailer.com refers to: spf.flowmailer.net.
flowmailer.com TXT | v=spf1 include:spf.flowmailer.net ~allreferring to:
spf.flowmailer.net TXT | v=spf1 ip4:185.136.64.128/27 ip4:185.136.65.128/27 ~allCombining mechanisms
It’s possible to combine different mechanisms and include a multitude of IP addresses, pointers and records. The number of lookups is subject to a maximum of ten. A lookup is defined as when another DNS has to be ‘looked up’ to check the SPF record. These are pointers to other domains (includes) and records (a and mx).
A combined (functioning) record could look like this, for example:
TXT | v=spf1 a mx yourcompany.com ip4: 30.93.0.1/14 ip6:2a01:7c8:3:1337::27 include:spf.flowmailer.net ~allQualifiers
To indicate what action the receiving mail server should take, before the all mechanism, specify a character:
~, –, + or ?:
~all, , also called softfail (recommended!). If the sending IP address does not match the IP addresses in the SPF record, the email is accepted but marked as spam.
-all, or hardfail. All messages sent with an unauthorized IP address will be rejected by the receiving mail server. This is not recommended, as you may encounter problems with email forwarding.
+all, which simply accepts all emails. With this, the rest of your SPF record is useless.
?all, here no extra validation is performed, so it has the same effect as +all: all emails from unauthorized servers are allowed. Again, the rest of an SPF record is therefore useless.
Adding your SPF record to your DNS
To get your new SPF record to work, you will have to add the record in your Domain Name System (DNS) settings. You do this (in most cases) as follows:
- Look for the DNS settings of your domain – for providers usually under ‘Product Settings’;
- If your domain does not yet have an SPF record, choose ‘add a record’;
- Select TXT as the record type;
- Select host / target and define it as @ or leave it empty;
- Enter your new SPF record in the text area and check that it starts with “v=spf1”;
- Save your record and you’re done! Now your new SPF record will go live as soon as possible (depending on TTL)
Summarized
Simply put, an SPF record is a collection of IP addresses that are allowed to send emails on your domain’s behalf. These IP addresses are often linked to the email sending software you use – e.g. your CRM, email marketing tool, ERP. With this record, you also tell the receiving mail server their next move when the IP address that is trying to email on your behalf fails the check. When set up correctly, SPF is the first “OG 3” email authentication method to protect your domain from abuse and increase your reputation with inbox providers.
An SPF record always consists of the version, one or more mechanisms and a qualifier. Building an SPF record, the version comes first (v=spf1), the mechanisms to include IP addresses are in the middle, and you close the SPF record with a qualifier (~, –, + or ?) + all.
Though mechanisms are limited in use (max. lookup of 10 & shouldn’t exceed a certain length), these define what IP addresses are allowed to send emails on your behalf. Make sure to keep that list complete and updated regularly!
Need help with your SPF record?
Need help setting up your SPF record or is your SPF record not working properly? Spotler’s experts have years of experience in securely delivering emails and are happy to help! Feel free to contact us.
