What is SPF (Sender Policy Framework)?
There are various ways that cyber-criminals can forge emails. They can modify the “Mail from” and make the emails look like they are coming from a specific domain when they are not. The SPF. Sender policy framework protocol is here to put strict rules. With SPF, the domain administrator can strictly limit who can send emails from the domain. The other part, the receiver, has a mechanism to check the authorization and take the necessary measures.
The outcome of the SPF evaluation can be:
- None – No SPF record was found, or the record was not properly configured.
- Neutral – The DNS admin is not stating that a particular IP address is authorized.
- Pass – The client is authorized to inject emails with the identity provided.
- Fail – Not authorized to use the domain.
- Softfail – Probably not authorized. There is a stronger “Fail” missing.
- Temperror – Currently, there is an error, most probably related to the DNS. Later, if retry again, the problem could be gone.
- Permerror – Permanent error. The DNS admin must fix an error because otherwise, the SPF record could not be understood.
Why do you need a DNS SPF record?
SPF record, what is it?
The SPF uses TXT DNS records called SPF records. The purpose of the SPF record is to provide the information showing which mail servers are authorized to send emails on behalf of the domain name.
It can also be used in a negative way, and the DNS administrator could also stop the authorization with the simple addition of “-all” at the end of the SPF record.
When receiver will use an algorithm to check the host by:
- Checking the IP address of the sender.
- Checking the domain.
- Checking the “Mail From” or “HELO” identifiers.
SPF record example and elements
A SPF DNS record can look like this:
v=spf1 +mx a:colo.domainname.com/28 -all
- Type: SPF
- HOST: domainname.com
- Points to: v=spf1 include:_spf.domainname.com ~all
- TTL: 1 hour
There are several qualifiers:
- “+” pass
- “-” fail
- “~” softfail
- “?” neutral
And several SPF mechanism:
- ” all” – always matches. Mechanisms after it will be ignored.
- ” include” – Triggers a recursive evaluation of the host. With this, you can include other domains to send emails from the outgoing mail servers. For example, domainname.com could include the domainname.org – v=spf1 include:domainname.com include:domainname.org -all.
- ” a” – With this one, the A or AAAA record will be check and compared with the return address. If they match, then it is ok.
- ” mx” – First, perform MX lookup and check the addresses. Later compare with the return-patch. A match will permit it.
- ” ptr” – It will check the reverse DNS route and if the IP address points to the domain name. If the IP address is from the domain, then it is validated.
- ” ip4” – checks if the IPv4 address is a part of the IP network.
- ” ip6” – checks if the IPv6 address is a part of the IP network.
- ” exists” – The domains can use this one to specify arbitrarily complex queries.
Why is it a problem not having a SPF record?
Using SPF records, together with some other DNS records like DMARC and DKIM, will authenticate the outgoing mail servers, and the receiver’s side can check it.
The authentication will allow your emails or take the measures based on the mechanism of the SPF, and your emails will have better chances to go to the Inboxes of the receivers. Otherwise, your email could be denied by the SMTP or put to SPAM.
Conclusion
Using SPF is a good way to show who can send emails on behalf of your domain. Set up SPF record, modify it the way you like, and reduce the bouncing mails significantly.