Last month, Google Mail started displaying an icon on emails that it can't verify as the legitimate sender. This used to be a Google Labs feature that you had to turn on yourself, but as of last month, Google rolled out an update to enable this feature for all users by default.
Why does this matter? Google Mail users will see a notice like so:
As time goes on, more and more businesses will set up their verification methods correctly and users might consider unauthenticated mail as spam, junk, or worse.
How do we set up authentication then? Our favorite mass mailing service Mailchimp has a great guide on the 3 authentication methods available today, along with a chart of support with mail providers. Mailchimp as a sender supports all 3 methods, but only if you configure your DNS. In fact, all 3 methods use DNS TXT records as the way your email provider checks for authentication.
SPF - Sender Policy Framework
SPF is the most commonly accepted means of authentication, and easiest to implement. The syntax guide is available here. All you need to do is create a TXT record for your domain (like genaro.com) with the value set as the appropriate syntax. For example, we have a webserver (genaro.com) that can send email, our primary email service (google apps for business), and our mass mailing service (mailchimp). Our SPF record value would be like so:
v=spf1 a:genaro.com include:_spf.google.com include:servers.mcsv.net ~all
- v=spf1 means this is a SPF rule
- a:genaro.com means allow the server with an A record at genaro.com (our webserver)
- include:_spf.google.com means give a pass if it is in the server list included at _spf.google.com (google mail)
- include:servers.mcsv.net means give a pass if it is in the server list included at servers.mcsv.net (mailchimp)
- ~all means anything in this list is allowed, if not then give a soft failure warning. A soft fail in gmail shows the unauthenticated message, while a hard fail (-all) may be sent directly to the spam box or blocked completely.
If you use an email server controlled by you, you will want to make use of the mx rule.
Sender ID is a method proposed by Microsoft based on SPF, but has some changes to its features. Although it is denoted with v=spf2.0, it is not actually SPF version 2, rather it was an independent project that is now obsolete. Here is an article that explains some of the key differences. The SPF working group recommends that you can use v=spf2.0/mfrom to make it similar to SPF.
v=spf2.0/mfrom,pra would actually be more secure in theory, but it requires more configuration when you send mail. In practice it has shown to create a significant amount of rejected mail.
DKIM - DomainKeys Identified Mail
DKIM was created by Yahoo and is a bit different than the two methods above, in that it uses public key encryption and also requires an authentication string to be embedded into the email header. By doing this, it verifies that it was sent by a server authorized by you, and that the message was not tampered with in transit.
It is important to note that if you implement this method, all of your mail servers have to be capable of inserting the DKIM-Signature header into all outgoing emails.
First, you need to create the public and private key pair. A typical setup uses 1024-bit RSA encryption. Some mail services have a tool to let you do this (such as google). When asked for a selector, pick a simple word to describe this key, it can be anything but remember it for later. As with all public/private keys, keep the private key safe and secure - if someone else gets a hold of it, your security is compromised.
Like SPF, you need to create a DNS TXT record that reads like this:
where yourpublickeystring is the 1024 bit public key that you generated. There should be no line breaks in the string.
On your email server side, you need to turn on DKIM so that it sends out the DKIM-Signature header. If you used it to create the key pair, it already has the information needed to do this. Otherwise, you will need to configure it, probably by providing both the private and public keys, and the selector you chose when creating the key. Again, make sure the private key is secure and only readable by the email server software.
Here is an example DKIM-Signature from the DKIM wiki page:
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938; h=from:to:subject:date:keywords:keywords; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR
- d is the domain
- s is the selector you chose
- h is the list of header fields that are included in the header hash
- bh and b are the encrypted hashes of your email headers and email content
Email authentication is important to implement now that Google is displaying an icon for unauthenticated senders.
The easiest method to implement is SPF, and is widely accepted by many email providers.
DKIM adds an extra layer of security, but requires extra configuration on everything that sends email from your domain.