What is SPF and what should the settings be?

Sender Policy Framework

SPF Record Syntax

SPF is a standard used to try to block Spam and to verify a senders email address.
It checks against the given IP's and Host names to be sure a sender is sending email from the email address he claims to be.
This helps prevent someone from claiming that your email address is the sending email address when in fact it was not.

Cpanel Control Panel can create this for you but if you wish to edit it the instructions are below

To find out what your server name is and it's IP address go to our Status Page at: http://www.cw3host.com/members/serverstatus.php

There you will find your server and by clicking on the server name which will bring you to our Server Info page where you can find the both the full host name.

For instance we have one server named darkage.dnssafesite.com.
You will also use your domain name as a possible sender.

This covers any possible info sent to the email servers you are sending to as to where the email came from

This page serves as an introduction and quick overview of SPF

Evaluation of an SPF record can return any of these results:

The "all" mechanism

This mechanism always matches. It usually goes at the end of the SPF record.

Examples:

The "ip4" mechanism

ip4:<ip4-address>
ip4:<ip4-network>/<prefix-length>

The argument to the "ip4:" mechanism is an IPv4 network range. If no prefix-length is given, /32 is assumed (singling out an individual host address).

Examples:

The "ip6" mechanism

ip6:<ip6-address>
ip6:<ip6-network>/<prefix-length>

The argument to the "ip6:" mechanism is an IPv6 network range. If no prefix-length is given, /128 is assumed (singling out an individual host address).

Examples:

The "a" mechanism

a
a/<prefix-length>
a:<domain>
a:<domain>/<prefix-length>

All the A records for domain are tested. If the client IP is found among them, this mechanism matches. If the connection is made over IPv6, then an AAAA lookup is performed instead.

If domain is not specified, the current-domain is used.

The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.

The "mx" mechanism

mx
mx/<prefix-length>
mx:<domain>
mx:<domain>/<prefix-length>

All the A records for all the MX records for domain are tested in order of MX priority. If the client IP is found among them, this mechanism matches.

If domain is not specified, the current-domain is used.

The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.

Examples:

The "ptr" mechanism

ptr
ptr:<domain>

The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches.

If domain is not specified, the current-domain is used.

If at all possible, you should avoid using this mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups.

Examples:

The "exists" mechanism

exists:<domain>

Perform an A query on the provided domain. If a result is found, this constitutes a match. It doesn't matter what the lookup result is – it could be 127.0.0.2.

When you use macros with this mechanism, you can perform RBL-style reversed-IP lookups, or set up per-user exceptions.

Examples:

The "include" mechanism

include:<domain>

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.

Examples:

Trust relationships — The "include:" mechanism is meant to cross administrative boundaries. Great care is needed to ensure that "include:" mechanisms do not place domains at risk for giving SPF Pass results to messages that result from cross user forgery. Unless technical mechanisms are in place at the specified otherdomain to prevent cross user forgery, "include:" mechanisms should give a Neutral rather than Pass result. This is done by adding "?" in front of "include:". The example above would be:

In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the first. For example, evaluating a "-all" directive in the referenced record does not terminate the overall processing and does not necessarily result in an overall Fail. (Better names for this mechanism would have been "if-pass", "on-pass", etc.)

Modifiers

Modifiers are optional. A modifier may appear only once per record. Unknown modifiers are ignored.

The "redirect" modifier

redirect=<domain>

The SPF record for domain replace the current record. The macro-expanded domain is also substituted for the current-domain in those look-ups.

Examples:

The "exp" modifier

exp=<domain>

If an SMTP receiver rejects a message, it can include an explanation. An SPF publisher can specify the explanation string that senders see. This way, an ISP can direct nonconforming users to a web page that provides further instructions about how to configure SASL.

The domain is expanded; a TXT lookup is performed. The result of the TXT query is then macro-expanded and shown to the sender. Other macros can be used to provide an customized explanation.

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
• Create a list of your domains
• List a server only once
• Only list outgoing mail servers
• Only use "mx" if your MX is used for outgoing mail
• Use "mx" with domain names, not mail server names

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)
• your ISP's mail server
• mail server of your end users' home ISP
• 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.

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 servers are used for outgoing mail

Sometimes when using configuration aids it is easy to add the mx mechanism. However MX records are used to route incoming mail for your organisation, and the same server(s) may or may not be used for your outgoing mail. If the IP address of your outgoing server is covered by an a, ip4, or other mechanism, it is not necessary to reference that server again using the mx mechanism (see list a server only once above). If the servers listed in your MX records are only used for incoming mail, it is not necessary to use the mx mechanism.

Use "mx" with domain names, not mail server names

Specifying mx:mailserver.example.com is generally incorrect, unless you truly want SPF validation to look up all the hosts that accept mail for the "mailserver.example.com" domain. (Usually, there will not be any such hosts, because "mailserver.example.com" is itself a host, not a domain.) This will not show up as a syntax error, however, it will simply not match anything.

The correct usage for validating against the MX records for "example.com" is mx:example.com, or if you want to specify a particular mail server's hostname or IP, a:mailserver.example.com or ip4:x.x.x.x. Finally, note that when your SPF rule is stored as a DNS record associated with "example.com", then "example.com" is the default domain for the rule, so mx on its own (with no explicit domain specified) is sufficient to check the sender IP against all the MX mail hosts listed for "example.com", in that context.

Only "include" existing SPF records

Let's say you want to include your web hosting company'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 an SPF record for their customers to include, or else you will need to change your record every time your ISP adds, removes, or changes a mail server's name and/or address.

Publish SPF records for HELO names used by your mail servers

Checking HELO/EHLO names is recommended by the SPF RFC. Publishing records for these hostnames is an important part of the SPF protocol. HELO or its modern version EHLO is used when Mail from is <> even if a receiver does not do 100% HELO checking.

Publishing a HELO rule involves creating an SPF record linked to the HELO FQDN used by your mailserver (example: "mailserver.example.com"). Normally this should be an entirely separate SPF rule to the one which checks the from addresses in your domain which might be associated with say "example.com". A simple example of two policies might be:

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

The first rule would be activated by any from address ending with "@example.com", and would validate such an email only if it comes from an IP address associated with an MX record for "example.com". The second rule would be activated by a HELO identification of "mailserver.example.com", and would validate the email only if it comes from the IP address associated with that server.

Another reason to take HELO names into account has to do with Publish null SPF records for your domains that don't send mail. Suppose you follow the advice in that FAQ but don't think about HELO names, you could inadvertently deny servers the right to send email. An example: a cloud of webservers send email forms out, using "webform@example.com" as the sender's address. Each webserver uses (as it should) its own name as the HELO parameter.

www.example.com.     IN  TXT  "v=spf1 -all"  web01.example.com.   IN  TXT  "v=spf1 a -all"  web02.example.com.   IN  TXT  "v=spf1 a -all"  web03.example.com.   IN  TXT  "v=spf1 a -all"

Eventhough there are no email addresses like "user@web03.example.com", the name "web03.example.com" is used for email!

If you don't publish an SPF policy for such domains, they are game for spoofers. And if you do publish an SPF policy, you better allow your host to use its own name.

Publish null SPF records for your domains that don't send mail

Once you've protected your mail sending domains with SPF, if someone is trying to spoof you, then first thing they will try is to spoof your non-mail sending domains. Publishing "v=spf1 -all" says that a domain sends no mail. As an example, you might publish:

example.com.       IN  TXT  "v=spf1 a:mail.example.com -all"  mail.example.com.  IN  TXT  "v=spf1 a -all"  www.example.com.   IN  TXT  "v=spf1 -all"