Implementing SenderID Framework records for my e-mail server

This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I recently read Craig Spiezle and Alexander Nikolayev’s TechNet Magazine article about the SenderID Framework (SIDF) – one of the available schemes to validate mail servers in the fight to reduce unsolicited commercial e-mail (UCE), more commonly known as spam.

SIDF is similar to the Sender Policy Framework (SPF) in that it uses specially-formatted TXT records in DNS (called SPF records) to detail the mail exchange (MX) servers that SMTP e-mail may originate from for a given domain, and any other domain names that may be used.

I’d decided some time ago to implement an SPF record for my domains but my hosting service provider at the time did not support the use of TXT records. Since I moved to ascomi a few months back that’s not been an issue and last night I finally requested that the changes were made.

There are a variety of tools online to help create SPF records, but the first problem I had was the need to decide whether to use OpenSPF, SenderID, or an alternative (such as Domain Keys). In the end, I decided to go with SenderID – largely because the Microsoft SenderID website helped me create an SPF record which supported the both SenderID Mail From method (identical to the SPF method) and the SenderID Purportedly Responsible Address (PRA) header method. Finally, to validate that my record was correct, I sent an e-mail to check-auth@verifier.port25.com and used the Email Service Provider Coalition verification tools – Microsoft also publishes a short implementation guide for SIDF which is worth a read.

The differences between SPF formats are discussed on the OpenSPF site too (and OpenSPF also has tools to help create the necessary records) but the OpenSPF guys seem to be more interested in saying why SenderID violates the standards and shouldn’t really be called SPF (I call that the “not invented here” syndrome) than in actually helping people work out how to stop spam.

It’s also worth pointing out that my SPF record will not directly affect the volume of spam that I receive; it will, however, help others who perform SPF lookups to determine if mail that appears to come from one of my domains really originated from a server which I authorised. Even then, they may elect to retain the message, or they may drop it – that’s no different to today but as more and more SPF records are published, the volume of spam on the Internet should drop considerably as all messages are effectively authenticated as having passed through an authorised MX for the stated domain name.

One thought on “Implementing SenderID Framework records for my e-mail server

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.