Sender Policy Framework, or SPF, is an email authentication protocol that allows domain owners to specify the servers that are allowed to send emails on behalf of their domains.
When an email is sent from your domain, receiving email servers check your DNS for an SPF record. This record contains a list of all IP addresses that are authorized to send email from your domain. If the sender’s IP address matches one of the addresses in the SPF record, the email gets authenticated.
The SPF record is crucial to implementing SPF on your domain. It’s published as a TXT record on your DNS that can be modified according to the specifics of your domain. Here’s an example of an SPF record:
v=spf1 a mx ip4: 188.8.131.52 include:_spf.google.com ~all
Let's break down each element in this record so we know what everything does.
An SPF record always starts with ‘v=‘, which indicates the version of SPF being used. spf1 is the most commonly used version of SPF and is understood by all email clients.
Mechanisms are elements of the SPF record that direct the receiving server to check specific records on DNS or use certain protocols when performing SPF authentication.
a — All the A records of the domain for which the SPF record is published are tested. If the sender’s IP address matches an IP in the A record, this mechanism passes.
ip4 — Specifies an IPv4 network range for the sender’s IP address.
ip6 — Specifies an IPv6 network range for the sender’s IP address.
mx — MX records specify which servers should be used to relay emails. If the sender’s IP address matches one of the MX records of the domain for which the SPF record is published, this mechanism passes.
ptr — The hostname for the sender’s IP is looked up using PTR queries. If a hostname ends in a domain that matches the one for which the SPF record is published, this mechanism passes. PTR queries should be avoided as far as possible to limit the number of expensive DNS lookups.
exists — Performs and A query on the specified domain. If a result is found, this mechanism passes.
include — The specified domain is searched for a match. If the domain doesn’t have its own valid SPF record, it results in a permanent error.
all — This mechanism always matches. It’s used with a qualifier to include all of the IPs that the other mechanisms don't match with. It’s usually added at the end of the SPF record.
“+” — Pass. The SPF record designates the IP address to be allowed to send.
“-“ — Fail. The SPF record designates the IP address NOT be allowed to send.
“~” — SoftFail. The SPF record designates the IP address NOT be allowed to send, but is in transition.
“?” — Neutral. The SPF record designates that nothing can be said about the validity of the IP address.
Mechanisms are set by default to Pass.
In the example above, the use of ‘a’ and ‘mx’ is equivalent to ‘+a’ and ‘+mx’. However, '~all’ tells us that all IP addresses that don’t match with ‘a’ and ‘mx’ should be considered a SoftFail according to SPF.
Modifiers are optional, and may be used only once per record.
redirect — Used to point to the SPF record of another domain. This is for when you have multiple domains but want to use the same SPF record data on all of them. The second domain must have its own valid SPF record. redirect is only used when you control both domains, otherwise include is used.
exp — If a receiving server rejects a message, it can provide an explanation.
Limitations of SPF Records
In order to reduce processing load on receiving email servers, SPF records have certain in-built limitations that you have to adhere to.
Only 1 SPF record per domain name — To properly implement SPF, you can only publish one SPF record to your DNS for each domain. If there are more than one, the receiving server doesn’t know which one to check, and your email fails SPF authentication.
Maximum of 10 DNS lookups — Your SPF record can’t have more than 10 mechanisms which result in DNS lookups.
Maximum of 10 MX records — When analysing the mx mechanism, there’s a limit 10 MX records that the server can query.
Maximum of 10 PTR queries — When analysing the ptr mechanism, the server can’t perform more than 10 PTR queries.
When you go beyond the 10 DNS lookups on your SPF record, your SPF authentication fails automatically. To fix this, PowerDMARC has come up with an innovative feature: PowerSPF. With just one click, you can optimize and shorten the length and number of DNS lookups in your SPF record. You can get maximum deliverability with almost zero effort.