The domain SPF record defines a ‘white list’ of legitimate mail servers that are authorised to be sending mail for your domain. In effect this record says; These are my mail servers and so if you receive an Email claiming to be sent from my domain, but not from a server on this list, you can presume it has not been sent by me.
An example domain SPF record would be:
The standard provides a wide range of formats for the list of servers including defining them by:
- Either IPv4 or IPv6 address, e.g. ip4:192.168.0.1
- CIDR block (IPv4 or IPv6), e.g. ip4:192.168.0.1/24
- DNS lookup, either against A or MX type records
- Using an include statement pointing to details held in another DNS record
- Defining mail host names suitable for reverse DNS PTR checking
- EXISTS, macro expansion and other mechanisms
The final -all ‘mechanism’ indicates the authority of the record and includes:
- +all Pass; implies any server may send mail for the domain and so not relevant here
- -all Fail; if the sending mail server is not included in the SPF list, the message should be treated as spam and rejected
- ~all Soft Fail; if the sending mail server is not included in the SPF list, the message should be suspected to be spam and accepted, but marked appropriately
- ?all Neutral; implies nothing can be inferred from a pass or fail result and so again not relevant here
For spam control purposes, only ~all (soft fail) and -all (fail or ‘hard fail’) are applicable. Often a soft fail is used initially while the impact of the SPF record is assessed, although the reality is a lot of domains survive on a ‘soft fail’ and never ‘bite the bullet’ and implement ‘hard SPF’. It’s also true that a lot of ISPs are wary of rejecting mail based on a ‘hard’ SPF fail, and so a -all may be handled as if it were ~all no matter what your SPF record says. Ultimately the decision on how a received message is processed is in the hands of the receiving mail server; you can only suggest a course of action.
Hence a fully completed domain SPF record might look like:
This record says that for the domain example.com, any server referenced by an MX record for the domain or the individual address 192.168.0.1, is a valid server sending mail on behalf of the domain. This kind of record might be used to list your own servers plus the server(s) of an external agency also sending mail on behalf of your domain.
This paper is not a suitable place in which to explain all the details of the SPF record syntax which is extensive, other than to say the use of IP addresses or CIDR blocks is a common mechanism. Service providers on the other hand often provide include-based recommended SPF settings allowing them to maintain the contents of the included record without service users needing to update SPF records within their own domain.
There is though one word of caution on the use of include and other lookup mechanisms; Ultimately the receiving mail server needs to distil the SPF record down to an IP address match between the IP address of the mail server attempting to deliver mail to it and the domain’s SPF record. Service Providers in particular can use nested includes where one include refers to a subdomain which itself uses further SPF include statements. If this is then combined with an extensive SPF record due to a domain using many Email services/servers, it can result in a DNS timeout within the receiving infrastructure, prematurely ending the SPF check. This can cause legitimate mail to be incorrectly processed as spam due to the lookup failing due to the timeout. It can therefore be necessary to ‘distil’ SPF records down to IP or CIDR lists even though this can result in additional SPF record maintenance.
The key to effectively deploying a domain SPF record is to ensure you identify all mail servers that legitimately send Email quoting your domain. This can be fairly straightforward for a smaller organisation, but more of a challenge in larger organisation which may have a variety of Email routes and employ a number of outside agencies that also send mail on behalf of the organisation. The broader your spread of Email services, the more of a challenge the collection of legitimate server information for your SPF record will be.
You should define one ‘HELO/EHLO’ name record per name used by your mail server(s) when sending mail. If you operate a cluster of servers, maybe named smtp1 to smtp4 or mail1 to mail4, then presuming each sends Email quoting its own name which is a general recommendation, then you should define one DNS record per name.
An example HELO name SPF record would be:
The record would be used as a part of the HELO identification when mail1.example.com sent mail. A message claiming to be sent by mail1.example.com would only pass an SPF check if the message was being sent from the IP address associated with that server.
Note that in this form, it would be necessary for you to define a DNS A record pointing to mail1.example.com although you might also define the server by IP address. Note that the record differs to the domain record which is in the unqualified name of example.com, as this record solely refers to the fully qualified server name, mail1.example.com.