Sending Encrypted Messages

There are many ways to send email from your application. Only a few of them are worth trusting your company’s messaging to, and even fewer are able to send a high volume encrypted messages to your end users. This is the story of how SparkPost makes sending encrypted messages possible for anyone to achieve.

First, it is important to point out that we normally recommend not sending anything that needs to be encrypted over email. Personal, secure information is better handled through a direct web portal with an SSL connection if at all possible, but the reality is that stuff happens and at some point, you may find yourself writing a function to send customer financial statements as an attachment over email by the thousands.

On the surface, this does not sound that hard. Surely there must be an easy way to encrypt messages and send them to people. You could simply “pdf” or “zip” an attachment with a password, or use PGP to encrypt the whole payload, but then how do you get the cypher key to the end user or decryption? Before you know it, the project to manage encryption keys has dwarfed the original work needed to just send the message.

SparkPost users can leverage our partner integration with Echoworx to encrypt the entire email, including any attachments, and send at high volume as needed. The key management is all handled by the Echoworx application which notifies recipients, provides a secure dashboard and sends notification in multiple languages.

Using Echoworx

Echoworx can work as a plug-in or as a separate cloud service. SparkPost’s integration leverages the Echoworx cloud service which directly feeds your own SparkPost cloud account. The general topology is drawn below and shows how you can generate messages from your own creation system and choose to direct traffic to the Echoworx encryption engine or through SparkPost directly. This way you can selectively encrypt the messages that require it and send your other messages unencrypted but see all the delivery results inside SparkPost.

When Echoworx encrypts the message, it then sends a notification to the end user that there is an encrypted message available as shown in the sample below. This is sent in multiple languages and redirects the recipient to the Echoworx portal for decryption of the message.


Echoworx represents a separate partner agreement to SparkPost, so you can choose to use it or not, and it does not affect your SparkPost account. You can find more information about Echoworx on our Partner Page or at the Echoworx site directly.

Want to join our partner program? Find out more here. If you have any questions or comments about encrypted messages feel free to tweet us or drop us a note in our community slack.


Google, Microsoft and Yahoo are failing your DKIM keys? You’re not alone.

By now, just about everyone in the email/messaging/Internet world has heard about Zachary Harris, the mathematician in Florida who uncovered the fact that Google corporate was using weak  512-bit encryption in its email, and how that discovery has snowballed into most of the big ISPs now rejecting email signed with encryption keys less than 1,024 bits in length. You can read the original Wired story or this blogpost from Return Path’s Ken Takahashi for more context.

The whole episode is a good thing in that it’s shined a light on the problem that many senders are still using weak 512-bit or 768-bit encryption. Yet it’s a bad thing in that since many senders haven’t fully come into DKIM compliance yet (the DKIM standard calls for encryption keys at least 1,024 bits) they’re now seeing mailings fail. We’ve long advised our users to upgrade to the 1024-bit DKIM standard, and now it’s really no longer an option.

To upgrade the strength of your DKIM keys to 1024-bit, here are some helpful instructions:

First, MAAWG has published some best practices guidelines that provide a great starting point if you need to upgrade from 512-bit or 768-bit encryption:

  • Use a minimum 1024-bit DKIM key length to increase key complexity, as shorter keys, such as 512-bit, are inadequate.
  • Keys should be rotated quarterly to reduce the period of time the key could be used to compromise the integrity of email.
  • Signatures should have an expiration period greater than your current key rotation period.
  • The “t=y” declaration is for testing only.
  • To be able to monitor how receivers are accepting email signed with DKIM, it is recommended to implement DMARC with a “p=none” (a.k.a. “monitoring mode”) policy.
  •  Domain Keys is a deprecated protocol; use DKIM instead.
  • Organizations should be engaged with anyone sending mail on their behalf and ensure that their third party email service providers adhere to these same best practices.

Additionally, you’ll also want to decide if you are going to replace the DKIM keys and selector in place, or change over and start signing with new keys and selector. Starting to sign with new keys is probably the optimal decision. Replacing the keys in place will result in any messages that have already been signed, and are in the queue, to fail DKIM validation after you update your DNS record.

We have documentation on the DKIM module on our support site, and for any of our users, we recommend that you consult that material. If you have any questions, please contact our support team and we’ll be in touch.

Learn more about DMARC, the industry’s email authentication standard with our How DMARC Is Saving Email eBook.

How DMARC Is Saving Email