DKIM Troubleshooting Series: Your DKIM Status is Still Pending

In this blog series, we are following the path of an engineer trying to set up DKIM for a domain, and examining various issues that can appear along the way. So far, we have been able to add to our DNS the records that Amazon SES gave us, and we confirmed that they resolve to the correct values. But we’re still having problems…

I can now successfully resolve all the DNS records but my domain’s DKIM verification status is still Pending

SES is still refusing to validate our setup, and our domain’s DKIM verification status still appears as Pending in the SES console. Occasionally, network glitches get in the way of DNS resolution. As long as the networking issues are resolved in time, they will not impact the process of setting up DKIM with SES. But we already waited for the 72 hours specified in the documentation and still haven’t received an Amazon SES DKIM Setup Successful confirmation email. We need to dive deeper than simply querying for TXT records in DNS and we need to check the health of our DNS system.

First, let’s make sure our domain has its authoritative name servers properly set up. Here’s how we retrieve the list of name servers for our domain in Linux using the dig command. We can see the list of name servers in the ANSWER SECTION of the dig output. We can also see how each name server has a properly configured IP address in the ADDITIONAL SECTION :

$ dig NS ses-example.com                                                                                                                  
; <<>> DiG 9.4.2 <<>> NS ses-example.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57753
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 12

;; QUESTION SECTION:
;ses-example.com.               IN      NS

;; ANSWER SECTION:
ses-example.com.        900     IN      NS      pdns6.ultradns.co.uk.
ses-example.com.        900     IN      NS      pdns1.ultradns.net.
ses-example.com.        900     IN      NS      pdns2.ultradns.net.
ses-example.com.        900     IN      NS      pdns3.ultradns.org.
ses-example.com.        900     IN      NS      pdns4.ultradns.org.
ses-example.com.        900     IN      NS      pdns5.ultradns.info.

;; ADDITIONAL SECTION:
pdns1.ultradns.net.    2974    IN      A        204.74.108.1
pdns1.ultradns.net.    73009   IN      AAAA     2001:502:f3ff::1
pdns2.ultradns.net.    1258    IN      A        204.74.109.1
pdns2.ultradns.net.    73009   IN      AAAA     2610:a1:1014::1
pdns3.ultradns.org.    2974    IN      A        199.7.68.1
pdns3.ultradns.org.    71368   IN      AAAA     2610:a1:1015::1
pdns4.ultradns.org.    688     IN      A        199.7.69.1
pdns4.ultradns.org.    71368   IN      AAAA     2001:502:4612::1
pdns5.ultradns.info.   2974    IN      A        204.74.114.1
pdns5.ultradns.info.   71368   IN      AAAA     2610:a1:1016::1
pdns6.ultradns.co.uk.  2974    IN      A        204.74.115.1
pdns6.ultradns.co.uk.  85530   IN      AAAA     2610:a1:1017::1

;; Query time: 63 msec
;; SERVER: 10.4.4.10#53(10.4.4.10)
;; WHEN: Tue Apr 23 12:21:56 2013
;; MSG SIZE  rcvd: 468

After seeing that the name servers are properly set up for our domain, the next step is to verify that each of those servers can successfully resolve the domain keys. Here are example DNS queries directed against the name servers obtained in the previous step:

$ dig CNAME zxfo5z4dqr44uztwz5io2b4j4mwlrquj._domainkey.ses-example.com @pdns1.ultradns.net +short
zxfo5z4dqr44uztwz5io2b4j4mwlrquj.dkim.amazonses.com.

$ dig CNAME zxfo5z4dqr44uztwz5io2b4j4mwlrquj._domainkey.ses-example.com @pdns2.ultradns.net +short
zxfo5z4dqr44uztwz5io2b4j4mwlrquj.dkim.amazonses.com.
etc...

$ dig CNAME xtk53kxcy4p3t6ztbrffs6d54rsrrhh6._domainkey.ses-example.com @pdns6.ultradns.net +short
$ dig CNAME zxfo5z4dqr44uztwz5io2b4j4mwlrquj._domainkey.ses-example.com @pdns6.ultradns.net +short
$ dig CNAME 5aws6ez5cxrf4hvt6w2qrip6pr4voupo._domainkey.ses-example.com @pdns6.ultradns.net +short

We fix our DNS setup and try again. Now we can see that our domain has properly configured name servers, and that each of them successfully resolves the CNAME records to the values indicated in the SES console. As indicated in the Developer Guide, we restart the DKIM verification process and now there is nothing in the way of SES verifying the setup for our domain. Indeed, a short while later, we get the confirmation email from Amazon, and we see our domain’s updated status in the SES console: DKIM is Verified! But the DNS issues we faced make us wonder…

My domain is now successfully set up for DKIM. But how does SES handle DNS errors caused by network glitches?

After seeing how fickle the network was in the previous step, we may be concerned about what happens when the records briefly become inaccessible.

SES repeatedly verifies that the DKIM CNAME records are still present in DNS and that the records resolve to the correct keys. SES does have degree of a tolerance to protect against network glitches, but if it repeatedly finds the records missing, it will disable DKIM signing for that domain’s emails. We will still be able to send, but our emails will no longer be signed.

The reasoning behind this is that if SES cannot resolve the DNS records, neither can ISPs. An email with a broken DKIM signature cannot be successfully associated with our domain, so ISPs may decide to send it to the Spam folder or even drop it all together in an effort to protect themselves and their customers against address spoofing and other fraudulent behavior. See the Developer Guide for more details on how SES revokes DKIM signing and how to reenable it.

Next steps

So far, these DKIM troubleshooting blog posts have focused on various problems we can encounter when trying to validate our DKIM setup with SES. The next entries in the series will focus on debugging issues with the DKIM signature itself and the usefulness of DKIM in general.