Showing results for 
Search instead for 
Did you mean: 

What's wrong with this DKIM?


I have a server setup with a popular open source MTA and DKIM, the messages it signs pass the tests at yahoo, gmail, port25 and unlock theinbox, so I am fairly sure that they are being signed correctly. howevwer

I have one user complaining about seeing this text:

In this email, a DKIM key was supplied in the email and the DKIM cryptographic
authentication has failed (with 100% certainty).  Due to this, you should not
necessarily trust that it was really sent from the domain stated by the sender

and that appears to be generated by ironport (am i right here?)

I'm also seeing an added "X-IronPort-RCPT-TO:" header.

and there is only one new recieved header (names and IPs changed to protect the innocent)

Received: from my.server.invalid ([999.999.999.999])
    by ironport1.their.domain.invalid with ESMTP/TLS/AES256-SHA; 08 Feb 2012 13:40:30 -0500
the signature looked much like this:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=my.domain.invalid; s=main;

        h=Date:Message-Id:To:Subject:From; bh=+BKVDLbyMrnqhPqdKKvfUBn8/mXd/G8QDWbkPFJnisw=;
is there anything obviously wrong with that?
none of the headers which were subject to the DKIM signature appear to have been altered

I am also concerned by the text in the error:
"you should not necessarily trust that it was really sent from the domain stated by the sender"
even if it passed the DKIM test (which in my opinion it should have) that should not be a reason to conclude that the
domain claimed by the sender is correct without there being further evidence to support that.
5 Replies 5

Andreas Mueller

Hi jasen,

could it be that the message contains multiple signatures? Happens with forwarded messages. There is also a possibility that a footer is added after the message has been signed, maybe that's what the IronPort appliance does? That would break the signature too.



no, received headers had the signing server immediately before the system which rejected the signatire.

(reading, in chronological order, upwards)

I don't have the original emai on record only the size (2881 bytes when it arrived)

and the copy that was marked bad. after editing out the received herader, ironport headers and the headers our system added prior to signing it I get 2940 but several line breaks appear to have been added between

it's intended recipient and me.

someone else told me that the DKIM header had  a semicolon on the and they considered this to be unusual

I was surprised by that claim, did a little research and found that RFC4871 explicitly allows that

(start at "tag-list", top of page 10). 

The semicolon in my post above seems to have got lost during my struggle with an unfamiliar editor

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mydomain.invalid; s=main;

the destination mx identified itself as


and responds to EHLO with


250-SIZE 20971520


(uppercase/italic part of domain name has been edited)

so I appear to have a direct connection from the smarthost (where the DKIM is done) to an MX

that somebody has labeled as 'ironport1' I don't know if that EHLO response is typical of this hardware

or not. it looks like a directo connection to me, I have no reason to believe that is is not.

Not having easy access to both sides of an ironport, is there a way I can test this?

If I gave you an smtp account on the server would that help?

I've had no response. Should I tell them it's broken?

Hello Jasen,

one thing I forgot to mention in my response was that the text the recipient sees (In this email, a DKIM key was supplied in the email and the DKIM cryptographic authentication has failed...)  is nothing the IronPort appliance creates, at least not by default.  After all it's mentioning that DKIM verification has failed, yet  as far as I understand you are signing outbound messages with DKIM, and that seems to work with popular sites (Yahoo, Gmail), extept this one host the user is complaining about.  So most likely the message to that user is passing another host which probably adds something to the message body, and the next hop then finds the signature invalid. Correct me if I am wrong at any point, just thought to mention that the error message is nothing we create on an appliance. I'll have a look at the signature later, but looks good to me, and obviously works with the major hosts.



Thanks for clarifing that point, further research on my part suggests that this message is from a broken

in-house filter at the recipients end,  I have disabled DKIM generation for that destination,

as it was in house it was at a single location and the examples on the interweb had passed through an Ironport,

simply because the single location was behind an ironport.

sorry for wasting your time.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers