A few steps to consider when creating an SPF record

Before creating your SPF record, there are a few steps you should take in order to organize the information needed effectively. You will need to make note of all of the servers that will be sending outgoing mail traffic. For example: 

• webserver
• in-office mail server (e.g., Microsoft Exchange)
• your ISP's mail server
• mail server of your end-users' home ISP
• any other mail server

Note: Only the final mail server is relevant. You do not need to include previous hops in the SPF record. 

Once this has been done, you will want to gather a list of your domains. You can use the information within the Agari user portal to ensure you are including the correct domains that send traffic. You can find the list of your registered domains within the Agari BP portal by going to Configure > Manage Domains.

When configuring SPF, make sure you only list a server once. SPF lookups resolve to an IP address. You are limited to 10 DNS lookups. You will want to ensure you are not adding the same server for multiple hostnames (e.g., "agari.com" and "www.agari.com").

Consider using the ip4:x.x.x.x (or ip6) notation so recipients can avoid DNS lookups entirely. 

Typically you might only list outgoing mail servers since SPF's purpose is to validate sending mail servers.  However, you will need to consider whether your inbound mail gateways (MXs) will ever generate bounce messages, system reports, alerts, or other administrative messages.  If this is the case (and it almost always is), you will want to use the "MX" mechanism unless those servers are already covered by an IP range you already specified via ip4, ip6, or some other include.

Only include existing SPF records. Do not include a name that does not have a published SPF record. This will probably make your SPF record invalid. 

Publish SPF records for HELO names used by your mail server. Example:

example.com.             IN  TXT  "v=spf1 mx -all"
mailserver.example.com.  IN  TXT  "v=spf1 a -all"

Checking HELO/EHLO names is recommended by the SPF RFC. Publishing a HELO rule involves creating an SPF record linked to the HELO FQDN used by your mail server, there are two rules to follow when publishing a HELO rule. The first rule would be activated by any from an address ending with your domain (using the example above that would be "@example.com"). This would validate emails only if it came from an IP address associated with the MX record for "example.com". The second rule would be to activated by a HELP identification of "mailserver.example.com", and would only validate the email coming in from the IP address associated with that server. 

It is best if you configure null SPF records for domains that do not send mail. Once you feel comfortable with the implementation of SPF on your mail sending domains. People who are sending spoofed emails will aim towards sending mail from domains you do not generally send email from. This is because the assumption is that there will not be as many configurations of authentication techniques on such domains. Setting up SPF on these domains will help combat this way of thinking. 

Before you implement your SPF record, you should use an SPF testing tool to ensure it is valid. An example of a tool that can be used would be SPF Tools. We also provide an SPF lookup tool if you would like to view if a domain has a current SPF record and if so you can check if it is valid: SPF Tool

Always make sure to publish your SPF in the correct DNS server. As you know SPF is based on DNS lookups. Without creating the SPF on the correct DNS server, recipients will be unable to look up your record correctly and it will fail. If you are not sure which DNS server is the "authoritative" DNS server, you can always do a "whois" lookup on your domain or you can ask your domain hosting company. 

Make sure to let your users know that you have implemented SPF. They may need to configure SMTP Auth in their own email client. 

For more information on SPF, please visit: www.openspf.org