Email Authentication – You’re probably doing it wrong.

"Email Authentication has been around for many years now, over a decade already, and yet I still see many companies doing it wrong. Sure, you’re likely publishing your SPF, Sender ID records, possibly one of or both DKIM and Domain Keys, but probably only because your ESP forced you to."

Email Authentication has been around for many years now, over a decade already, and yet I still see many companies doing it wrong.  Sure, you’re likely publishing your SPF, Sender ID records, possibly one of or both DKIM and Domain Keys, but probably only because your ESP forced you to. 

But that is a good thing right? How could it be wrong if my ESP is doing it for me? I mean, that’s what I hired them for. True, the knowledge to properly manage and build an infrastructure that can sign thousands, or millions, of email messages effectively is what ESPs build into their solutions and in turn manage for their clients. 

Even with your ESP looking out for you, chances are you are still authenticating wrong.

Forgetting your corporate domain

You have your marketing domains covered, but what about your corporate domains or parked domains, are you authenticating those?  This is the most common offence of authentication failure I see.  When working with a marketer to properly protect their users, most ESPs focus on just the mail they plan on sending.  I mean why worry about stuff that is not being sent from your network?  Take the time to talk to your IT team about reviewing your corporate mailing setup.

Stuck in testing mode

While less common, many people are still using one of these authentication flags: ~all, ?all +all, or DKIM t=y for their email. These flags all indicate that you are in a testing mode or that you’re unsure of where you send mail from. I have yet to see a mailing infrastructure so vast that building a valid SPF or Sender ID records is a significant challenge. Start in testing mode but remember to promote your records to an active state over time. Forgetting to protect your corporate domain can be disastrous for your end users and a nightmare for your branding team.

Authenticating only some mail

Mailing from multiple sources can be time consuming and confusing when it comes to Authentication – you have your corporate mail servers and web servers triggering from another place (potentially multiple places), and your ESP(s) not to mention your commercial vs. transactional mail servers if you have them separated. Keeping tabs on all of this mail can be a daunting task. Being organized and understanding all of your organization’s mail server locations, on–site and off, are key to maintaining a healthy authentication program.  Not to mention that resources and your infrastructure may change due to other priorities within your organization. These records should regularly be reviewed. 

You don’t know how BIG the problem is

Well you are in luck! With the launch of DMARC [http://www.dmarc.org] (Domain-based Message Authentication, Reporting & Conformance) your infrastructure and security team can begin to receive reports of all the IP addresses that claim to send email from your domains.  After you get SPF and DKIM in place, DMARC allows you to set a policy on how your mail should be treated by the recipient mail servers (report only/fail to junk/fail and reject). 

DMARC also allows you as the domain owner to request summary reports of all the mail seen and the IP Addresses these messages are sourced from. These reports will easily allow your Security and IT teams to validate your true mail servers (if you missed any in your authentication records) and identify others that are potentially being used for more nefarious reasons. There are many reporting services that will take these reports and turn them into graphs and aggregate the data to make interpretation of the data easier.

Testing your authentication setup

First off get a list of your domains - all of them even the ones you are not actively mailing from.  Yes these domains should be authenticated too, even if the records simply says no mail is sent from this domain (i.e., “spf v=1 -all”).  Send yourself an email to an @outlook.com email account and view the message source. This will show you the headers of the email where you can review the line reading “Authentication results”.
It will look something like this:

Authentication-Results: hotmail.com; spf=pass (sender IP is 209.85.223.169; identity alignment result is pass and alignment mode is relaxed) smtp.mailfrom=example@gmail.com; dkim=pass (identity alignment result is pass and alignment mode is relaxed) header.d=gmail.com; x-hmca=pass header.id=example@gmail.com

Find the SPF and DKIM results, if you are properly authenticating you will see “pass”. If not you will see “none” or “fail” messages. If the DKIM record fails, look further down in the header and you should see a line that reads “DKIM-Signature” or “Domain Key-Signature“. Seeing these validates that you are using one of these technologies (Note: DKIM is the latest version of Domain Keys so you should upgrade when you get the chance).  If both of these are missing you are not currently publishing these records for this particular message stream. This should be addressed with your IT team or your ESP immediately.

Final thoughts

In summary, authenticating your email is important, but more importantly is properly authenticating all of your email messaging.  These ideas will (hopefully) help you find the holes in your current authentication process and help protect your users and your brand.  To quote a good cliché: “Your team only as strong as the weakest player.” Don’t let poor authentication practices be your weak player. There’s just too much at risk.