Sender Policy Framework

Is SPF the same thing as Sender ID? Which is better?

Executive summary

SPF and Sender ID are not the same. They differ in what they validate and what "layer" of the e-mail system they are concerned with. Sender ID is not the latest version of SPF – it is a obsolete and independent experiment. The "spf2.0" tag name is a historical accident. Neither is better because they address different problems. There is controversy because Sender ID is incompatible with existing specifications. Microsoft is aware of the problem and representatives of theirs have stated that they have no plans to fix it. There are practical work-arounds for SPF and Sender ID users.

Are SPF and Sender ID the same?

SPF and Sender ID are not the same. Both validate e-mail sender addresses, and both use similar methods to do so. Both publish policy records in DNS. Both use the same syntax for their policy records. So you have some excuse to be confused. They differ in what they validate and what "layer" of the e-mail system they are concerned with.

Is Sender ID "SPF 2.0"?

The tag for SPF records is "v=spf1". It is defined by RFC 4408 to apply to the MAIL FROM and HELO identities only. The tag for Sender ID records can be "spf2.0/pra", "spf2.0/mfrom", or "spf2.0/mfrom,pra", depending on which identities the policy applies to. Nevertheless, Sender ID is not the latest version of SPF — it is a obsolete and independent protocol. The tag name is a historical accident and was assigned by the failed MARID IETF working group.

Which is better?

Neither is better because they address different problems. Comparing them is comparing apples and oranges. SPF can be compared to other SMTP layer protocol proposals like CSV/CSA. Sender ID can be compared to other RFC 2822 layer protocols like DomainKeys IM (DKIM). Nevertheless, the SPF technical community does have its own opinion on the merits of Sender ID.

Why is there controversy about SPF vs Sender ID?

The Sender ID specification contains a recommendation to use SPF's v=spf1 policies — which are originally defined to apply to MAIL FROM and HELO identities only — and apply them to the PRA identity as well. Specifically, it says to consider v=spf1 as equivalent to spf2.0/mfrom,pra. This is technically wrong, as is explained in detail below. Sender ID implementors should correct this and treat v=spf1 records as equivalent to spf2.0/mfrom. Unfortunately this mistake in the Sender ID specification was not corrected prior to its publication despite an appeal from the SPF project.

This creates a very bad situation in that Sender ID implementations that follow the recommendation in the Sender ID specification (RFC 4406, section 3.4) violate the SPF specification (RFC 4408). Since the Sender ID specification defers to the SPF specification for the definition of v=spf1, and because SPF has been in existence (prior to the publication as an IETF RFC) a lot longer than Sender ID, the recommendation in the Sender ID specification should be ignored by implementors.

How will Sender ID implementations violating the SPF specification affect me?

If you have published an v=spf1 policy to protect the use of your domain in the MAIL FROM and HELO addresses, Sender ID implementations that apply your policy to PRA (per RFC 4406) will reject your mail if you use your domain in the "From" (or generally PRA) header field while sending from (MAIL FROM) another system.

Informal surveys have shown that in roughly 80% of e-mail surveyed, MAIL FROM and PRA are the same. However about 20% may be wrongly rejected or flagged by Sender ID implementations. Microsoft is aware of the problem and representatives of theirs have stated that they anticipate the conflict to resolve itself as soon as domain owners are publishing all their v=spf1 policy records with the possible PRA interpretation in mind. Of course this is not going to happen as there are hundreds of thousands of v=spf1 records out there that were published long before Sender ID even existed.

What should I do if my SPF record is misinterpreted?

First, contact the recipient who wrongly rejected your message and explain the problem. Send them here to learn about the issue. If you are peers, you may even be able to convince them to get their Sender ID implementation fixed to respect the original meaning of v=spf1 records.

Domain Owners

Meanwhile, if necessary, as a domain owner you can prevent Sender ID implementations that violate the SPF specification from using your v=spf1 policy for PRA checking by publishing an explicit spf2.0/pra policy. Unless you have researched and developed a PRA policy, you should publish an empty spf2.0/pra record (i.e., "spf2.0/pra"). There is no simple translation from MAIL FROM policy to PRA policy — they are different animals. Luckily, the Sender ID specification forbids implementations to fall back to a v=spf1 record for PRA checking if an (empty or not) spf2.0/pra record exists.

Mail Users

As a user, you can work around the problem by making PRA and MAIL FROM the same. For instance, if you are trying to send mail with your domain in the "From" header field, and Sender ID rejects it (because you are not sending from a system authorized by your v=spf1 policy), you can add a "Sender" header field to your messages (to override the "From" field with regard to PRA) with the domain you are sending from. Of course your mail client has to support this.

MTA Operators

Some people have experimented with working around Sender ID's incompatibility with SPF for mail that passes through their system by adding a "Sender" (or other more obscure) header field with a copy of the MAIL FROM to force the PRA address to match. Use this approach with caution — it has not been fully investigated for unintended consequences.

Sender ID implementors

Ignore the recommendation in the Sender ID specification, section 3.4, to treat v=spf1 equivalently to spf2.0/mfrom,pra. Instead, treat it as spf2.0/mfrom. At the very least, make this configurable in your implementation and make the spf2.0/mfrom interpretation the default.