How to Set Up Sender Policy Framework (SPF): the Complete Guide

SPF

Sender Policy Framework (SPF) plays an important role in modern-day email authentication, along with DMARC and DKIM. It helps prevent emails from unauthorized senders from landing in the inbox.

We are going to present a comprehensive guide to SPF in this article. We will cover the various concepts of SPF, how it works, hands-on setup instructions in typical scenarios, and more. You will be able to implement SPF within your organization based on this SPF guide.

What is Sender Policy Framework (SPF)

Sender Policy Framework (SPF) is an email authentication mechanism which allows only authorized senders to send on behalf of a domain, and prevents all unauthorized users from doing so. SPF enables the receiving email server to check that an email claiming to come from a specific domain indeed comes from an IP address authorized by that domain's administrator.

SPF is defined in RFC 7208, and more information can be found at www.open-spf.org.

History of SPF

The concept of SPF was first mentioned in 2000. Later, proposals like "Reverse MX" (RMX) by Hadmut Danisch, and "Designated Mailer Protocol" (DMP) by Gordon Fecyk were submitted to the IETF Anti-Spam Research Group (ASRG).

In 2003, Meng Weng Wong merged the RMX and DMP specifications to form what ultimately became SPF.

In early 2004, the IETF tried to use SPF and Microsoft's CallerID proposal as the basis for what is now known as Sender ID; but it went nowhere due to technical and licensing conflicts. The community then returned to the original version of SPF. In 2006, the SPF RFC was published as experimental RFC 4408.

In 2014 IETF published SPF as a "proposed standard" in RFC 7208.

Why SPF

Email was not designed to be a secure communication platform - anyone can send emails that appear to have originated from any particular domain. This allows cybercriminals to fraudulently obtain the recipient's sensitive information like credit card details and/or password.

SPF was designed to specifically address this issue: when SPF is correctly implemented on a domain, an SPF-compatible email service provider will check any incoming email message to see if it originates from the specified list of hosts allowed to send emails on behalf of the domain. If it's the case, the email is said to be SPF authenticated and will land in the inbox; otherwise, the email is subject to other types of checks and might end up quarantined or rejected, depending on your DMARC settings.

Benefits of SPF

SPF provides a mechanism to authenticate email senders - this ensures that senders outside the specified whitelist are not permitted to send emails for the domain. This eliminates a wide array of spoofing attacks.

In short:

  • without SPF: anyone can send emails for the domain;
  • with SPF: only hosts specified on the whitelist can send emails for the domain.

What SPF doesn't do

There are 2 types of From addresses in email: the envelope From address and the header From address. SPF only authenticates the envelope From address, while still leaving the header From address unchecked. DMARC introduces the concept of "SPF identifier alignment" to address this issue.

For more information on this topic, refer to: From addresses in email.

SPF breaks when the email goes through an indirect mail flow, like when it's forwarded. Since the intermediate host's IP address is different than the originating one's, and it might not be on the whitelist, the email can fail SPF authentication on the destination host. Fortunately, a relative new protocol called authenticated received chain (ARC) addresses this issue: What is authenticated received chain (ARC). ARC preserves the SPF authentication result and passes it to downstream hops so that the terminal host can pick it up.

Finally, SPF lacks reporting/feedback capabilities. This makes it hard to implement and maintain.

SPF VS DKIM VS DMARC

Modern email authentication typically involves major players including DKIM and DMARC, in addition to SPF. Together, they offer complete anti-spoofing protection for business email, which minimizes the risks of email spoofing attacks, when implemented properly.

DKIM stands for DomainKeys Identified Mail. It is an email authentication method designed to detect forged header fields and content in emails. DKIM enables the receiver to check if email headers and content have been altered in transit. For further information, refer to: What is DKIM.

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. It is a way to determine whether an email message is actually from the sender or not. It builds on SPF and DKIM, and adds domain alignment checking and reporting capabilities to designated recipients. For further information, refer to: What is DMARC.

As described above, SPF, DKIM, and DMARC serve different purposes in email authentication. Meanwhile, they provide complete protection for email when working together. To sum it up: SPF authenticates email senders; DKIM ensures email headers and content have not been tampered with; and DMARC authenticates email messages based on the outcomes of SPF and DKIM authentication.

While DMARCLY uses all of SPF, DKIM and DMARC, one can start from a partial implementation like SPF and DMARC, then move on to ultimately achieve a full SPF, DKIM, and DMARC implementation.

How SPF works: SPF explained

In order for SPF to work, the domain administrator needs to collaborate with the email service provider. On the domain admin side, he publishes an SPF record in the DNS specifying the whitelist of senders, i.e., which hosts are allowed to send on behalf of that domain; enforcement occurs on the email service provider side: for each incoming email, it fetches the SPF record from the DNS and checks if the sender is on the list.

Consider this scenario:

  • your business domain is business.com; you will send emails to your employees and customers from [email protected];
  • your email delivery host, which sends the email for you, has an IP address of 192.168.0.1;
  • some attacker uses a scam email host at IP address 1.2.3.4 to try to send spoofed emails.

When an email delivery service connects to the email server serving up the recipient's mailbox:

  • the email server extracts the domain name from the envelope from address; in this case, it's business.com;
  • the email server checks the connecting host's IP address to see if it's listed in business.com's SPF record published in the DNS. If the IP address is listed, the SPF check passes, otherwise not.

For example, let's say your SPF record looks like this:

v=spf1 ip4:192.168.0.1 -all

it means only emails from IP address 192.168.0.1 can pass an SPF check, while all emails from any IP address other than 192.168.0.1 will fail. Therefore, no email from the scam host at IP address of 1.2.3.4 will ever pass an SPF check.

Think of the SPF record as a whitelist of legitimate IP addresses, and only when an incoming email is from one of the IP addresses, SPF gives the green light. No other hosts are able to send emails using your domain. The SPF authentication result is then used for DMARC authentication later.

If you are using Gmail, it's easy to view whether SPF check passes or fails. Simply log in to Web Gmail, click the message in question, and use the "Show original" feature to examine the details of an email message. One example message is shown below:

In the above example, the message has passed the SPF check, as highlighted.

What is an SPF TXT record

An SPF record is a Sender Policy Framework record, of TXT resource record type, published in the DNS, on a specified domain. It's whole purpose is to specify a list of allowed senders on behalf of the domain.

Note that there used to be an SPF resource record type, but that was deprecated in 2014. An SPF record must be published as a TXT record in the DNS.

An SPF record is published by the domain administrator and is enforced by email service providers.

SPF TXT record syntax

Loosely speaking, every SPF record starts with a version number being v=spf1, followed by a group of mechanisms with optional qualifiers and modifiers. Together, SPF mechanisms, qualifiers, and modifiers enable a flexible way to define a list of IP addresses.

SPF mechanisms

A mechanism is a way to specify a range of IP addresses. Eight mechanisms are defined:

  • IP4 : If the sender is in a given IPv4 address range, match;
  • IP6: If the sender is in a given IPv6 address range, match:
  • A: If the domain name has an address record (A or AAAA) that can be resolved to the sender's address, it will match;
  • MX: If the domain name has an MX record resolving to the sender's address, it will match (i.e. the mail comes from one of the domain's incoming mail hosts);
  • PTR: If the domain name (PTR record) for the client's address is in the given domain and that domain name resolves to the client's address (forward-confirmed reverse DNS), match. This mechanism is deprecated and should no longer be used;
  • EXISTS: If the given domain name resolves to any address, match (no matter the address it resolves to). This is rarely used. Along with the SPF macro language it offers more complex matches like DNSBL-queries;
  • INCLUDE: References the policy of another domain. If that domain's policy passes, this mechanism passes. However, if the included policy fails, processing continues. To fully delegate to another domain's policy, the redirect extension must be used;
  • ALL: Matches always; used for a default result like -all for all IPs not matched by prior mechanisms.

SPF qualifiers

A qualifier specifies the result of a mechanism evaluation. Each qualifier can be combined with any of the mechanisms described above.

  • + for PASS, i.e., the SPF check passes. This can be omitted; e.g., +mx is the same as mx;
  • ? for a NEUTRAL result interpreted like NONE (no policy);
  • ~ (tilde) for SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged;
  • - for FAIL, i.e., the SPF check fails.

SPF modifiers

There are two widely deployed modifiers:

  • exp=some.example.com gives the name of a domain with a DNS TXT record (interpreted using SPF's macro language) to get an explanation for FAIL results. Rarely used.
  • redirect=some.example.com can be used instead of the all mechanism to link to the policy record of another domain.
  • SPF modifiers allow for future extensions to the framework.

Note that redirect works in a different way than include:

  • include is a mechanism, and if it fails validation, the next mechanism in the same SPF record will be checked;
  • redirect is a modifier, and the result is the entirely based on the evaluation of the specified domain's SPF record.

SPF record examples

Here is a typical SPF record:

v=spf1 a mx include:_spf.example.com -all

This record allows the following IP addresses to send emails on behalf of your domain business.com:

  • if business.com has an address record (A or AAAA) that can be resolved, the resolved value is allowed (the a mechanism);
  • if business.com has an MX record that can be resolved, the resolved value is allowed (the mx mechanism);
  • any IP address passing SPF authentication using another domain's SPF record at _spf.example.com, is allowed (the include:_spf.example.com mechanism); Note that if you use 3rd-party email delivery services, they usually ask you to add their SPF list to your SPF record using the include mechanism. For example, SendGrid will ask you to add include:sendgrid.net to your SPF record, so that email messages sent from SendGrid will pass SPF authentication.

A special SPF record that prevents any email from being sent on behalf of a domain looks like this:

v=spf1 -all

This record dictates that no IP address be authorized to send emails for the domain.

You should publish the SPF record on domains that are not supposed to send any emails, including parked domains. Otherwise they are wide open to spoofing attack, and will ultimately suffer deteriorated domain reputation and email deliverability, should you decide to use it to send emails later.

Remember: you must include all IPs that will send emails for your business; otherwise, emails sent from some of the IPs will fail SPF authentication.

How to generate/create an SPF record

You can generate an SPF record in 2 ways: manually or by using a tool like DMARCLY's SPF record generator.

If you create an SPF record manually, you can start from the v=spf1 part, then add all the legitimate senders in your email streams to the record, finally append -all to complete the record.

Alternatively, you can use DMARCLY's SPF record generator to create it. See the next section.

SPF record generator/creator

Using the SPF record generator, you simply fill in the settings for the record, like legitimate senders, and hit the Generate SPF Record button, an SPF record is generated for you. This is less error-prone and is preferred.

All-in-one DMARC/DKIM/SPF wizard

If you are implementing SPF within a larger context including DKIM and DMARC, you can also consider using DMARCLY's all-in-one DMARC/DKIM/SPF wizard. This wizard provides end-to-end guidance on how to implement SPF, DKIM, and DMARC in a row to provide complete protection against email spoofing.

Check it out at: DMARC/DKIM/SPF wizard.

How to add/publish an SPF record in the DNS

Once you've created the SPF record, you need to publish it to the DNS before the receiving email server can pick it up. Publishing an SPF record is a matter of creating a TXT record on your domain.

Let's assume you are using GoDaddy as your domain hosting service. If you are using another domain hosting service, the UI should be similar.

Here are the steps:

  • Log in to GoDaddy. Click the domain in question, then click the DNS button.

  • If you've never created an SPF record on the domain before, click the Add button under the Records section.

  • Otherwise you already have an existing SPF record, edit it instead. To check if there is any SPF record, try to find a TXT record with a value starting with v=spf1.

  • Select TXT for the Type drop-down menu. Enter @ for the Host field. Enter the SPF record as the TXT Value. Then click the Save button.

Now you have published the SPF record. Note that if you check the newly published SPF record, it might take up to 1 hour before it appears in whatever tool you use to check it, due to DNS propagation.

SPF DNS lookup limit

Each time an email message hits the email service host, the host looks up in the DNS to perform an SPF check. Care has been taken to prevent this from turning into a Denial of Service (DoS) attack.

The SPF specification imposes that the number of mechanisms and modifiers that do DNS lookups must not exceed ten per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. If this number is exceeded during a check, a PermError is returned.

The include, a, mx, ptr, and exists mechanisms as well as the redirect modifier do count against this limit. The all, ip4, and ip6 mechanisms do not require DNS lookups and therefore do not count against this limit. The exp modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated.

For example, let's take a look at google.com's SPF record:

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

the include mechanism in this record count 1 against the limit. Next is _spf.google.com's SPF record:

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

the 3 include mechanisms in this record count 3 against the limit. All of the records below _netblocks.google.com _netblocks2.google.com _netblocks3.google.com resolve to a flat list of IP addresses. So none of them counts against the limit.

Therefore, the total number of mechanisms and modifiers that do DNS lookups in google.com's SPF record is 4 (1+3).

You can verify the above SPF record check result by using the SPF record checker on google.com.

How to check/validate/test an SPF record

At times, you need to check if your SPF record is correctly published. Like creating an SPF record, you can check it either manually or by using DMARCLY's SPF record checker.

The next section describes how to use DMARCLY's SPF record checker to check your SPF record.

SPF record checkers/validators/testers

To check the SPF record on your domain, go to SPF record checker. Simply enter the domain in question, and it will fetch the SPF record (if any) from the DNS. After the record is returned, it:

  • checks if the SPF record syntax is correct;
  • makes sure the number of mechanisms and modifiers that do DNS lookups does not exceed ten;
  • "flattens" the returned SPF record into a list of plain IP addresses, so that you can check them one by one, in case it's necessary. This is helpful when you need to track down some gnarly SPF issues.

Here is an SPF record check example:

As can be seen from above, the SPF record test shows that the SPF setup on domain dmarcly.com is correct.

FAQs

What is the SPF record type used by some DNS service providers?

The use of SPF resource record type that was formerly supported was discontinued in 2014. SPF records MUST now only be published as a DNS TXT record.

Can I have multiple SPF records on my domain?

You should not do this. When a domain has multiple SPF TXT records, SPF returns a PermError.

Learn more here: Can I Have Multiple SPF Records on My Domain?

Предыдущая запись Следующая запись

 Protect Business Email & Improve Email Deliverability

Get a 14 day trial. No credit card required.

Create Account