Sender Policy Framework

I'm an ISP. What should I keep in mind?

1. Vanity domain holders may point to you using an include: directive. Keep in mind the overall processing limits will apply to their SPF record and yours together, so try to minimize the number of DNS lookups your record requires.
2. You should support SASL AUTH on ports 25, 465 and 587. When your users need to phone home from an Internet cafe, port 25 may be blocked, but port 465 and 587 are not. Most modern mail clients support STARTTLS and SASL AUTH on port 587, but Microsoft Outlook and Outlook Express support the older SMTPS approach via a "wrapped port" on port 465.
3. You may want to set a default of "unknown" by saying "?all" instead of "-all" for the first few months, to accommodate legitimate users who have been sending mail through somebody else's servers.
4. You can tell who these users are by adding an "exists:%{l}.%{i}._spf.isp.com" record, and grepping in your DNS server logs to see who's mailing through what machines. Then you can contact all nonconformant users and tell them to use your SMTP server.
5. You should never publish "-all" for customers domains without the consent of your customers. They will have ways of sending mail that you don't know about. Keep your customers informed about your SPF roll-out, this will prevent them from being unpleasantly surprised by mail that suddenly is not delivered due to SPF "fail" results. Insufficient communication will drive up your support costs and result in your customers being less happy with both your service and SPF.

Include magic

If you are hosting many domains sending mail using your services let the domain owners (your users) figure out what they want in their SPF policies. Some of them will also use other providers, not only your services. Some will want no nonsense PASS or FAIL policies, others might want PASS or NEUTRAL, and many won't care about SPF as long as they have no problem with forged mail from some@user.example.

Things you can do: You have one or more outbound mail servers, they use EHLO mailer2.your.domain.example or similar names. You can publish policies for these HELO names, example:

mailer2.your.domain.example. IN TXT "v=spf1 a -all"

This means that any mailer claiming to be mailer2.your.domain.example with an address different from A(mailer2.your.domain.example) in the EHLO gets a FAIL, receivers checking SPF hopefully reject FAIL.

More interesting, your users with various domains cannot be sure which outbound servers you use. But they need to know or guess this when they publish policies for their domains, and wish to send mail using your services. Forcing users to guess is a bad idea.

To make this as painless as possible for them offer a policy they can include enumerating all your outbound servers by name (SPF "a" mechanism), by number (SPF ip4 or ip6 mechanism), or if you must, use the mx mechanism as an indirect way to list all names - but note that MX is actually about your inbound servers, this trick makes only sense if inbound happens to be the same as outbound for your mail servers.

You can be fuzzy to some degree, e.g., if you have a /24 with 256 IPs (of course not all of them outbound SMTP servers) say:

dummy.your.domain.example. IN TXT "v=spf1 ip4:11.22.33.44/24 ?all"

That permits all 11.22.33.nn IPs in CIDR /24 notation. Or say:

dummy.your.domain.example. IN TXT "v=spf1 a:mailer2.your.domain.example/24 ?all"

Same effect as long as the address of mailer2 belongs to the /24. You'd then tell your users that they can include this policy in their policies. Your user with the domain user.example can then say:

user.example. IN TXT "v=spf1 a include:dummy.your.domain.example -all"

That means that mail from any@user.example must either come from the IPs of user.example, or from one of the 256 included IPs in your dummy policy, or else it FAILs. Likewise the user.example owner could permit more IPs for other routes, or pick ?all for a NEUTRAL result.

Your users might have not the faintest idea what that is about, and maybe you intend to offer a Web form or similar, where the smarter users can set their SPF policies, actually published by you if your services cover mail (SMTP) + domain (DNS).

In that case offer include:dummy.your.domain.example as default like this for all domains hosted by you:

user.example. IN TXT "v=spf1 include:dummy.your.domain.example ?all"

This means that mail from any@user.example gets an SPF PASS if it is sent via your servers, otherwise it gets NEUTRAL. You can offer to switch it to "otherwise FAIL" protection when a user wants this.

Maybe add "a" to the default for user.example if that is not anyway covered by dummy.your.domain.example. While you are at it please also publish identical policies using the new SPF RR type, using TXT is a kludge until all name servers and SPF implementations can deal with the new DNS RR type.

Please note that ?all and -all in an included record have the same "no match" effect, the including policy needs its own -all for FAIL-protection. However, if the dummy record is also the target of redirections, the difference matters:

your.domain.example. IN TXT "v=spf1 a redirect=dummy.your.domain.example"