Sender Policy Framework

Common mistakes when creating an SPF record

SPF records can be quite simple ("v=spf1 a -all"), but they can also be rather complex, to account for the multitude of different outgoing mail server configurations that exist on the Internet. Newcomers to SPF often seem to make similar mistakes when creating their first SPF record. In general you should:

Begin by making a list of your mail servers

The purpose of SPF is to advertise your domain's mail servers. It often helps to make a list before starting. Consider whether any of the following are used to send mail:

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

Only the final mail server is relevant. If your company has a more complicated setup where an internal mail server routes mail through an outgoing mail server for delivery to the world, only the outgoing mail server would be listed in SPF.

Note: at one point in time, AOL would capture outgoing SMTP (port 25) traffic from its users and transparently intercept and re-route the message through AOL's outgoing mail servers. Thus any AOL users would end up sending mail through AOL's mail servers whether they wanted to or not. Using an alternate port such as port 587 'may' work to get around this if your hosting company supports it.

List a server only once

Ultimately, SPF lookups resolve to an IP address. It is not necessary to list the same server using multiple host names (e.g., "example.com" and "www.example.com" which both resolve to the same IP). In fact doing so is a bit harder on your DNS servers since a receiving server progressing through your record may be forced to make multiple DNS lookups, when simply referencing the server hostname once would have been sufficient.

If the server's IP rarely changes, consider using the "ip4:x.x.x.x" (or ip6) notation so recipients can avoid DNS lookups entirely. Since there is a limit of 10 DNS lookups per SPF record, specifying an IP address or address range is preferable for long lists of outgoing mail servers.

Often an SPF record can be condensed down to something like "v=spf1 ip4:x.x.x.x -all" if there is only one outgoing mail server.

Only list outgoing mail servers

SPF's purpose is to publish a list of outgoing mail servers. Any servers that do not deliver mail to the world, such as web servers or incoming-only mail servers, should not be listed.

Only use "mx" if your MX is used for outgoing mail

Sometimes when using configuration aids it is easy to add the "mx" mechanism. An MX is used for incoming mail, and the same server may or may not be used for outgoing mail. If the IP address of your MX is covered by an "a", "ip4", or other mechanism, it is not necessary to reference that server again (see "List a server only once," above).

Don't assume - especially if you are an ISP

If you host e-mail for others, do not just create an SPF record for a customer without researching what e-mail servers that customer uses. You may find you have blocked or hindered your customer's outgoing mail delivery from their in-office mail server, for example, or from end users who send mail through their home ISP's mail server.

Only "include" existing SPF records

Let's say you want to include your ISP's outgoing mail servers in your SPF record. Let's also say Network Solutions hosts your web site and e-mail. You may be tempted to use something like "include:networksolutions.com" in your SPF record. However there are two potential problems with this. As of this writing, Network Solutions does not publish an SPF record for the networksolutions.com domain. Therefore using "include:networksolutions.com" instantly makes your record invalid.

The other problem is more subtle..."include:networksolutions.com" would include mail servers authorized to send mail from the domain networksolutions.com. This may or may not be the same list of mail servers Network Solutions uses to send mail out using customer domains! Sometimes an ISP will create a special SPF record that customers can include with their record, such as "_spf.example.com." If you want to use an ISP's mail server(s) you should ask them if they maintain such a list.

Test your new SPF record to make sure it is valid

Use a testing tool to test any new SPF record. An invalid record will fail processing with a PermError result.

Publish your SPF record in the correct DNS server

SPF is based on DNS lookups, so for the world to find your SPF record you need to create it on the correct DNS server. If you do not know which are the "authoritative" (main) DNS servers for your domain, do a "whois" lookup or ask your web hosting company.

Allow for DNS caching during testing

Remember that if you are using a testing utility to look up your SPF record in DNS, you need to wait until its TTL (time to live) expires and the change propagates to the world before the utility will see any changes. Often it is easier to paste your SPF record into the utility instead.