Sender Policy Frameworkis a technique used to fight spam.
By adding a
TXTrecord 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
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:
- The record body: In general a set of IP addresses or hostnames that are allowed to send mail (mechanisms).
"v=spf1 a mx include:spf.byte.nl ?all"
^ ^ ^ ^ ^
| | | | |
| | | | ---- The catchall qualifier
| ----------------------------- The record body (a set of mechanisms)
----------------------------------- The version indicator
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:
v=spf1 a mx include:spf.example.hypernode.io ~all
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:
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:
v=spf1 +a +mx +include:spf.example.hypernode.io ~all
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:
ip4mechanism for regular IPv4 addresses
This mechanism can be used to add regular IPv4 based ip addresses.
ip6mechanism for regular IPv6 addresses
This mechanism can be used to add regular IPv6 based ip addresses.
amechanism for hostnames
If you send mail from ip address
example.comand example.com resolves to
220.127.116.11, the mail is accepted.
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.
This mechanism determines whether the
PTRrecord of the domain matches the IP address of the sending server.
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.
This mechanism can be used to include another SPF record for another domain. In this example, the SPF record for
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.
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 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.
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
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:
"v=spf1 mx include:servers.mcsv.net include:spf.example.hypernode.io include:_spf.google.com -all"
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.
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 -t TXT +short example.com
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 <firstname.lastname@example.org>.
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:
<email@example.com>: Recipient address rejected: SPF Tests: Mail-From Result="pass":
Mail From="firstname.lastname@example.org" HELO name="mail.example.net" HELO Result="pass" Remote IP="18.104.22.168"
Port25.com provides another tool to test whether your SPF record is working. Send an email to <email@example.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:
- Kittermans SPF validation – This is the first SPF checker ever, and still well known for it’s completeness
- The SPF Check @ MX Toolbox – This is the most complete online email utility
- The Google Apps SPF Checker – Very useful to verify whether your SPF record is correctly setup for use with google apps
The documentation for DNS configuration on Gsuite
- The Office 365 documentation about SPF – Outdated and full of dead links, but sometimes useful for Office 365 users.
Dutch documentation for DNS configuration on office 365
English documentation for DNS configuration on office 365
- Mailcleaners Batch SPF Tester – Very useful to verify if all your domains are setup correctly.
- Common mistakes when creating an SPF record
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.