Sender Policy Framework

This is the sandbox. Feel free to experiment<ht>!

That's a test line added by user 1004 ;-)
That's a test line with "<&>" (lt-amp-gt)
Another with "<&>" (dito symbolic)

lets see a line

A link to a new [[Community/subpage|page]] page creates a new page.

Step by step instructions to deploy SPF.

SPF has two parts: one for the sender, and one for the receiver. If everybody published an SPF policy, but nobody would use these policies, then nothing is going to happen. If you want others to pay attention to your SPF record, you can understand that others want you to pay attention to theirs. This is why you should do both parts! (if possible)

Sender side / Domain owner side

SPF is a way to tell others where your e-mail can be coming from. If you say your e-mail can only come from a couple of servers in Brazil, then any e-mail sent in your name by a server in China is not really from you. There's no need to waste time and resources on such mail, so you will be helping the receiver to stop wasting time on checking Domain Keys, SenderID records, Signed Envelope Senders and other cryptography, spam scanners, virus scanners, and so on. In addition, the intended receiver should not send a bounce to you.

What do you need:

• you need to know which servers you will be using to deliver e-mail
• you need to know how to encode this information in an SPF policy
• you need to be able to publish your SPF policy in DNS

Let's start with the last part. If you are not the owner of the domain (example.com. in this example) then you cannot modify DNS for this domain. If you are the owner of the domain, but if you are not able to modify DNS, then you cannot publish your SPF policy. I recommend that you start the process by verifying that you are able to publish TXT records for your domain. Publishing "hello, world" will be enough. There are still DNS providers out there that won't provide full service. It would be a pity if you did much work to create an SPF policy only to find out you cannot publish it...

Okay, let's assume you are able to publish TXT records for your domain. The next step is to find out how you are sending your messages into the world. This task can be very easy or very hard, depending on the circumstances. One thing is sure: it is not easy to guide you through this process. If there would be a "one size fits all" solution, we wouldn't need a protocol to communicate this policy!

Some possible setups:

• One mailserver or a mailserver-cluster is delivering e-mail directly to its destination.
• All e-mail is given to the provider, the provider delivers it to its destination
• Every user of a domain uses a different provider to send his e-mail, some use a webserver, some use gmail or similar

The possibilities are infinite. A large company could have subsidiaries which deliver their mail to the head office, which then in turn delivers all messages to a provider. One or two subsidiaries however deliver their mail themselves, using a local provider. In addition, some traveling salesmen will use a hotel's internet connection to deliver their mail. Yes, this setup is a nightmare from an SPF perspective.

There is no reliable way to guess this information. The only true way to solve this problem is to know how it is setup. There's one exception though: if your provider is used to deliver e-mail, and if your provider has published an SPF policy designed for you to include then you can rely on them to do part of the job. An example for this is gmail. If you rely on them to deliver your messages, then you do not need to know how they do this job. You only need to tell people that you trust what they are doing.

It usually helps if you try and consolidate all your mail into one specific (set of) server(s). Those travelling salesmen can then connect to your server, using pop3 and authenticated SMTP for instance. All mail, no exception, should come from those authorized servers. Once you've done this, you know which servers are to be authorized to speak on your behalf and then it's a piece of cake to write your SPF policy.

Known server(s)

SPF knows a lot of different ways to describe mail servers. There's no point in using them all. Use whatever is needed to do the job, but no more. Here are some of the mechanisms and when to use them:

PTR

This mechanism is only useful in some special setups. Only if all computers that send mail have a name which ends in the same domain, and if no other computers exist with a similar name (not sending mail), then PTR is for you. Most people should not use it. If in doubt, then don't use it. If not in doubt, ask for our help and we'll try to talk you out of it. If you survive that, then it's okay.

MX

If you have a lot of computers receiving mail for you, and if all of them also send mail for you, then you could choose to use this mechanism. But don't use it if you have only one computer that does all work, and don't use it if you have more than ten. I guess this means most people should not be using this mechanism.

A

This is a useful mechanism for computers that do have a static name, but not a static address. Make sure you understand DNS caching and how it would affect your ability to send e-mail.

IP4 and IP6

This is useful for computers that have a static IP address. If your address doesn't change often, this is the mechanism to use. It is fast, cheap and reliable.

If you have one computer which sends and receives mail, has a name and an IP address, then you can describe this one computer with "ip4" and no more. You do not need "mx", "ptr" and "a". Yes, that computer does receive mail, but you aren't describing the computer's function. You should list each server only once.

Unknown server(s)

If you send your mail via your provider, and if your provider has setup an SPF policy which is intended for you to use, you can include it. This way you don't need to know which servers are going to deliver your mail, you trust that your provider knows its job. It would be wise if you ask your provider (but try their FAQ first!) about this, because sometimes an SPF record is not intended to be included. Two possible scenarios where you cannot use include:

• The provider is already using the maximum amount of DNS lookups in their policy. If you include their record, your policy will do an extra lookup and thus ask too much.
• The provider can route e-mail from customers differently than their own mail. Their policy reflects their mail, not yours.

In other words: don't guess. Know.

If you know the provider has setup something for you to include, most will give you advice on how to do so. This advice is well ment but often wrong; they have no way of knowing how your record should look like. Use their example as an example only, not as something you can cut and paste. Or just read this text...

Just like "ptr", "mx", "a" and "ip4", "include" exists. If the provider says you can include "_spf.example.com", then you write it like so: "include:_spf.example.com". As with the other mechanisms, you need to separate this mechanism from the others using a space.

If you do use "include", you are relying on your provider to get it right. Usually you can. You trust them with your e-mail, so why not trust them with your SPF policy. As long as you have setup your e-mail client conforming to your provider's instructions, this mechanism should match.

Think 'receiver', not 'sender'

Before I start throwing examples in your direction, please take a moment to think about what it exactly is what you are trying to accomplish. If you are going to write an SPF policy, it is because you want other computers to look at it. When will such another computer do so? When it receives mail supposedly from you. This is what is happening:

1. Some server is knocking at the door, trying to get in and get an e-mail delivered
2. The receiving server sees the IP address of this other server
3. The sending server says "HELO mailhost.example.com" (Hello, my hostname is mailhost.example.com)
4. The receiving server will fetch the SPF policy for mailhost.example.com and process it. By the way: this is optional for the receiver, which means the sender should be prepared for it. You MUST have a policy for this domain if you want to be SPF compliant!
5. The sending server says "MAIL FROM:<username@example.com>"
6. The receiving server will fetch the SPF policy for example.com and process it.

Maybe you are sending mail through ten computers on your company network, then five more at your provider. Not important. The only thing that is looked at is the IP address of the computer knocking at the door. The decisions in this example are: is that host authorized to say "HELO mailhost.example.com", and is it authorized to say "MAIL FROM:<username@example.com>".

Examples

These examples use names and addresses which should not be used on the Internet. Of course you will use your own addresses and names, and thus you do not have a problem.

In my examples, I do not use "+ip4", "+mx" and so on. This "+" is default, and therefore I do not write it down. There is no difference, at all, between "+mx" and "mx" except that the latter is one byte shorter. This is also valid for "all", so unless you want to authorize each and every host on the Internet, you should not forget to use a qualifier: "~all", "-all" or "?all".

Home or small office, using one computer to send and receive mail. The computer's name is "adsl-1-2.city34.example.com", the MX record for your domain points to this name, the IP address is 192.0.2.1 and does not change. You are a good neighbour, so you use "ip4:192.0.2.1" to authorize this host. Prefix is "v=spf1", suffix is "-all", complete policy is "v=spf1 ip4:192.0.2.1 -all".

Same kind of office, but with a dynamic IP address. In stead of changing the policy each time a new connection is made, it is acceptable to use the server's name in this case. PROBLEM: chances are the name will also change, as it will be based on the IP address being used. Your best bet is to use another server, for example one at your ISP, or for instance dyndns. I will show an example for dyndns, not because I want to recommend their service but just because I need an example. Dyndns has specified in their FAQ how they have created a policy for you to include. Great news, just "include:outbound.mailhop.org". Prefix is "v=spf1", suffix is "-all", complete policy is "v=spf1 include:outbound.mailhop.org -all".

A slightly more complex setup is where two offices use the same domain name. One of the offices is on static IP (like the first example), the other is on dynamic IP (like the second example). Easy: "ip4:192.0.2.1" and "include:outbound.mailhop.org" both need to be authorized. Prefix is "v=spf1", suffix is "-all", complete policy is "v=spf1 ip4:192.0.2.1 include:outbound.mailhop.org -all".

Notice how this example just combines the previous two examples. You don't publish two policies, you combine those two into one.

A large company, delivering all its e-mail via the corporate firewalls. Two clusters of mail servers at two different locations are responsible for delivering all mail. These servers are also responsible for receiving all mail. In this case, it could make sense to use "mx". Use it if the servers responsible for delivering e-mail could change (for instance you often add or remove a server from the cluster). Beware of processing limits (see the RFC, section 10.1, which discusses this). A maximum of ten MX records may exist.

Especially in a closely monitored environment such as a firewall, it is often better to specify a range of servers to be authorized. For example, "ip4:192.168.1.0/28" and "ip4:192.168.2.0/28".

In either case, you need the usual prefix and suffix again. See above.

Small office, and many traveling salesmen using hotel internet connections, cybercafes, and so on. In this case it would make sense to tell the world about the one server you do know, but don't forbid the use of other hosts. Process like the first example, but do not suffix with "-all" (forbids all other hosts to use your name). Instead you end your policy with "?all". The complete policy: "v=spf1 ip4:192.0.2.1 ?all".

Authorized or not?

People sending mail via a host that is shared with other people are sometimes adviced to publish "?ip4:192.0.2.1" instead of "ip4:192.0.2.1". This is a matter of taste. The difference is this: Just "ip4" results in PASS, whereas "?ip4" results in NEUTRAL. PASS means "is authorized", NEUTRAL means "no opinion, I don't know". I give you two opinions, and you may decide for yourself which one you use.

Opinion 1: with SPF, you claim a message is sent by you (if a match occurs, of course). On a shared host, it would be possible for other customers of that host to send mail using your name. Because you aren't sure that this won't happen, you don't want this host to get a PASS.

Opinion 2: with SPF, you authorize hosts to use your name. You are using this shared host, thus you authorize it to use your name, thus you make sure the host gets a PASS.

Believers of opinion 1 loose the ability to end their policy with "?all". Believers of opinion 2 may have a problem once reputation systems find out about the problem. The RFC is clear on this: you authorize hosts, not messages. Nevertheless, you should be aware of the controversy.

Whatever you do: do not publish something stupid like: "v=spf1 ?include:shared-host.example.com ?include:otherhost.example.net ?all". If all hosts should result in NEUTRAL, then there's no point in doing these includes.

Publishing your policy

You know how to publish "Hello, world", right? Then you know how to publish your SPF policy. It is no different, except that you need to take care there may be at most one SPF policy per domain. This policy can be published in a TXT record and in an SPF record, even in both of them. See Resource Records.

It is OK if there are more than one TXT records, but only one of them may start with "v=spf1".

It is OK if there are more than one SPF records, but only one of them may start with "v=spf1".

When publishing your SPF policy, according to the specification you have a choice if you publish it in an SPF record, in a TXT record, or in both. In reality however you should publish your policy at least in a TXT record.

If you publish your policy in both types of DNS Resource Record, both records (TXT and SPF) must have the same content (thus: the same policy).

Receiver side

In DNS, you tell people where e-mail to you should be delivered. This is done in the MX record(s) for your domain. If your e-mail address is somebody@example.com then the domain is example.com.. The server(s) mentioned in this/these MX record(s) should be looking for SPF policies and process them.

Many users have delegated the task of receiving e-mail to their provider. In such a case, it is your provider that needs to do SPF verification. If you are running your own mail servers, you have to ask the people that built your software how to enable SPF processing.

Once the message is accepted by (one of the) mail receiver(s), it is considered delivered. What you do next with this message is your problem, not the original sender's problem. Especially "forwarding" (resending a message, using the original sender's name) is a problem. But it is your problem. If you are sending these messages to somewhere else, and if you are processing SPF records again, you will reject the message because you detect that you falsified "mail from"...

To do: include examples on how to enable SPF verification in MTAs.

The following is an attempt to make the Why page more suitable for different types of viewers.

Please comment on all: content, language, spelling errors, technical comprehensibility, correctness and so on.

Why?

An e-mail message was rejected.

 E-mail address:     ${identity}    e.g. someuser@example.com
 Sending computer:   ${ip_address}  e.g. 192.0.2.1
 Receiving computer: ${receiver}    e.g. receiving-computer.example.net

(Note, not for the page: experienced people now know enough, my aunt still has no clue but is not yet scared away.)

Why was this e-mail rejected? The owner of ${identity#*@} (e.g. example.com) has published rules for e-mail coming from any address that ends in @${identity#*@} (e.g. @example.com). According to ${receiver} (e.g. receiving-computer.example.net), your message did not comply with those rules.

SPF was used to communicate these rules between ${identity#*@} (e.g. example.com) and the receiver. SPF is a communications protocol, not a company, a blacklist, or similar. SPF itself cannot help that your message was rejected. The receiver rejected the message, based on information given by the domain owner (the owner of ${identity#*@} (e.g. example.com)).

If you are an e-mail user, give this information to your helpdesk, your support contact, your ISP, whichever is appropriate. They should be able to tell you what went wrong and how to solve this problem. At the very least they should be able to understand the technical information that follows.

What follows next is technical information, for people that have their own domain names and can create their own policy.

What is SPF?

SPF is an extension to Internet e-mail. It prevents unauthorized people from forging your e-mail address. The owner of the domain (the person responsible for @${identity#*@} (e.g. @example.com)) makes the rules, and you will have to follow them when sending e-mail. If you don't, you may be mistaken for a forger (see the introduction).

What went wrong?

Several things could go wrong:

• Quite often, the sender of an e-mail used an unauthorized source. Example: someone using is company e-mail address from his home computer.
• A change has been made in the infrastructure, but the SPF policy has not been adjusted.
• The domain's DNS provider published a generic SPF record without consulting the domain owner.
• A forwarder reused the original sender address when it sent its message to the next receiver.
• The SPF policy contains errors, uses too many resources, or is otherwise unsuitable for the domain.
• The receiver is in error. This happens, but is unusual.
• Nothing went wrong, except that a bounce was sent to you

How to fix

The correct way to fix depends on which kind of problem occured. Some suggestions:

Use an authorized server

This may mean changing the "SMTP server" configuration setting in the e-mail client. Or, in case of a company server, to route all mail via a "smart host" / "SMTP relay" or a similar.

Keep your record up to date

An SPF policy can be seen as a way to describe part of the infrastructure used to send e-mail. If this changes, then your SPF record will probably needs some changes as well.

Ask forwarders to respect your policy.

Forwarders use your name, and if they cause problems then you receive bounces for problems you cannot solve. The problem isn't yours, it is the forwarder's. Ask them why you should clean up their mess. However, quite often the bounce includes an e-mail address which you could try. Chances are your e-mail will end up at the recipient hiding behind that forwarder address.

Make sure your policy is correct

Most frequent errors:

• using "include" for a domain that has no SPF policy. You cannot include something that does not exist.
• using "mx" and then listing a host that is an MX server instead of listing a domain that has MX records.
• using ipv4 instead of ip4

You could try the validator which should find most (if not all) errors.

Be aware of processing limits. One MX lookup may not result in more than ten records. The total amount of DNS queries is limited, and so on. See the RFC section 10.1 for more information.

The more you rely on DNS, the more can go wrong. You may want to consider to use only "ip4" mechanisms if you can.

Receivers wrongly blame SPF

If you have no SPF policy yet the receiver claims to have rejected the message based on SPF, it may be because they guessed and guessed wrong. We don't think you should be pressured into adopting SPF, however if you would publish your own SPF policy, they would not have to guess anymore so you would probably work around the problem.

Another reason would be a mistake in their error messages. For example, the mailbox written to does not exist, but the receiver (wrongly) presents an error message talking about SPF.

You did not send a message

In this case, a forgery was detected and rejected by some host. The host accepting the message in the first place (often an ISP) could not deliver the message thus sends it "back" to the "source". Report them to spamcop for creating backscatter. It's their user that forged your name.

nowiki vs. code

<code><nowiki> http://www.openspf.org/?action=edit&id;=Community/Sandbox </nowiki></code>

<nowiki> http://www.openspf.org/?action=edit&id=Community/Sandbox </nowiki>

<code> http://www.openspf.org/?action=edit&id;=Community/Sandbox </code>

http://www.openspf.org/?action=edit&id=Community/Sandbox

<nowiki> http://www.openspf.org/?action=edit&id;=Community/Sandbox </nowiki>

http://www.openspf.org/?action=edit&id=Community/Sandbox

<nowiki><code> http://www.openspf.org/?action=edit&id;=Community/Sandbox </code></nowiki>

<code> http://www.openspf.org/?action=edit&id=Community/Sandbox </code>