Setting up or fixing and SPF record can be pretty difficult. It requires time, precision, and a deep understanding of how your email sending systems work together. Who you authorize to send emails on your behalf, impacts the delivery of your business’ emails. To get started on the right foot, let’s dive into the various ways of authorizing domains & IP addresses, and setting up an SPF record the right way.

Basic SPF syntax

An SPF record (RFC 7208) 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: TXTv=spf1

You 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 & 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 ( as well as its subdomains ( a mx

IP-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.: ip4:
  • For IPv4-ranges, e.g. ip4:
  • For IPv6-addresses, e.g.: ip6:2a01:7c8:3:1337::27
  • For IPv6-ranges, e.g.: ip6:2a01:7c8:3:1337::27/96


The fifth option is to refer to a domain where your SPF record is specified. This is what we did for our own domain. The SPF record for refers to: TXTv=spf1 ~all

referring to: TXTv=spf1 ip4: ip4: ~all

Combining 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:

TXTv=spf1 a mx ip4: ip6:2a01:7c8:3:1337::27 ~all


To indicate what action the receiving mail server should take, before the all mechanism, specify a character:
~+ or ?:

  1. ~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.
  2. -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.
  3. +all, which simply accepts all emails. With this, the rest of your SPF record is useless.
  4. ?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:

  1. Look for the DNS settings of your domain – for providers usually under ‘Product Settings’;
  2. If your domain does not yet have an SPF record, choose ‘add a record’;
  3. Select TXT as the record type;
  4. Select host / target and define it as @ or leave it empty;
  5. Enter your new SPF record in the text area and check that it starts with “v=spf1”;
  6. Save your record and you’re done! Now your new SPF record will go live as soon as possible (depending on TTL)


Dissecting the Sender Policy Framework

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!