Implementing Sender Policy Framework (SPF)

Ever received a spam message supposedly from yourself or another existing or non-existing account at your domain? If so, you’ve experienced email spoofing where messages are forged or made to appear as though they originate from your server. If you’re the email administrator for your domain, you certainly know the frustration trying to explain to your clients that these messages do not actually originate from your server.

Another unwanted consequence of email spoofing occurs when spammers forge your email address as the sending or reply-to address in their spam messages. When these messages cannot be delivered to invalid mailboxes, your address receives hundreds or thousands of bounce messages.

How do you prevent email spoofing? Unfortunately, standard SMTP alone does not prevent this type of spam. In short, anyone can specify any email address in the return path header. However, implementing a Sender Policy Framework (SPF) can prevent SMTP forgeries and mitigate the undesireable effects of email spoofing.

What is SPF? Sender Policy Framework allows domain owners to specify valid sending servers in the DNS zone records for a domain. How does SPF work? Like a reverse lookup for email, SPF lets receiving servers verify that sending servers are in fact authorized to send mail for specific domains. In practice, when a message is received from someone@somedomain.com, the receiving server looks up the SPF entry in the DNS for somedomain.com. If the sending server matches the server specified in the SPF entry, then the message is accepted by the receiving server.

For more information on generating an SPF entry for your domain, check out:
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/