SPF

Though I don't configure my MTA to use SPF at all, I do publish SPF records for the domains I host:

v=spf1 a a:llamail.com include:comcast.net include:std.com -all

That Version 1 SPF ("v=spf1") record specifies that all my outgoing email is sent from:

("a") the same host listed as the server for the domain in question (such as jcb-sc.com)
("a:llamail.com") my colocated server (llamail.com)
("include:comcast.net") whatever Comcast publishes in the SPF for its comcast.net domain
("include:std.com") whatever Software Tool & Die publishes in the SPF for its std.com domain

I don't recommend using SPF to block incoming email, or to filter it such that it might end up accepted, unread, and unbounced. But I hope that, by publishing my own SPF records, those who use SPF for these purposes will accept and properly prioritize emails that actually do originate from my domains.

Failings of SPF

The reasons I don't recommend using SPF to block incoming email are substantially and persuasively addressed by Jonathan de Boyne Pollard, who claims SPF Is Harmful, though I now disagree with any implications that IM2000 Internet Mail is preferable to SMTP (and yet am "on the fence" with regard to IM2000 compared to SMTP with widespread adoption of SPF).

I do believe forgery is a significant problem on the Internet. In fact, my email addresses and domain names have often been "hijacked" by forgers who send spam. But I consider SPF to be an insufficiently robust design and implementation to address this problem within the present Internet email system (which is based on SMTP), and I'm not convinced any SMTP-based system can (or even should) be sufficiently secured against forgery.

SPF and similar authentication schemes, such as DomainKeys, can be used to "tag" incoming email rather than just block it. A benefit of such tagging might be that incoming mail tagged as "not authenticated" or "likely forgery" is delivered to a lower-priority "inbox" for a recipient. As long as the recipient ultimately reads the email and can decide whether it is worth following up on, improperly tagging email (as a result of any of SPF's problems) isn't necessarily a big problem.

However, if the result of an improperly tagged email is that the email is never read and never bounced, a legitimate sender of such email is left believing either the email has been received and read, or that no email he sends is necessarily getting through.

And that represents a huge problem with almost any SMTP-based anti-spam measure, such as SPF: to the extent they increase the likelihood that legitimate mail is "dropped" (accepted, but never delivered nor bounced back to the sender), they decrease the sender's confidence in the system and the usefulness of the bounce mechanism (which is an expensive mechanism in the first place). Absent some other means of verifying that a message got through (perhaps in the form of the recipient responding to the message), SMTP provides no reliable means to verify that a message has not been dropped (essentially, deleted).

Other problems with SPF and similar schemes include excessive reliance on the DNS system, which can increase latencies (add delays) to the receiving of incoming email by each SMTP server that handles it.

I consider SPF to be just one of many Challenge/Response systems intended to improve email exchange, all of which degrade it in one way or another for legitimate use without sufficiently devaluing it for abuse by spammers or vermin authors.

Back to my "postmaster" page.