SPF 2005 is not a superpowered suntan lotion. Sender Policy Framework is one of the new technologies in the battle against spam, and we're hoping it will help reduce our e-mail problems in the future. If the e-mail servers that bounced all those messages to ACME had used SPF, we would not have received their autogenerated replies.
Here's how it works. When an e-mail server using SPF receives a message, it does an SPF lookup via DNS (Domain Name System) and verifies that the sending e-mail server is valid for the domain of your address. To make SPF work, you must put an SPF record in your DNS that specifies the valid e-mail servers for your domain. Then you configure your antispam solutions to check for SPF records from sender domains, adding weights--pass, fail, soft fail or neutral--to the results of the lookup. For the DNS faint-of-heart, there's an SPF Record Wizard available.
Pleading With Peers
We've been using SPF on our e-mail servers, but for it to really make a difference, its use must be widespread. Our recommendation: Embrace SPF, and update your DNS records and SMTP antispam checking accordingly. Don't send autoreplies from the user level or server level to the Internet--why tell everyone a specific user doesn't exist on your server? Remind your employees not to try the "unsubscribe" link on junk e-mail--it usually makes things worse. I've heard of at least one company that is blocking all incoming messages from the free e-mail services--ACME isn't going that far yet, but the idea has some merit. Spam may seem like a minor annoyance to your users, but when it gets out of hand and affects infrastructure performance and employee productivity, it's serious business.