Best Practices Using Custom DKIM Signatures
Since the SocketLabs SMTP relay service SocketLabs On-Demand first started processing messages back in 2009 we’ve added tons of awesome new features to improve the deliverability of our customers’ email messages. Serving as SocketLabs’ Lead Deliverability Analyst, I’ve never been as excited about a feature as I am about the customizable DKIM options we added earlier this year. I’ve spent a considerable amount of time promoting the benefits to our user base and I want to review some best practices in today’s blog article.
Note: Currently customizable DKIM signatures are only available to customers on Bronze or higher service plans. SocketLabs does have plans to enable this feature to a wider range of users in a future update.
What exactly is DKIM?
What is DKIM? DomainKeys Identified Mail (DKIM) is a popular email authentication technology that allows for a domain to prove it is responsible for a message and it was not altered as it traveled the delivery path.
The basis of DKIM is that messages can be authenticated in a non-path related method with the use of public keys published into DNS. The authentication process revolves around the creation and decoding of what is called the DKIM signature. DKIM signatures are inserted into the header of an email message. A hash of the body and select header items is created and used in a calculation along with a private key value to create a message signature that can be decoded properly only with the public key which is posted in a domain’s DNS. It’s also good to note that taking preventative measures can help keep you stay vigilant against DKIM replay attacks.
DKIM and SocketLabs On-Demand
Each and every message that processes through the SocketLabs On-Demand Platform is automatically signed with a DKIM signature that authenticates email-od.com as the point of origin for your messages. This allows every message processed on our platform to properly authenticate at the major service providers.
Our recently upgraded customizable DKIM signature options allow for a second DKIM signature to be added to the headers of your email messages using your own domain. This second signature allows for an increased level of authentication and better message branding.
Note: Custom DKIM signatures are only added to messages that purport to originate from the domain in which a custom signature setting is established. Please see our DKIM knowledge-base articles for more information.
Standard Implementation of DKIM customization on the SocketLabs On-Demand platform
First we will take a look at the most common use case of SocketLabs service, delivery of messages on behalf of a single domain. Whether it be transactional, smart host, or marketing email messages most customers send on behalf of a single private domain. Adding a custom DKIM signature from the primary sending domain will make a quick and noticeable impact. Take a look at the following screenshots of a sample message sent to Gmail with and without a custom DKIM signature.
Test email message without a custom DKIM signature:
Test email message with a custom signature:
As you can see above, adding the customized DKIM signature removed the “via” tag from displaying in the Gmail web client. Gmail displays the “via” tag to inform message recipients when a domain that is different than the From address was responsible for the authentication mechanisms.
Advanced implementation of DKIM customization on the SocketLabs On-Demand platform
When you want to send email on behalf of an email address outside of your own domain, properly utilizing a custom DKIM signature can brand your messages in a unique way. For the following example we will pretend that [email protected] found a product that he likes on e-commerce store customerexample.com and he wants to share this product with his friend [email protected]
There are many different approaches on how to send this message. First, you could send the message from “[email protected]”, but when the message is received by [email protected] he will be less likely to know that is it being sent by his friend [email protected] This will increase the rate at which the end-recipients mark the email as possible SPAM and this could cause deliverability issues. The benefit is that the message would be strongly branded and properly authenticated increasing message deliverability.
The other option is to use the from address of [email protected] The benefit to this is that if [email protected] is in the address book for [email protected] then the message will skip SPAM filtering and land directly in the inbox. The from address will also look familiar to [email protected] and he may be more likely to open the message. The draw back is yahoo.com will not authenticate your message and it could be blocked and never reach the end recipient. Sending messages that purport to originate from a public domain is also against the SocketLabs Usage Policy.
The good news is that with proper message formatting and the use of custom DKIM signatures you can get the best of both methods. You can get the from address familiarity and the branding you want your messages to convey, all while allowing the message to properly authenticate and avoid getting blocked. This is accomplished by the inclusion of the Sender header field. This value, outlined in more detail in our knowledge-base article here, allows you to take responsibility as the sender of the email message on behalf of a different from address.
Take a look at the following pair of screenshots, you will see that the “via” tag in the Gmail web client changes from email-od.com to customerexample.com.
Test email message using a third-party-domain-based from address without a sender header line and no custom DKIM signature:
Test email message using a third-party-domain-based from address with a sender header specified and a custom DKIM signature:
For reference below I’ve provided the full message source of the test message with a sender header and custom DKIM signature. Specifically I’ve singled out the custom DKIM signature and it is highlighted in blue:
Delivered-To: [email protected]
Received: by 10.194.242.198 with SMTP id ws6csp338839wjc;
Fri, 2 Aug 2013 10:21:40 -0700 (PDT)
X-Received: by 10.66.119.35 with SMTP id kr3mr11718735pab.149.1375464099934;
Fri, 02 Aug 2013 10:21:39 -0700 (PDT)
Return-Path: <[email protected]>
Received: from bca5.email-od.com (bca5.email-od.com. [220.127.116.11])
by mx.google.com with ESMTP id xq4si7745592pab.28.2013.08.02.10.21.39
for <[email protected]>;
Fri, 02 Aug 2013 10:21:39 -0700 (PDT)
Received-SPF: pass (google.com: domain of [email protected] designates 18.104.22.168 as permitted sender) client-ip=22.214.171.124;
spf=pass (google.com: domain of [email protected] designates 126.96.36.199 as permitted sender) [email protected];
The example above can be applied to any other form field on a website, and many other situations. If you have any questions on how you can best utlize DKIM signatures in your messages don’t hesitate to contact the SocketLabs Support Team at [email protected]