What is SPF (Sender Policy Framework)?

Jeana Hollingsworth

http://customer.convio.com/whatisspf

What is SPF?

Sender Policy Framework (SPF) is one of a number of proposed standards which will enable owners of Internet domains to publish information which other people's email systems can use to help decide whether an email is legitimate or forged. SPF has now emerged as the clear winner and is actively supported by major email services such as Google, Yahoo and AOL.

The general umbrella acronym for such techniques and proposals is MARID - Mail Authentication via Records In DNS - and the IETF has had a number of MARID working groups over the years.

Other MARID proposals of note include a proprietary one from Microsoft, called "Email Caller ID", and one contributed by Yahoo! called Domain Keys.

Why does SPF matter to organizations doing email marketing?

Major consumer ISPs such as AOL, Hotmail Yahoo! and Google Gmail have started to perform SPF checks on inbound mail. These checks are merely one part of a comprehensive, mutli-layered strategy to combat spam, but a positive confirmation via SPF that the email is legitimate and authorized is an important element in maximizing the likelihood of successful deliveries, and one under the organizations' control.

How do SPF and similar systems work?

The common theme in all these systems is that the owner of an internet domain, for example foo.org, will publish records in the DNS zone for foo.org that determine which servers on the internet are allowed to send email on behalf of addresses in that domain. A mail server receiving email which claims to be from foo.org can look up these records, if they exist, and determine if the sending server is authorized to send email for that domain.

Yahoo! Domain Keys takes things one step further; instead of just identifying authorized mailservers, its process involves applying a digital signature to the email headers. This is more complex to deploy since it is not a one-time publication of static data, the capability to calculate the digital signatures must be added to the email sending software, and PKI infrastructure must be managed. Domain Keys is currently being protoyped by Yahoo! Mail and Google Gmail.

Convio anticipates that we may in the future add support to our software for Domain Keys based on need, but there is currently no timeline to do so.

What are the recent technical developments in SPF?

The SPF committee sat down with Microsoft in 2004 to try to unify SPF and Caller-ID ... the merged proposal was an awkward hybrid called Sender ID, which Vinton Cerf, the "father of the Internet" described to the author of this FAQ as "a bit of a camel", and was unpopular and derided in many communities as it would require implementors to license Microsoft's Caller ID patent to fully use it - to ensure interoperability, Internet and network technology standards are traditionally open and unencumbered by intellectual property, even ones originated by vendors such as NFS (Sun Microsystems) or SMB/CIFS (Microsoft).

The good news is that SPF version 2.0 has emerged from the ashes of Sender ID, and is becoming popular, and it has subsumed some nice features from the Microsoft Caller ID proposal, of note the ability to define SPF for the "From" address more familiar to end users, as well as the return path (envelope sender) known only to email system administrators.

How does SPF need to be set up for an organization using Convio?

To get full benefit from SPF, there need to be two sets of records, for the return path and the From address.

The return path address on Convio system-generated email is a convio.net one, so SPF records for that are Convio's responsibility. The records for the "From" address will need to be published in the organization's DNS.

The SPF term which maps to "From address" (modulo some small print) is "Purported Responsible Authority" or PRA. An SPF PRA record defines which servers are allowed to send email with the organization's domain name in the From address, and must be published in the DNS for that domain.

Determining what the SPF policy should be for a domain is a matter for each organizations' IT team; Convio offers the following guidance:

If an organization publishes a PRA record for a domain used in the "From" address of Convio emails, it MUST contain a rule which explicitly authorizes Convio's servers as legitimate email sources for that domain. To do this, include the following rule:

+autboundmail.convio.net

I just have a simple setup, can you recommend a PRA setting for me?

For 95% of our clients, an appropriate policy for which servers can send email is "our mail inbound server(s), plus Convio's" - to determine if this right for your organization, make sure the following conditions are met:

1. Convio is the only ASP-hosted service that sends email on the organization's behalf

2. Employees are not sending email with organization "From" addresses using external services such as Yahoo! Mail, Blackberry, T-mobile or their home ISP's mail servers; if they are, it will be necessary to curb the practice before deploying a PRA record (whether you use Convio or not).

3. Your email setup is symmetrical, in the sense that the only server(s) which deliver(s) your outbound office email are the same one(s) that accept(s) inbound mail. If you are using an ISP to manage your office email inboxes instead of having your own mail server(s) on the premises, you'll need to confirm that their setup is symmetrical in this way.

Provided the above conditions are met, the following PRA record will work:

spf2.0/pra +mx +autboundmail.convio.net ?all

This translates as: "Servers specifically allowed to send mail are our inbound server(s), and (ii) Convio's servers. For mail from any other source, treat it as SPF neutral, as if we had never published this PRA record."

What review steps should I take before publishing my PRA record?

In addition to making sure it correctly encompasses the way email is being used within your organization, it is recommended that you have Convio Support review your proposed record before you publish it, to confirm it correctly authorizes our servers. Open a Support Desk ticket.

What is the syntax for putting SPF records in DNS?

An SPF record is published as the TXT record type, for the domain itself. SPF-checking email servers can differentiate it from other TXT records using the fact that it starts with "spf2.0....".

An example of the DNS syntax used in a zone file for the BIND (named) DNS server software (presuming the example foo.org domain name) would be:

foo.org. 86400 IN TXT "spf2.0/pra +mx +autboundmail.convio.net ?all"

Note the trailing dot after foo.org - tthis indicates to BIND that this record has an absolute name and not relative to the zone domain name (SOA). The other syntax for specifying domain-level records to omit the name field entirely, but it is arguably less clear.

Other DNS software uses different input formats - if you are using an offsite vendor, perhaps your office ISP, to host your DNS for you they will typically provide a web interface, where you will need to select the record type "TXT" and supply the SPF string as the value.

Where can I learn more about SPF?

There are numerous online forums, mailing lists, etc. - the best general resource website and a great starting point is http://spf.pobox.com/.

Resources

Email Sender Verification and setup

Yahoo DomainKeys: Configuration Pitfalls, Tips, and Comments

YDK and SPF basics

What is SPF (Sender Policy Framework)?

Trusted-sender.convio.net FAQs that can be shared with Constituents when Yahoo DomainKeys are not implemented for your site