Article: Email Authentication Explained

Email authentication can be tricky to explain, and even trickier to understand when attempting to troubleshoot. I'm sure you've gotten an email at some point that looked completely legitimate. The pictures looked right, the margins were good, the spelling was spot-on, and logo was exactly like you've seen it a million times, yet it was somehow a forgery. The internet community as a whole has been fighting this type of spam for over a decade. So it comes as no surprise that the recent changes by Yahoo, AOL, and Gmail have all but made it mandatory to have authentication measures in place. It's unfortunate that the internet has put the onus on the good senders rather than the bad senders to prove who they are. Yet, every domain has a slightly different take on authenticating the from address when receiving an email.

So then, who is checking for what authentication?

As you can see above, no one email provider checks for all four methods of authentication. This is actually rather easy to explain – not all methods of authentication are equal. Some have been deprecated.

SPF – Sender Policy Framework

"is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages."[1] This system asks the question "Are you who you say you are?", and based on the answer, will decide the legitimacy of your message.

SenderID [deprecated]

"Is an anti-spoofing proposal from the former MARID IETF working group that tried to join Sender Policy Framework (SPF) and Caller ID."[2] SenderID, although never fully adopted, was a bold attempt at improving the shortcomings of SPF. However, there were some compatibility issues with SPF, and its widespread use was appealed due to Microsoft holding many patents that would be core to the structure of SenderID's adoption, which stands in contrast to SPF, a completely open standard.

DKIM – DomainKeys Identified Mail

The result of merging the DomainKeys standard with the Identified Internet Mail standard, "this system allows receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. A digital signature included with the message can be validated by the recipient using the signer's public key published in the DNS."[3] This system is the successor to Domainkeys. Although very similar in functionality, it has some key improvements, including the ability to delegate signing to third parties, the ability for DKIM to self-sign the DKIM-Signature header field (to protect against its being modified), and the ability to support signature timeouts in DNS.

DomainKeys [deprecated]

Published alongside DKIM in of May 2007, DomainKeys was issued as a "historical" protocol and DKIM was issued as its standards-track replacement. When most people talk about 'Domainkeys', they are usually referring to DKIM, as the two protocols are so similar.

Email authentication shouldn't be hard to implement, so we are here to help. JangoMail's goal is to have our customers sending in the safest way possible. To this end, we offer VIP service to help you in making these DNS changes. In fact, we can even register a custom domain and complete all the setup for you!

Just remember: email authentication is not the end game for making sure your messages land in the inbox. You also need a well-balanced message with HTML, plain text, images, and good content to go along with it. A message with bad content, but good authentication is as useless as a message with good content and no authentication.

Sources: [1] OpenSPF web page; [2] Wikipedia Article; [3] Wikipedia Article, Linked by dkim.org;