SPF or Sender Policy Framework is a technique used to fight spam.
By adding a TXT record in a specific syntax to the DNS zone of your domain, you can define which mail servers are allowed to send email for that particular domain.
This mechanism helps fighting spam as third party mail servers used by spammers cannot send mail for your domain from IP addresses that are not listed in the SPF record.

In other words: Sender Policy Framework (SPF) is a security mechanism created to prevent the bad guys from sending emails on your behalf by defining which IP addresses can be used to send emails from your domain.

SPF is a complex technique and we recommend new users to get a specialised third party to implement your SPF records. On our partner page you will find an extended list of technical partners that can assist you implementing your SPF records.

How the sender policy framework (SPF) works

To determine where the email of a certain domain is delivered we use MX records. These records point to the IP addresses of the mailserver that accept email for that domain for delivery in a mailbox.
SPF records function as reversed MX records and tell the world which ip addresses are allowed to send email for a specific domain.

This is done using a specific syntax in a DNS TXT record.

Receiving mail servers check this SPF record to validate whether the mail server that is sending the email is allowed to do so for this domain.
If the IP of the mail server is listed in the SPF record, the mail is accepted as valid email, if the IP address does not match the addresses defined in the SPF record, the mail will be discarded or moved to a spam folder.

This mechanism prevents unauthorised email senders from “Email spoofing”: Abusing a weakness in the email protocol that allows anyone in the world to send email using a non-existing email address or the email address from someone else.

Due to the way email works, it’s almost impossible to prevent others from sending mail on your behalf. SPF is a mechanism to fight this weakness.

What do SPF records look like

SPF records exist in general of 2 parts:

  • A version indicator: v=spf1.
  • The record body: In general a set of IP addresses or hostnames that are allowed to send mail (mechanisms).

A very complete explanation of how SPF works can be found in the SPF record syntax definition.

Breaking up an SPF record

Let’s use this SPF record as an example:

The use of the version indicator is fairly easy: As creating multiple TXT records is possible, this is used to indicate that the specific TXT record is an SPF record. This indicator currently is v=spf1, as we are still using version one of the SPF implementation.
The record body consists of a set of mechanisms available to instruct mailservers which ip’s are allowed to send email for this domain.

The mechanisms used in this example are:

  • a
  • mx
  • include spf.example.hypernode.io
  • all

The SPF record is parsed from left to right: It iterates over all mechanism statements to determine which mechanism apply to the given IP address. If none of the mechanisms match the IP address, the all statement takes presence.


Mechanisms can be prefixed with a qualifier which describes which action to take when a sending ip address matches the mechanism. The default qualifier is a +, which can also be left out.

This means our example SPF record can as well be written as:

The following qualifiers are available:

  • + (Pass) – An IP that matches the mechanism with this qualifier should pass the SPF check.
  • - (Fail) – An IP that matches the mechanism with this qualifier should fail the SPF check.
  • ~ (SoftFail) – An IP that matches the mechanism with this qualifier should soft-fail. In other words: The SPF check should fail, but the mail should be accepted by the receiving sender.
  • ? (Neutral) – An IP that matches the mechanism with this qualifier should neither pass nor fail the SPF check.

The last statement of an SPF record (in our example ~all) is the catchall qualifier: This indicates what the receiving mailserver should do with the mail if non of the defined mechanisms match.
These qualifiers together enable you to create a fine-grained selection of email senders that should or should not be rejected by the receiving mail server.


The currently available mechanisms are that you can use are:

  • The ip4 mechanism for regular IPv4 addresses
    Usage: ip4:
    This mechanism can be used to add regular IPv4 based ip addresses.

  • The ip6 mechanism for regular IPv6 addresses
    Usage: ip6:2a00:1450:400e:806::200e
    This mechanism can be used to add regular IPv6 based ip addresses.

  • The a mechanism for hostnames
    Usage: a
    If you send mail from ip address for domain example.com and example.com resolves to, the mail is accepted.

  • The mx mechanism
    Usage: mx
    This mechanism defines that all IP addresses that are present in the MX records of the domain are allowed to send email for this domain.

  • The ptr mechanism
    Usage: ptr:example.com
    This mechanism determines whether the PTR record of the domain matches the IP address of the sending server.

  • The exists mechanism
    Usage: exists:hostname.example.com
    This mechanism performs a lookup for a domain. If the lookup succeeds the mail can pass. The returned IP of the lookup does not have to match the sending IP address.

  • The include mechanism
    Usage: include:spf.example.hypernode.io
    This mechanism can be used to include another SPF record for another domain. In this example, the SPF record for spf.example.hypernode.io is checked.

  • The all mechanism
    Usage: -all
    This mechanism always matches. It usually goes at the end of the SPF record and functions as a catch-all for all IP’s that do not match any mechanism prior to this statement.

Have a look at the documentation at openspf.org for more information about the specific mechanisms.

The Return-Path

When working with SPF, it is important to know that the receiving mailserver that is validating the SPF record, never looks at the email address that is set as the From address.

The From header is part of the message body and is only used for display purposes in mail clients. The receiving mailserver does not inspect the message body for checking SPF but instead uses the return-path, which is a separate header, that is send prior to the message body. This is also the email adress that is used to return mails to when the message bounces or an error occurs.

Composing an SPF record on Hypernode

After all the theory about how SPF works in general, let’s get to the point and explain how this comes together on Hypernode.

On Hypernode all mail is send through our relay environment at Byte. This is done to filter out all spam mails coming from hacked webshops or abused contact forms.
Additionally this route protects our customers from being blacklisted on the Hypernode due to the recycling of a blacklisted IP address at our cloud provider.

This adds some complexity to the SPF record, as we regularly change the IP addresses of our mail environment.

To circumvent this complexity, we create an additional TXT record for each Hypernode that can be included in your domain, covering all IP ranges used for mail delivery.

TXT or SPF records

Only create your SPF records using a TXT record in the DNS. The previously used SPF type DNS record is deprecated.
Although most of the mail server still check if there’s a DNS record with type SPF available, but this is an older standard that is not used anymore and is soon to be declared invalid.

Determine your mail behaviour

When you start to setup SPF, first determine which mail servers are allowed to send email. This can be your office mail server, additional third parties for transactional email like Mailchimp, MailJet and Elastic Mail etc.

If you use hosted mail services like Microsoft’s Office 365 or Google’s Gmail Suite have a look at their documentation prior to implementing your SPF record.

Many specialised services that offer email functionality provide a custom TXT record. Have a look at the documentation of the hosting company to find out which record to include for the service you are using.

Implementing SPF records for the domains that you use on your Hypernode

For all domains that you send any email for, create an SPF record. You can do this manually by adding the same record to all domains, or by creating 1 SPF record for a single domain and include this record in all other domains used.

For every Hypernode, we created a TXT record containing the IP of the Hypernode itself and the IP ranges we use for our outgoing mail platform.
This record is updated when you do an up or downgrade, so it’s always up to date with the IP address used for your Hypernode.

If you include this record in your existing SPF record, all IP addresses that are used for sending mail from your Hypernode are covered.
To use this record, prepend ‘spf.’ on your Hypernode appname and include it in your SPF record.

IE: If your node’s appname is ‘example’, your SPF include record is spf.example.hypernode.io.

You can add the this record to your SPF record using an include mechanism:

Creating the SPF record

When you know which services and IP addresses are allowed to send mail from your domain, glue it all together in a single SPF record.

Adding a SPF record to the DNS of your domain

Add an include for each third party service (IE: for Mailchimp add include:servers.mcsv.net to your SPF record), and combine all IP’s and records from all your mail sending parties.
When this is done, your record should look something like:

Now open the DNS editor of your DNS provider, and create a TXT record that contains the record. Sometimes you need to add double quotes around the statement, sometimes you don’t.
After adding the record, make sure your changes are saved in case there is a “Save your changes”-button, and use dig to verify whether the record is visible when doing a lookup.

Never create multiple SPF records for the same domain, but instead include all mechanisms in a single record!

Using an SPF record generator

There are web based tools available that can help you generate an SPF record. As there are always corner cases which the generater does not take into account,
blindly generating an SPF record with one of these tools and copy paste it in your DNS zone is never a good idea.

If you know what you are doing however, this generators can be of great assistance.

The best generators we’ve found so far are the one on spfwizzard.net, and the one on unlock the inbox.
Both tools are free of use for anyone.

Finding your current SPF record

Although there are multiple online web-based tools to lookup your SPF record, the easiest is on the command line using the dig utility:

Which returns in this case 2 TXT records, of which one is the SPF record:

Testing your SPF record by sending an email

The openspf.org ensemble offers an email based SPF record tester. To use this service, send an email to <spf-test@openspf.net>.
Your message will be rejected (this is by design) and you will get the SPF result either in your MTA mail logs or via however your MTA reports errors to message senders (e.g. a bounce message).

This is done to avoid the risk of backscatter from the tester. This test tests both MAIL FROM and HELO and provides results for both.
It uses the Python SPF (pySPF) library, which is fully compliant with the SPF specification.

An example result is:

Port25.com provides another tool to test whether your SPF record is working. Send an email to <check-auth@verifier.port25.com> and you will receive a reply containing the results of the SPF check.


Debugging SPF issues can be hard, as the only way of finding information about whether your SPF is correct, is by spitting through the mail headers of your received and sent emails.
Luckily there are several third party services and analysis tools available to assist you in creating and maintaining your SPF record.

We list a few that can help you solving SPF problems:

Differences compared to DKIM

SPF is not the same as DKIM. SPF and DKIM are both spam protection mechanism that prevent unauthorized senders from mailing in your behalf.
Where DKIM works with signing messages and validating the signature to determine whether the sender is the sender it says it is, SPF uses DNS to determine which IP addresses are allowed to send email for a particular domain.
While we do not support native DKIM yet, in other words: we don’t offer a solution for signing your messages, you can always use a PHP library (for example phpmailer) to sign your outgoing emails and add a DKIM record to our DNS editor.

SPF and DKIM are both used techniques within DMARC.