SPF (Server Policy Framework) is a simple means to limit the ability of others to forge your identity in email. I first implemented it after a forged identity under my domain was used to send Spam. Once SPF was configured, the bounce messages quickly dropped off.
Although not as frequently implemented as sender address checks, SPF can be used to prevent forgery of the HELO identity. My mail server uses SPF to check the Identity of the server. This is easier to configure and more reliable than checking the domain in the Mail from address. Even though I treat Neutral and Softfail policies as a Fail policy, I have not detected any false negatives. I verify both the address returned by the PTR record for the host and the address in the HELO command. This is primarily because the PTR record is more likely to have a valid domain.
Standard SPF Policies
I use standard SPF policies for my domains. Two of these are invariant and are applied to server domains. The third is for email domains that have an MX record pointing to their mail server.
For the domain name of a mail server, I use an SPF record which allows that host to send email using its domain. This allows it to originate administrative email messages and also validates its address for use in the HELO or EHLO command. This applies to the MX hosts as well as servers that only send email messages. The SPF record is: “v=spf1 a -all”.
For domains that should neither originate nor send any email, I use an SPF record which does not allow any use of the domain for email. This should cover most occurrences of A records, that are not for email domains or servers. This includes web server domains which are rarely used as email domains. Internet mail originating from these servers should use the public email domain. The SPF record is: “v=spf1 -all“.
For domains expected to appear in email addresses being sent to or received from the Internet, I use a record limiting its use to the MX for the domain. Normally, this is the organization’s registered domain. These domains must have one or more MX records pointing to servers. Their A records, if they exist, likely point to a web server. The SPF record is: “v=spf1 mx ~all” or “v=spf1 mx -all“. The choice of policy will depend on the policy regarding originating email from other domains. These records may cause failures when the domain is used in the HELO command from non-MX hosts.
Special Cases
In these cases, I will use example.com for the originating domain and example.net for any third-party domains.
Sometimes email is configured so that a second server handles email which can not be delivered immediately. The primary email server will need to be configured so that the secondary server, can send its mail. The required SPF record could be of the form: "v=spf1 a a:secondary.example.net -all". If the secondary server is an MX for the first server, then the SPF record can be simplified to "v=spf1 a mx -all".
If a service is used to send mailing campaigns, then it is useful to create a domain for the purpose. If the domain of the sending host can be determined using it in an SPF record like "v=spf1 a:service.example.net -all". Alternative formats if they can not provide a domain, is to:
- defer to their SPF record: “v=spf1 include:example.net -all“;
- use their domain’s IP range: “v=spf1 a:example.net/24 -all“; or
- use their IP address range, “v=spf1 ip4:192.0.2.0/24 -all“.
Other hosts generating automated email should be given their own domain. The SPF record should be selected as if they were generating a mailing campaign. Domains for automated email and mailing campaigns should normally be a sub-domain of your domain. In either case, the Reply-to address domain can be the normal email domain (example.com). The MX record should be configured so that delayed bounces are sent to a server that can process them correctly. This may involve deactivating the email address which is bouncing.
Notes
When configuring SPF records create the record as a DNS TXT record. If your DNS server supports it, you should also create a DNS TXT record. If you create both types of records remember to keep them in sync. I have seen cases where SPF failures were caused by the failure to update both records. Note: The SPF record type has been deprecated, and only TXT records should be used.
The FQDN (Fully Qualified Domain Name for hosts sending email should be at least a third-level domain (smtp.example.com). Second-level domains (example.com) usually indicate a forged name from a server being used to deliver spam. Commonly forged domains include yahoo.com, ups.com, hotmail.com, gmail.com, fedex.com, and aol.com. Some of these domains are not protected using SPF.
When verifying the domains in HELO commands or from PTR records, I treat Neutral and Softfail as Fail conditions, as those policies are not really applicable in this case. This enables the host’s domain name to be protected from forgery while still allowing a liberal policy for use of the domain in outgoing email addresses.
SPF records are not intended for use within a local area network. Limit the use of SPF records to messages from the Internet. Internal email traffic should normally be exempted from SPF checks.
Outgoing mail servers do not need to be the target of an MX record. As email load increases, an initial load balancing can be done using separate servers for incoming and outgoing mail. The outgoing server should not be listed as an MX target unless it is configured as a fallback MX. The originating domain’s SPF record will need to refer to the A record of the outgoing mail server(s) instead of the MX servers. This will require a record like: “v=spf1 a:mail.example.com -all“.