0

I am using AWS Simple Email Services (SES) and am trying to configure DKIM so as to add an extra layer of security to my emails. According to SES documentation, the procedure for setting up SES + DKIM with your DNS is:

  1. Generate DKIM CNAME records inside the SES UI/console
  2. Edit your DNS records by adding these (3) CNAME records
  3. Within 72 hours, SES will verify the DKIM records you added and begin adding DKIM-based authentication to your emails

I have followed these steps several times and each time I get failed validation errors inside SES:

However they don't give the reason for the failure/error each time this happens. I have checked and rechecked (and rechecked!) that I am adding CNAME records with the correct name + value that SES has generated for me.

I think I'm going to have to open an incident with AWS, but before I do, I'd like to see if I can use a reliable "DNS querying tool" to somehow confirm whether the CNAME records are added to my DNS configuration properly.

Does such a tool exist? If so, how could I use it to verify the CNAME records that are associated with my domain name?

Update:

Here is the output from my dig command:

dig <longstring>._domainkey.example.com CNAME

; <<>> DiG 9.10.3-P4-Ubuntu <<>> <longstring>._domainkey.example.com CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39150
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;<longstring>._domainkey.example.com.   IN CNAME

;; ANSWER SECTION:
<longstring>._domainkey.example.com.    7200 IN CNAME <longstring>.dkim.amazonses.com.

;; Query time: 132 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Fri Feb 16 20:15:39 UTC 2018
;; MSG SIZE  rcvd: 145
smeeb
  • 201
  • 1
  • 5
  • 13
  • I am interested in your solution for this problem. There are a number of web sites out there that verify DNS records including MX records. I cannot speak for any but maybe they will point something out. If you have AWS support enabled, I would definitely open a ticket. Let us know what the issue was. – John Hanley Feb 13 '18 at 05:26
  • 2
    The de facto standard DNS query tool is `dig`. From a *nix command prompt, you should be able to `dig my-dns-record.example.com CNAME`. Your domain's DKIM settings in DNS are public information -- not sensitive -- so if you can mention the domain name here I suspect we can easily pinpoint the general nature of the problem. – Michael - sqlbot Feb 13 '18 at 10:16
  • 1
    You didn't mention who is hosting your DNS but a common error when creating a CNAME record is incorrectly including the domain name twice. In the Route 53 console, if your record on the left hand side shows `foo.example.com` instead of just `foo` then that would be your issue. – Michael - sqlbot Feb 13 '18 at 10:23
  • Thanks @Michael-sqlbot (+1 for both) I will post the `dig` output here unless you can confirm what I'm seeing: going with your theory that I'm incorrectly including the domain name twice, I looked at the **name** of *each* of my CNAME records (the left-hand side) and it is `._domainkey.example.com` (where `` is a random alphanumeric string that SES' DKIM tool generated and where `example` is obviously my actual domain name. **Are you saying that I should change each of my three CNAME records to fit a format of `._domainkey`?** Thanks in advance! – smeeb Feb 13 '18 at 14:35
  • 1
    Unfortunately, I was going from memory about the console UI, and memory failed me. The route 53 console does show the entire hostname on the left. Where you get in trouble is if you paste the entire record including the domain name into the `Create Record Set` box. If this is the problem, you'd actually see `foo.example.com.example.com.` on the left side after creating the record. – Michael - sqlbot Feb 13 '18 at 22:09
  • Thanks @Michael-sqlbot (+1 again) please see my update which contains my `dig` command output as well as bounty posted ;-) Any ideas? Thanks again so much! – smeeb Feb 16 '18 at 16:51
  • Sorry, you need to `dig longstring._domainkey.example.com CNAME`, not `dig example.com CNAME`. – Michael - sqlbot Feb 16 '18 at 20:11
  • Please see my updates @Michael-sqlbot! – smeeb Feb 16 '18 at 20:17
  • Note that the long strings are not secret values -- they don't have to be redacted. What about *"Edit your DNS records by adding these (3) CNAME records"* (three?) – Michael - sqlbot Feb 16 '18 at 20:21
  • Thanks @Michael-sqlbot I get the same/similar output for all 3 DKIM/CNAME records. – smeeb Feb 16 '18 at 20:37
  • You want to go ahead and show us the actual records? – Michael - sqlbot Feb 16 '18 at 21:12
  • Please provide the domain name. There are different possible reasons but without the domain name it will be very difficult for anyone to tell you what the problem is. – user5870571 Feb 22 '18 at 21:16

1 Answers1

1

Your domain isn't actually using Route 53 for its authoritative DNS hosting, so records created in a Route 53 hosted zone are invisible to the Internet, as well as to other AWS services.

You need to do one of two things:

  • create these records with your current DNS hosting provider, in their console, not in Route 53, or
  • make a change at your domain registrar to set the authoritative nameservers to your domain to the 4 nameservers Route 53 assigned to your hosted zone, so that you're using Route 53 rather than your current DNS host.
Michael - sqlbot
  • 21,988
  • 1
  • 57
  • 81
  • Thanks @Michael (+1 as always!). I have a few quick questions for you, but they're all predicated on my understanding one critical thing: when you say "*so records created in a Route 53 hosted zone are invisible to the Internet, as well as to other AWS services*", I'm not 100% following you. Are you saying that when I went into AWS SES and clicked the button to generate the (DKIM) CNAME records, that it was generating them from inside a Route 53-hosted zone? – smeeb Feb 16 '18 at 19:54
  • Sorry, I think I've made an assumption that you were using Route 53. We may need to scratch this answer and try again. – Michael - sqlbot Feb 16 '18 at 20:10
  • No worries at all, I updated my post with the new `dig` command! – smeeb Feb 16 '18 at 20:17