Getting into the inbox, part five: Authentication

Email Deliverability Series, Part Five.

Getting into the inbox:
Why use authentication technologies? What our tests reveal.

How do SenderID, SPF and DomainKeys affect me as an email sender?

Remember those emails from eBay and major banks asking you to verify your account information? They looked real. They had the right From address and the official logos. But they were phishing scams, trying to steal your account information.

In previous articles we have covered what you as an email sender need to know about content filtering, whitelists and blacklists—the tools email administrators and ISP's use to keep spam out of their email systems.

In this issue, we'll cover the authentication technologies that may be used to help prevent spoofing and phishing spam, and reveal our test results which show if implementing authentication will help or hurt your email deliverability.

If you have no interest in the technology side of the email marketing, then you can stop reading after our surpise recommendation below (please note that not all our newsletters will be so techy).

Surprise recommendation: While many email marketing providers are pushing authentication, today there is no penalty for not using authentication, in fact, our tests show your deliverability will be better without it.

Being pragmatic, we can't recommend implementing authentication at this time.

There is no doubt that authentication will be more widely used in the future, so you may want to read the rest of this article to learn more about how it works as well as the risks and benefits.

While authentication is yet another technical subject, this article will provide you with a basic understanding of authentication technologies such as SenderID, Sender Policy Framework (SPF) and DomainKeys.

We have also provided links to the more technical aspects, because any authentication implementation will require modifications to your DNS record, and will need to be done by your email or internet administrator.

What is Authentication for?

The idea behind authentication is to verify that an email is really coming from the sender displayed in the From field. The goal is to reduce spoofing, phishing and spam by authenticating the sender.

Authentication is useful if you are sending from an organization, such as a bank or financial institution who needs to prove they are the actual sender.

Online email systems make it relatively easy to forge the sent From display text, by changing the From and Reply-To fields within the email message header, it makes the email appear to be from someone other than the actual sender. While this may be useful in some cases, for instance, when you want you message to appear to be Newsletter at YourCompany, it is also the root of the ebay and bank email phishing scams which asked people to confirm their account information. At first glance they looked like authentic emails, with the right from address and logos, but they were not.

Authentication is supposed to help this situation, although it does nothing to stop people from spoofing the message header, it does provide a means to determine if the sender is authentic.

But making authentication work requires two things 1) The sender has to publish a record of email servers (domains) authorized to send email or publish an encrypted key to sign the email, and 2) The receiver has to implement an authentication check as part of their anti-spam protocol.

Unfortunately today, the majority of email receiver's (ISP's, mail providers, corporate exchange admins) DO NOT implement a strict authentication check on incoming email. And even when they do a check, most do not enforce the case where no authentication record exists. In other words, if you don't have authentication set-up, it passes.

How does it work?

Authentication only works when the receiving email server is set-up to run an authentication check as part of their spam detection method.

If the authentication checks out, then the email passes. If the authentication fails, the email is rejected (put into the spam folder or just dropped).

However, if there is no authentication technology available, most systems will pass the email through.

Also, most mail servers do not yet support authentication checking natively, although there are plug-ins available.

What's the benefit?

If your business domain is subject to spoofing or phishing attacks, then authentication can help prevent it.

What's the risk?

If your authentication is set-up incorrectly, or does not include every possible sending domain (including automated web mail, forwarding services and outside email service providers) then your email is more likely to be rejected than if it did not have authentication at all! Your deliverability may actually decrease.

Even worse, there are known conflicts between SPF and SenderID which may cause the authentication check to return a false positive (failed), which is a negitive for you. Even if you have your SPF record set-up correctly, a server checking for SenderID may reject your email.

What's the bottom line?

Unless your business is subject to spoofing or phishing attacks, we can not recommend implementing authentication at this time. Once ISP's and email administrators being enforcing authentication AND reject email without some form of authentication, then setting up authentication will be a priority. So long as there is no penalty for not having it, then why do it?

We support the concept behind authentication. However, in practice, you are better off today without authentication than with it.

Next issue: Deliverability best practices

Got SenderID?

Is your domain authenticated?
Run our free SPF check here...

Just Released:
PoliteMail Online Training Video

The About.com email marketing
guide rated PoliteMail 2.0
4½ stars out of 5.

Authentication Technologies Defined:

In general, authentication technology works by comparing information included in the email envelope (the undisplayed email header containing the To: From: and other routing information) with a record or key created and stored by the official owner of the sending email domain.

SPF
Sender Policy Framework
An open standard specification and method to prevent sender address forgery. Domain owners publish records via DNS that describe their policy for which machines are authorized to use their domain in the HELO and MAIL FROM address fields within the email header envelope.

The largest ISP using SPF as part of their incoming spam check is AOL. Other email providers such as Bellsouth, Charter, Earthlink, Google Gmail, Juno, Road Runner and Verizon also use SPF.

http://www.openspf.org/

SenderID
An authentication protocol based upon SPF and promoted by Microsoft.

SenderID validates the sender according to an algorithm called PRA (Purported Responsible Address) different from SPF. There are some potential conflicts with SPF which may cause false positives (falsely rejected email).

SenderID is primarily utilized by Hotmail and Microsoft Live Mail.

http://www.microsoft.com/senderid

DomainKeys/DKIM
Initially developed by Yahoo! and now enhanced with Cisco's Identified Mail as DomainKeys Indentified Mail (DKIM). Provides authentication through the use of digitial signatures (encrypted keys) to sign each outgoing email, which is then verified by the receiving server.

DomainKeys is utilized by Yahoo!, Google and EarthLink.

http://antispam.yahoo.com/domainkeys

http://www.dkim.org/