- Developer Hub
- SparkPost API
- Email Tools
- Slack Channel
- User Guides & Migrations
- Submit a Ticket
- SparkPost Academy
- Deliverability Guide
- Email Explained
- White Papers & Guides
- Webinars & Videos
- SparkPost vs. SendGrid
- Contact Us
DKIM Validator by SparkPost
You might have heard about our shiny new DKIM Validator, since we announced recently in our newsletter. In this post, we’re going to show you how we built it.
We talked about the “why” and “how” of DKIM in Ewan’s blog post last week. I’m guessing that a very common reaction was “it’s complicated”, which it is, because crypto. We’ve written before about why DKIM exists and how it works, even publishing a shiny infographic.
So let’s dive into the details. How did we build our DKIM Validator?
It Takes Two to DKIM
DKIM protects messages between Alice and Bob from Mallory, who wants to modify them. When Alice sends a message to Bob that includes a DKIM signature, Bob can prove the received message is exactly what Alice sent. Proving that a message hasn’t changed is a similar operation to signing it. However, it’s different enough that you need to use different tools.
We use quite a lot of Node.js under the hood of our service. As it turns out, there wasn’t a Node.js module that could verify messages signed with DKIM. Several options existed for signing messages. So we picked the one that seemed most active, with the most thorough tests, and got to work adding what we needed. We made sure to return intuitive, diagnostic-quality error messages when validation fails, since our goal is helping you fix the right problem when something’s busted.
Testing code involving crypto is hard. Validating messages with the same module used to sign them would result in a sort of echo chamber effect where bugs get ignored, because they’re our bugs. We settled on signing messages using OpenDKIM’s testing tools, then validating those signed messages in our test suite to avoid as many echoes as possible. That ended up resulting in some pull… er, merge requests to OpenDKIM to make their testing tools able to easily generate a wider variety of signatures.
SMTP, API, UI, Oh My!
Since SparkPost runs primarily on Amazon’s cloud, we quickly spun up some PostgreSQL RDS instances to store generated test addresses, and any associated DKIM verification results. We use flyway to apply any changes to our database schema. Bamboo deploys the API components to an existing tier of servers, which listen for HTTP requests coming in from the tool’s interface.
With the hard part out of the way, next we wired our shiny new DKIM validator up to a SparkPost account, because dogfooding your own service is good for everybody. That account has an Inbound Domain and Relay Webhook configured to accept your test messages via SMTP, transform to JSON, and pass them through to the validator’s back end for storage and processing.
Validating your DKIM configuration with a test message is simple:
- Generate a test address
- Send mail from the system being tested, to that address
- View results (on failure, fix & GOTO 1)
And that’s it!
With a few clicks, including one on a “send” button, you’ve confirmed that your messages are being DKIM signed! And because they were sent only to us at SparkPost, you didn’t have to worry about any damage to your domain reputation if there was an error. Mailbox providers will now see your DKIM signatures and know it’s you sending that email. And no, nobody injected any spam or malware-ified any links along the way. Because if they try, DKIM protects your subscribers and customers by raising a red flag.
So go ahead, test your email with our DKIM testing tool – you know you want to! If you have any questions about DKIM, or email, or ideas for improvements, tweet @SparkPostDev. Feel free to also join our slack community!
–DaveSparkPost © 2018 All Rights Reserved