My mail DKIM-Signature creates an email address out of thin air

Question

I use mandrill to send emails created using javamail. When I try to send an email from our application using the from address of our users, the DKIM-Signature contains an email address we never assigned and which does not exists. When I sent this email without using mandrill, the mail does not get altered.

The problem is that when we sent an email from our application which uses a SKIM signature for ourdomain.com and we send an email for a user on a different domain user_domain.com, the from and sender headers get set as folows:

From: Joost Schouten <joost@user_omain.com>
Sender: Joost Schouten <[email protected]>

The Sender header is never set by us, nor does the email address exist and unfortunately some mail clients use this address to reply to. It is a combination of the from email part without the domain and the DKIM signed domain. I have no clue why this is happening and how to stop it from happening.

The DKIM-Signature also mentions this non existing address so I'm assuming that might be the cause. Unfortunately all the DKIM documentation is somewhat lost on me so I was hoping someone can point me in the right direction.

This is the complete mail:

Received-SPF: pass (google.com: domain of bounce-md_30191264.559598db.v1-0709e43ec6fc4aaaa2eaa4b9a07c553a@mandrillapp.com designates 198.2.133.7 as permitted sender) client-ip=198.2.133.7;
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=mandrill; d=ourdomain.com;
 b=FJ6zXTYOnZY/RN7okxXDpl5sNL0ysjDQfXixD8vfLk7nvpEB2Y7vUBe7EKbC0dLuHRtLSullN9Eg
   ARddkGh81Mes/ergpfyy/epulj745nOfPR8h4cQsu6dhe2p8xHA3H8AJDf2XTX8SnspuZrBgrcmU
   gXI1cSTr/QTAz6emAbE=;
From: Joost Schouten <joost@user_domain.com>
Sender: Joost Schouten <[email protected]>
Subject: Subject
To: Receiver <[email protected]>
Message-Id: <328629681.01435867315102.JavaMail.tomcat7@www>
Date: Thu, 02 Jul 2015 20:02:35 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="_av-RYsOAD_G5IlIUfcO9tyvnQ"

--_av-RYsOAD_G5IlIUfcO9tyvnQ
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

PLAIN TEXT CONTENT

--_av-RYsOAD_G5IlIUfcO9tyvnQ
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><title></title></head><body> THE HTML CONTENT</body></html>
--_av-RYsOAD_G5IlIUfcO9tyvnQ--

(EDIT - added the java code) My mail sending code (Simplified)

MimeMessageHelper helper = new MimeMessageHelper(message, false);                       helper.getMimeMessage().setSubject(emailMessage.getSubject(), defaultCharSet);

helper.addTo(new InternetAddress("[email protected]", "Rex receiver"));             
helper.setFrom(new InternetAddress("joost@user_domain.com", "Joost Schouten"));

//commenting this next line out does not change anything
helper.getMimeMessage().setSender("[email protected]");

helper.setText(htmlContentVar, true);
helper.getMimeMessage().addHeader("X-Mailer", xMailer);
helper.getMimeMessage().addHeader("X-MC-SigningDomain", "ourdomain.com");
helper.getMimeMessage().addHeader("X-MC-AutoText", "true");
helper.getMimeMessage().addHeader("X-MC-Track", "opens,clicks");
helper.getMimeMessage().addHeader("X-MC-Tags", emailMessage.getTags());

javaMailSender.send(helper.getMimeMessage());

Can you give us a code sample that can reproduce the error? Without that we would only be guessing at where the issue is. — Dijkgraaf
@Dijkgraaf I just added the javacode. Unfortunately my application creates the email exactly like i'd like it to. It's when I route the email though mandrill that the header get's added/changed. — joostschouten
@Dijkgraaf The issue lies with Mandrill, see my answer below. Thanks for your help! — joostschouten

joostschouten joostschouten · Accepted Answer · 2015-07-06T10:06:39

The problem lies with Mandrill as they add the Sender header to ensure it is on the domain signing the email. The obvious problem here being that they even override the Sender header when I specify it myself on our own domain. Currently we have explicitly added the Reply-to header as well as the From header to invite as many email clients as possible to use those addresses vs. the Sender option. This does seem to help but we are not fully sure this will solve the reply address issue for all email clients.

I hope this will save someone from pulling out their hair trying to figure out what's going on. This is mandrill's their full answer:

Thanks for reaching out. Mandrill adds the Sender: header to your message headers to support signing and authenticating your emails when the sending domain does not have SPF and DKIM records. A few email clients (but not all) choose to display the address from this header rather than the address in the From: header.

Mandrill adds a Sender header to all emails that are sent from a domain that doesn't have SPF and DKIM set up. And we construct the Sender header address by combining the local portion of the From address (everything before the @ symbol) with the singing domain. In many cases, this can create an address that doesn't actually exist — as you've pointed out — but generally this only impacts the display of those emails and not actually email replies. You should still be able to reply to the email and have the original From: or Reply-To: address be used as the recipient of your response rather than the constructed sender header which doesn't exist.

We are looking at ways we may be able to update how we construct that header to avoid confusion, but I don't have an ETA I can offer just yet for when those changes might be available.

I hope this information was helpful. Let us know if you have any further questions.

My mail DKIM-Signature creates an email address out of thin air

1 Answers