The miracle of DomainKeys

I work for a company that has in-house software for sending email bulletins to registered customers. The largest problem has been fighting off the major email providers — Rogers, Sympatico, MSN/Hotmail and Google — from flagging these messages as spam.

For some, just making sure that you have a correctly configured MX entry in your DNS along with a proper reverse lookup on the IP is enough. Of course, you usually have to talk to your ISP about reverse lookups, even if you have your own DNS server. If you're a big enough company that you own your own block of IPs, then make your cheques payable to me at...

SPF is a step forward -- it works sort of like a "call-display" for email servers. Your mail server knows what IP is connecting to send the message and can look up the SPF record to see if this IP is allowed to send messages for that domain. However, for some ISPs and mail providers, this still isn't strong enough.

DomainKeys was first introduced by Yahoo! and was then developed further by other major messaging providers to become an open standard. It works on the principle that if you're a spammer, you won't have your own domain necessarily, or a DNS server under your control that you can post public encryption keys to, or be willing to invest the computational time required to digitally sign some of your email headers. (In the last case, the time really is only fractions of a second, but when you need to send out millions of messages quickly before you get caught, every millisecond counts.)

There are plenty of good tutorials on how to set up DomainKeys, so I won't go through step-by-step here. However, I can give you the general picture of what needs to be done. You will need:

• a mail server that supports DomainKeys
• a public/private key pair
• the ability to post a text record to the DNS server for your domain

Once you generate the public/private key pair, you tell your mail server the location of your private key and select which headers you wish to sign. Under the principle of non-repudiation, I generally flag the Date, From, To, Subject and Message ID headers to be signed by the DomainKeys private key.

After this is configured, you need to publish your DomainKeys public key so that other mail servers are able to verify the digital signatures on those message headers. This is accomplished by two DNS TXT records. The first is a policy record published as _domainkey.yourdomain and simply states whether or not all messages are signed and how seriously you are using DomainKeys. A good way to start is to set the text to "t=y o=~". this tells everyone you're in testing mode and that some messages may not be signed. You can tighten this up after you've confirmed everything is working.

The second is the selector record which contains the actual public key. This is published to your DNS as selectorname._domainkey.domain and in its simplest form contains "p=" followed by the long garbled string of characters that is your DomainKeys public key. There are other options available, such as being able to explicitly declare cipher type, length, etc. but this information is enough to get things started. Your mail server software also needs to be told the name of your selector record as that information is included in the message headers.

That's it.

The biggest protection this provides is proof that a message really did come from your domain. As many spammers try to spoof the message sender's address in order to bypass more simplistic email filters, this is a way of proving whether or not a message really was delivered from your mail server or not. At least for now.