SPF protects brand equity.

The present SMTP standard for email allows anyone to forge anyone else's email address. This means I could send anyone a message claiming to be from you, and only an email expert would be able to tell the difference.

On April 11, 2003, hoaxsters took advantage of this loophole to cancel class. Today, most spammers invent email addresses out of thin air when they send their spams. But there's nothing to stop them from using your name. This is called Joe-Jobbing and it is beginning to happen more often.

Already many people block mail from Hotmail and AOL simply because a lot of spam is forged from those addresses. SPF prevents sender forgery and protects you from trademark dilution.

SPF reduces inbound spam.

Spam is rising exponentially. A significant majority of spam is forged. SPF allows your mail servers to easily distinguish forgeries from real mail. Importantly, SPF works before the message body is transmitted, saving you the bandwidth cost of downloading the message and the CPU cost of filtering it.

SPF is not patent-encumbered.

Challenge-response schemes are inconvenient and subject to legal liability.

What is the implementation strategy?

You can roll out SPF in two phases.

The transitional phase gives users time to switch to SASL SMTP, and to get used to the idea of increased security. During this phase, spam detection will improve quickly as many ISPs start publishing SPF records. During this phase, you set the default response to "neutral" or "softfail". (You can identify users who are sending mail through unapproved relays by configuring a diagnostic "exists" directive which will cause them to show up in your DNS logs.

When all your users have switched to some kind of authenticated sending (eg. SASL) you can announce to them that the transitional period will end on a particular date. After that date, you can change the default to "fail": that protects your domain from being forged and will be respected by all SPF clients in the field.

How do I keep up with developments?

Managers of email services should join the SPF-deployment mailing list.

How long will it take to install?

A first-approximation publishing-only implementation at a large ISP will take between four and eight hours total; it will require coordination between your email administrators and your DNS administrators. This web site provides detailed instructions for them. After the initial work is done, you still need to consider SMTP AUTH support, outbound rate-limiting, and some "what's new" user documentation to reduce customer support costs.

Is there consulting / support?

(20040623) A variety of services offer assistance in deploying SPF and related technologies.

• For small installations, the free wizard is useful.
• Medium-sized domains may wish to engage independent consultants to assist them with training and installation.
• Large customers will probably want to contract with Professional Services vendors such as Accenture and EDS. In June 2004, the SPF community started to work with the consulting industry to perform training and technology transfer. We expect that large consulting firms will be ready to work with clients in August 2004.

Are people really going to use this?

The SPF concept was born in early June 2003. A draft RFC has been written and submitted to the IETF for review. SPF has been covered by CNN, CNET, the Washington Post, and others.

Previously, we had to call the major ISPs and tell them which servers in our address range are allowed to send email. That was how we claimed responsibility. We were already doing what SPF does, but we use the telephone rather than DNS. Using SPF is going to make communicating what we are already communicating that much easier.

Think of the original hosts.txt file that got passed around before DNS. That was how they did DNS. Now the have DNS and it just makes life easier. That is what SPF is - it is doing something that is already being done but now it is a lot easier.

-- J. Gardner, Mass Mail Systems Developer, Amazon.com, 20040714

Already, many large ISPs, including AOL and GMail, have published SPF records, and AOL will use it for whitelisting in 2004.

The Anti-Spam Technical Alliance comprising AOL, Earthlink, Yahoo, Microsoft, British Telecom, and Comcast have endorsed the publishing and use of SPF records in their June 2004 report. (We're not mentioned by name for political reasons, so you have to read between the lines.)

SpamAssassin has SPF support.

DynDNS has altered the TXT configuration for its Custom DNS service to allow people to publish SPF records.

PairNIC, eNom, ZoneEdit, and EasyDNS are some of the DNS service providers who support SPF. The .TM Registry has announced its support for SPF.

Some well-known names protected by SPF today include:

• AOL.com
• Altavista.com
• DynDNS.org
• eOnline.com
• Earthlink.net
• Google.com
• GNU.org
• LiveJournal.com
• MotleyFool.com
• OReilly.com
• Oxford.ac.uk
• PairNIC.com
• Perl.org
• PhilZimmermann.com
• SAP.com
• Spamhaus.org
• Symantec.com
• Ticketmaster.com
• w3.org