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 which have an
MX record pointing to their mail server.
For the domain name of a mail server, I use an SPF record which allows on that host to send email using its domain. This allows it to originate administrative email messages and also validates it address for use in the
HELO command. This applies to the
MX hosts as well as servers which only send email. The SPF record is:
v=spf1 a -all.
For domains which should neither originate nor send 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 this servers should use the public email domain. The SPF record is:
For domains expected 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 more more
MX records pointing to servers. Their A records, if they exists, 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 will cause failures when the domain is used in the
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 is
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 use 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 (
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.
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 failure to update both records.
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
HELO name from a server being used to deliver spam. Commonly forged domains include
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.