DKIM woes with Mailman


Apparently Gmail now uses DKIM ( to verify sender origin on their emails. But Mailman, or at least DreamHost’s version of it, seems to break the signature, so Gmail users who get a message from other Gmail users through Mailman also get a warning that “this message may not have come from your buddy Fred” or whatever.

Is there some combination of Mailman settings that will stop breaking the signature?


Setting up an SPF record for the sending domain seems to help get rid of this message, although you would do this via the Dreamhost control panel, not Mailman.

You can also turn off Mailman settings which manipulate the header and cause DKIM validation to fail. So you could take a look at the DKIM signature of messages on your list to see what headers are being included in DKIM signatures, and turn off settings which modify those header fields.

The set of headers which are used for the DKIM signature is determined by the originating mail provider so you should try to get a sense of all of the signatures that are present on your list.

Here is what Yahoo’s looks like (for a Blackberry user):
“DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;;

So right away, you can see that adding a prefix to the Subject or adding anything to the Reply-To field would cause this signature to not validate correctly for any of the list recipients whose providers check DKIM.

BTW, gmail’s DKIM signature looks like it is much more Mailman friendly:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to:content-type;

So far most list messages from gmail users pass DKIM but mail originating from yahoo and received by yahoo seems to be subject to some odd behaviour like delayed messages.

FWIW, I think yahoo’s signature is overly strict; I can see why you wouldn’t want spammers to be able to modify the Reply-To but exploiting this seems like an edge case and having the list address added to this header is very useful (almost essential, in my case) from a list functionality perspective.