I isolated the process into three components: the email builder (my code), the mailer application, and the sending application (in this case, smtp through postfix). I followed the below process to troubleshoot:
Changed the mailer application to use the built in PHP mail() function, and I also tried sending using a completely different SMTP box. The problem was persistent no matter what process was used to send the mail.
I found the place in my code where the completed HTML was being handed off to the mailer application. Adding in a file_put_contents, I could then examine the exact data before it went to the mailer. Taking a look at it through a hex editor revealed that the body did not contain the offending characters Finally, I found another mailer application (I was using phpmailer). Swiftmailer is an alternative to phpmailer. I figured that if it was obscure bug with phpmailer, changing the mailing application would clear it up. This also did not solve the problem.
So if everything was working correctly, where could the problem crop up? The only place left to look was the encoding scheme for the emails. Scouring the internet, I found a few suggestions that the problem may be related to the message encoding. In this case, it appeared the problem stemmed from (possibly) a 75 character limit in quoted-printable encodings. This didn’t help me, as my emails were being sent using 8-bit encoding.
Just to see what happened, I changed the encoding settings on phpmailer to use base64 encoding using $mail->Encoding=”base64?. This solved my problem, though I don’t admit to knowing exactly why.
Note: don’t confuse this with character set issues. In the past I have seen situations where utf-8 text was being read into an email and sent as ISO-8859-1. When having weird characters showing up in your emails, this is most often the problem (or vice versa).