Question asked by Constantine Serafim - 8/27/2016 at 6:25 AM
I am setting a DNS Record for Mail Signing (SmarterMail 15.2) with the Key generated, but I have a problem validating it with the <Test DNS>.
The keys match when checked with what the DNSStuff tool shows.
Also when I run a report through the Port25.com tool, it shows that the DKIM Key is valid.
Emails are received with DKIM_Pass signed.
I tried different key sizes but <DNS test failed>.
Any suggestions on this?

5 Replies

Reply to Thread
michaeljmann Replied
Constantine I am battling this setting for months and can't get an answer from anyone.  Including smartertools support for which I paid the support fee and they did not fix it, nor did they advise me on how to proceed and configure so this situation does not repeat itself.  They must expect us all to be Bruce Barnes.  Keep an eye on this thread maybe someone that has a clue will appear to help us out.
Constantine Serafim Replied
Michael thank you for that! I have been pulling my hair on this for weeks. I think SmarterTools should investigate this more closely and fix it! Lets wait and see. Fingers crossed!
Bruce Barnes Replied
If either, or both, of you will send me your domain names and e-mail addresses, via PM, I'll be glad to take a look at this and see if I can assist you with getting it resolved.

Remember, for your DKIM record, you need THREE RECORDS and a VALID SPF record:
The first is the DKIM RECORD, generated by SMARTERMAIL - do not use a key generated anywhere else:
In our case, we name our DKIM keys "secure", so they will always be entered as "secure._domainkey.domain.tld"  Note the LEADING UNDERSCORE in _domainkey - it must be included.
In the example below, the domain is echicago.com, so the name of the key is "secure._domainkey.echicago.com"  Not, also, that the domain key is prefixed with "k-rsa" to indicate the encryption type.
The SECOND DNS entry is: _adsp._domainkey.echicago.com.  Note the leading underscore in _adsp, it must be included:
The final key is this one:  _domainkey.echicago.com - again, note the leading underscore in _domainkey:
When you use DomainKeys you can publish policy statements in DNS that help email receivers understand how they should treat your email. There are three main statements that can be published:
  • "t=y" - Which means that your email DomainKeys are in test mode.
  • "o=-" - All email from your domain is digitally signed.
  • "o=~" - Some email from your domain is digitally signed.
  • "n=*" - n stands for notes. Replace the * symbol, with any note you like
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
michaeljmann Replied
Bruce thanks as always for the enlightenment.  You can be sure I will follow the instructions above wow thanks. Constantine and Bruce the support for my server host, the good folks at Softlayer, we are sorting through this as well and working toward the total solution, for which Bruce has so eloquently provided to us.  I have many domains in IIS on my windows 2012 server r2.  Let me pass along what support has chimed in with and I will post back the results.

"What Trae was referring to is that you cannot set a different PTR record for one IP address meaning it cannot have two values only one. So in that case you may need to set the domain on its own unique IP address so that the PTR value can be set to a hostname that resolves back to hat unique IP address.

Like say you have two domains:



And in our example both are set in DNS to IP

Both can be hosted on the same IP address with virtual hosting but the IP address can only have one PTR record. So in order to set another unique PTR you would need another IP address assigned to one of the sites so you can do so.

Though technically this may not be necessary as the hostname you setup for the PTR value just really needs to resolve back to the IP it is mapped to so as long as the hostname value maps back to the IP it should be fine, although some providers may not like that and still flag this as spam but usually when the domain name's IP address MX record and PTR all resolve and match the same IP address you usually are not flagged as spam or other."

So we shall see and I would bet BB might know what the outcome is going to be.  Will keep you all posted.
michaeljmann Replied
I don't think what is above applies because testing with unlock the inbox tools show some problems, but let us start with adding records as Bruce has advised. Please look to my next reply for all pertinent images.

Reply to Thread