Allright; this case is breaking my moral over here. Hope you guys can help.
I've setup PHPMailer on my webserver (Centos, PHP5.6) using Exim 4.89 to send mails. I've setup SPF and DKIM correctly. Using https://mxtoolbox.com/dkim.aspx i can validate the DKIM record. When i send an e-mail to http://dkimvalidator.com/ and/or https://www.mail-tester.com/ all is OK (10/10 @mail-tester.com!).
# Problem description
The current subject of the test e-mail is "Reminder give feedb盲ck to R1 R1 / Reminder" --> OK.
When i change it to: "Reminder give feedb盲ck to R1 R1 / Reminder to Ronald" the DKIM check fails.
# Code to reproduce
`date_default_timezone_set('Etc/UTC');
use PHPMailer\PHPMailer\PHPMailer;
$key = '-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----';
$selector = '1520190215.mytestdomain';
$to = '[email protected]';
$sender = 'mytestdomain.nl';
$mail = new PHPMailer;
$mail->setFrom('noreply@' . $sender, 'Mail from ' . $sender);
$mail->addReplyTo('noreply@' . $sender, 'Mail from ' . $sender);
$mail->addAddress($to);
// OK, 23 chars with 1 special char:
//$mail->Subject = "Reminder feedb盲ck to R1";
// NOT OK, 1 char. too long? Strlen: 46
$mail->Subject = "Reminder give feedb盲ck to R1 R1 / Reminder to Ronald";
// NOT OK, 1 char too long. Strlen: 77
//$mail->Subject = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
// Strlen 63, NOT OK, 1 char too long.
//$mail->Subject = "Reminder give feedback to R1 R1/ Reminder Reminder Reminder Remi";
$htmlMsg = '
This is a test!!!$mail->msgHTML($htmlMsg);
//$mail->AltBody = strip_tags($htmlMsg);
$mail->DKIM_domain = $sender;
$mail->DKIM_selector = $selector;
$mail->DKIM_identity = $mail->From;
$mail->DKIM_private_string = $key;
$mail->CharSet = 'UTF-8';
$mail->send();`
# Debug output
When i use a subject from above where it says NOT OK i get the following error from dkimvalidator.com:
Validating Signature
result = fail
Details: message has been altered
mail-tester.com & gmail.com validate the DKIM error. Using a smaller subject solves in a correct DKIM sent email.
I think there is a bug in "encodeHeader", the part after the following comments:
//RFCs specify a maximum line length of 78 chars, however mail() will sometimes
//corrupt messages with headers longer than 65 chars. See #818
The result of "encodeHeader" with a "faulty" subject:
=?UTF-8?Q?Reminder_give_feedb=C3=A4ck_to_R1_R1_/_Reminder_to?=
=?UTF-8?Q?_Ronald?=
The result with a "correct" subject:
=?UTF-8?Q?Reminder_give_feedb=C3=A4ck_to_R1_R1_/_Reminder_to?=
That wrapping (it's called header folding) is correct, but suggests the DKIM normalization might be having a problem with it. There should be some white space (a tab or space char) at the start of the second line of that folded header.
Actually there is a white space but the Github editor filters it / does not display it. Here a screenshot:

I've updated the const STD_LINE_LENGTH from 76 to 255 and my (our?) problem is solved. So yes, i can confirm there is a bug in the DKIM normalization concerning subject length > STD_LINE_LENGTH
OK, I'll have a look at that.
You can show raw content by using triple backtick "fences".
I think I've spotted the problem. All the headers except the subject line are handled correctly by the DKIM_HeaderC method. The Subject line is a special case partly because it needs to be dropped from the headers when using mail(), which adds its own subject header in. The DKIM signature doesn't treat the subject header in quite the same way as the others, leading to this issue. I suspect that if you put the same (long) subject line in a custom header, the DKIM signature would be correct. That's academic though! I've not got a fix yet, but at least I know where to look.
@Synchro thank you so far!
Hi there,
I have been facing exactly the same issue today, and it took me a long while to get to same conclusion, and so I ended up here.
Just checking if you have any relaible solution for this "too long" subject issue to suggest in the meantime ? Is changing the const STD_LINE_LENGTH value effectively ok ? as I suppose it would impact other parts..
Thanks !
Working with STD_LINE_LENGTH = 255 for months now, no problems.
@lukasmedia Thank you, I will give it a try then.
I have a similar problem with the subject (https://github.com/PHPMailer/PHPMailer/issues/1526). I set STD_LINE_LENGTH = 255, which solved my problem. @lukasmedia, thanks!
Same issue here, can confirm that STD_LINE_LENGTH = 255 fixes the issue.
Whats the way to go here to solve this issue? Do a PR with the changed value? I don't know enough about DKIM to understand whats the negative consequence of increasing this setting.
The problem with doing that is that it's an RFC contravention. That it works for you is purely down to luck. The underlying problem is something to do with exactly how PHPMailer folds subject lines for DKIM, and the reason increasing the line length "solves" it is that lines do not get folded as much - but if you make your subject line longer, you'll have the same problem again, and all the while you're risking your messages not being delivered at all due to the length contravention.
In short, increasing the line length is a workaround, not a fix. The best kind of PR would be some failing test cases relating to very specific header folding rules.
Agree that it is a workaround. So far all DKIM checks are passing, i have tried several companies in my network and also Gmail, Zoho, Yahoo and (the greatest whiner of all) Hotmail. We also use Office 365, no problems. A RFC contravention will sooner or later result in messages not being delivered.
Hello,
Have you found a fix for this problem ?
Hello, the problem is no longer. Webhosting updated some libraries on the server (I don't know what) and the problem disappeared. I am now set to default value STD_LINE_LENGTH = 76.
"Webhosting updated some libraries on the server" this could be anything. Who is your webhoster?
It is a local webhosting https://www.cesky-hosting.cz/
It's quite likely that these issues have been resolved by what's been going on in #1860, so if anyone in this thread is interested in this, please give the version in the dkimrevision branch a go and see if it helps you without having to change the line length.