Domain Keys / DKIM issue

Hi, do you have the public key set in your DNS server?

https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

DKIM == DomainKeys Identified Mail 

Barry

Hi Barry:

Yes. DKIM wouldn't be working otherwise.  But as pointed out above, domainkeys=neutral (no sig) is not working.

Hi Barry:

Yes. DKIM wouldn't be working otherwise.  But as pointed out above, domainkeys=neutral (no sig) is not working.

Are you maybe talking about S/MIME and PGP domainkeys? Then is the answer NO. Not implemented. AFAIK due no real existing standard for this ( but I may be wrong in this one...)

EDIT: Ah, forget my post. Just googled little bit. Seems to be some kind of enhacement of DKIM. No idea about that....

Hi, only dkim is implemented to the UTM. Dkim is the successor of domain keys which is no longer supported and has been replaced by dkim. So if dkim works all right, everything is fine. You can read about it here: DomainKeys Identified Mail (DKIM) (half the page down - introduction)

Samy, I don't disagree with the idea that domainkeys should have been superseded by DKIM in every deployment, as of several years ago.  However, while researching this issue, I did find a chart somewhere on the net that listed some major ISP's who were using only domainkeys, and those using DKIM or both.  I'm looking for it again, but haven't found it yet this morning.  By now (January 2014), one could easily speculate that any ISP of any consequence has migrated to DKIM rather than just domainkeys.

As an aside, if anyone has had problems sending outbound emails to AOL accounts, below is AOL's statement about using DKIM, and nothing else (like no SPF, etc.), to authenticate inbound mail.  However this AOL page was last updated in 2010, so who knows? *** Edit - I did find another internet document this morning that said AOL was using SPF as of 2012.  But it wasn't an AOL document.

Anyway, this sort of thinking is another reason to get DKIM up and working.  Interestingly the same AOL document also mentions that AOL doesn't send outbound mail with any authentication on board.  I guess we're just not supposed to question AOL email. :-o

AOL Postmaster | Postmaster / Domain Keys Identified Mail (DKIM)

Hi eganders, maybe I did not get your point right - sorry. But in my understanding dkim and spf are used as additional security options, to make sure the mailserver who sends this e-mail is allowed to do this. To my knowledge at least here in Europe no Mailprovider rejects e-mails that do not use dmik or spf. They reject mails, if these are implemented for the domain and the mail gets sent through a server that is not listet in the dns spf record or uses a dkim key that does not match the public key in dns. So it is a check if these settings are valid if set via public dns. But if they are not in place the mail is not rejected, only does not get some additional negative points for spam detection. So if you are not able to deliver mails to AOL that may have other reasons like using a dial-up connection with no valid rdns setting etc.

You're right Samy and sorry for the confusion.  I did not mean to say that you could only send email to AOL accounts if you used an email authenticator such as DKIM.  However, in my experience, AOL has been one of the touchier ISP email recipient's over time, and including an authenticator does seem to help get email through to those who use AOL as their email ISP.  In AOL's case, apparently they used to only use DKIM as their favored authenticator, assuming you were including authenticators in your emails.  Apparently they might now be using SPF as well, if not others.

As to your other point, yes I've definitely had clients have non-problematic emails bounced by AOL for reasons unknown.  It's not a frequent occurrence, but including an authenticator does seem to help.

Are these messages blackholed by AOL or do you get any bounces giving some reasons? If you have some mail headers from bounced messages or Astaro SMTP Transaction logs that might help to look a litte deeper :-)

Depended on the message. Can't remember all the reasons now.  Been doing Astaro / Sophos for many years.  Definitely some messages were bounced as SPAM.  Example, between law offices - a back and forth email thread. No identifiable SPAM on board.  Not bounced for RBL's, etc.  Not on Commtouch lists.  Sent the same messages at other times, and went through without a hitch.  Go figure.

We spent a fair amount of time on it at the time.  Not worth revisiting well after the fact.