DKIM Troubleshooting Series: Why is My Signature Not Validating?

Hello and welcome to the fifth entry in the Amazon SES DKIM troubleshooting blog series. We have begun the task of setting up DKIM for a domain and overcome a great variety of DNS issues, to succeed in getting the signature to appear in our emails. This is when the next problem manifests itself: the DKIM signature we’ve worked so hard for is invalid.

My emails are now signed but I see a DNS validation error when viewing message headers

Finally, the so-far elusive DKIM-Signature header appears in our outgoing emails. But we cannot rejoice yet, because it looks like our hard-earned signature is not validating. We see a dkim=temperror message in our inbox. What could be happening now?

Occasionally, temporary DKIM validation errors by ISPs can appear, such as dkim=temperror. These could be due to a DNS glitch causing problems retrieving the public key record. The first thing to do is to confirm that our DNS is properly set up (see previous blog post). Next, we can try sending emails to addresses belonging to different ISPs. If only one ISP shows DKIM validation failures, that specific ISP could be having some trouble retrieving DNS records.

For our scenario, let’s suppose that half of our emails going to a certain ISP showed this header in our email client::

Authentication-Results: <ISP domain>; spf=pass (sender IP is 199.255.192.105) smtp.mailfrom=0000013c1f0b78ac-aba21a53-f2a4-4bc4-9fd0-7138018d372e-000000@amazonses.com; dkim=temperror header.d=ses-example.com; x-hmca=none

What we can do is send test emails to other major ISPs. If they regularly validate DKIM, it could be a problem with that specific ISP’s DNS resolver setup. If we see these kinds of errors appearing across all of the ISPs, we may want to confirm with our DNS provider whether our servers are constantly up, and serving correct results to all requests.

For this scenario, let’s assume that we have confirmed that our DNS is fine, and, after waiting a while, we’re no longer seeing any DNS validation errors with any ISP. We switch our production systems to use the new SES account and everything is going great… except that a number of our emails are displaying a very unusual signature invalidation message.

My emails are now signed but I see a body hash verification failure error when viewing message headers

We have confirmed that our DNS is fine, and we have begun sending emails to another ISP. We’ve returned to our original ISP and it appears that in the meantime they have fixed their DNS resolver issues and are now validating our signature. We switch our production systems to use the new SES account and… we’re in trouble again. All ISPs are reporting “body hash did not verify” errors. So what happened now?

Sometimes, when sending an email indirectly (from SES to a forwarding address or middleware software which then delivers it to an ISP), the intermediate layer alters the message body in some way. Since the body hash in the DKIM signature is calculated before the message exits the SES system, it obviously cannot account for changes en route.

We can try to send directly to an ISP and confirm whether we still see the issue. If the DKIM signature is validated there, then we look into any software we have that sits between SES and the destination domain that actually performs the DKIM validation.

For our scenario, let’s assume that our company had, for auditing purposes, a forwarding address that was capturing part of the traffic from our production systems. That address was configured to URL-encode some part of the message text, before resending it; that fact alone was enough to make the hash of the text invalid, thus compromising the signature. We disable the URL encoding in our software and try again. Finally, we see the DKIM validation successful message. Success!

Next steps

With our signature now appearing in our emails and validating across all ISPs, we have come to the end of the technical part of the DKIM Troubleshooting series. The next entry will focus mainly on security issues, and we will find out exactly what DKIM does for us, and, equally important, what it doesn’t do.