How to fine tune your SPF

What is SPF and what should the settings be?

Sender Policy FrameworkSPF Logo

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:

Result Explanation Intended action
Pass The SPF record designates the host to be allowed to send accept
Fail The SPF record has designated the host as NOT being allowed to send reject
SoftFail The SPF record has designated the host as NOT being allowed to send but is in transition accept but mark
Neutral The SPF record specifies explicitly that nothing can be said about validity accept
None The domain does not have an SPF record or the SPF record does not evaluate to a result accept
PermError A permanent error has occured (eg. badly formatted SPF record) unspecified
TempError A transient error has occured accept or reject

The "all" mechanism

all

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

Examples:

"v=spf1 mx -all"

Allow domain's MXes to send mail for the domain, prohibit all others.

"v=spf1 -all"

The domain sends no mail at all.

"v=spf1 +all"

The domain owner thinks that SPF is useless and/or doesn't care.

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:

"v=spf1 ip4:192.168.0.1/16 -all"

Allow any IP address between 192.168.0.1 and 192.168.255.255.

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:

"v=spf1 ip6:1080::8:800:200C:417A/96 -all"

Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.

"v=spf1 ip6:1080::8:800:68.0.3.1/96 -all"

Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.

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.

"v=spf1 a -all"

The current-domain is used.

"v=spf1 a:example.com -all"

Equivalent if the current-domain is example.com.

"v=spf1 a:mailers.example.com -all"

Perhaps example.com has chosen to explicitly list all the outbound mailers in a special A record under mailers.example.com.

"v=spf1 a/24 a:offsite.example.com/24 -all"

If example.com resolves to 192.0.2.1, the entire class C of 192.0.2.0/24 would be searched for the client IP. Similarly for offsite.example.com. If more than one A record were returned, each one would be expanded to a CIDR 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:

"v=spf1 mx mx:deferrals.domain.com -all"

Perhaps a domain sends mail through its MX servers plus another set of servers whose job is to retry mail for deferring domains.

"v=spf1 mx/24 mx:offsite.domain.com/24 -all"

Perhaps a domain's MX servers receive mail on one IP address, but send mail on a different but nearby IP address.

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:

"v=spf1 ptr -all"

A domain which directly controls all its machines (unlike a dialup or broadband ISP) allows all its servers to send mail. For example, hotmail.com or paypal.com might do this.

"v=spf1 ptr:otherdomain.com -all"

Any server whose hostname ends in otherdomain.com is designated.

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:

In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.

"v=spf1 exists:example.com -all"

If example.com does not resolve, the result is fail. If it does resolve, this mechanism results in a match.

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:

In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.

"v=spf1 include:example.com -all"

If example.com has no SPF record, the result is PermError.
Suppose example.com's SPF record were "v=spf1 a -all".
Look up the A record for example.com. If it matches 1.2.3.4, return Pass.
If there is no match, other than the included domain's "-all", the include as a whole fails to match; the eventual result is still Fail from the outer directive set in this example.

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:

"v=spf1 ?include:example.com -all"

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:

In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.

"v=spf1 redirect=example.com"

If example.com has no SPF record, that is an error; the result is unknown.
Suppose example.com's SPF record was "v=spf1 a -all".
Look up the A record for example.com. If it matches 1.2.3.4, return Pass.
If there is no match, the exec fails to match, and the -all value is used.

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

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"

 

 

 

  • 2 brukere syntes dette svaret var til hjelp
Var dette svaret til hjelp?

Relaterte artikler

Proper use of a Email forward and to avoid Spam blocking

A Email forward is very useful if you wish to create email addresses that doesn't really exist....

My email account is over limit but there are no emails in the account

This is most likely due to Spam Assassin's Spam Box feature. Spam Box is a feature for those...

How do I use Spam Assassin?

First you Enable Spam Assassin. If an email is found to be Spam the system will add ***SPAM*** to...

Using Portable Email Devices

Our servers support both Pop 3 and IMAP mail systems. You can use any type of PDA to access...

Outlook and Windows 7

Older versions of MS Office and Windows 7 Problems If you are using Office versions lower than...