I am using code (see below) that I found for sending an AWS SES message with an HttpRequest to amazon. I am able to send MIME messages with PDF attachments and all has been great.

Today, I tried changing from text/plain (in my body) to text/html, and added div tags, so that I could add some formatting to the emails.

Unfortunately, somewhere along the way, the '>' character in the tags is getting converted to '?', which breaks the html. This only happens to about one in three instances and I cannot tell what factor determines whether the '>' remains as '>' or shows up in the email as '?'.

I have taken the base 64 encoded value from this line and run it through web based decoding tools, and it appears to be fine:


Are there any known complications with HttpRequest posts that might be responsible for breaking the html tags?

String emailRequest = 'Action=SendRawEmail';
emailRequest += '&RawMessage.Data=' + EncodingUtil.base64Encode(Blob.valueOf(body)).replaceAll('=','%3D');

AWSHelper helper = new AWSHelper('us-east-1','ses');

private String httpMethod = 'POST';
public void sendEmail(Blob mimeMessage) {
    Map<String,String> queryParams = new Map<String,String>();
    Map<String,String> headerParams = new Map<String,String>();
    headerParams.put('content-length', String.valueOf(mimeMessage.size()));
    headerParams.put('host',new URL(awsSESEndPoint).getHost());

    HttpRequest request = new HttpRequest();
    for(String key: headerParams.keySet()) {
        request.setHeader(key, headerParams.get(key));

    HttpResponse response = new Http().send(request);
    if(response.getStatusCode() == 200) {
        ResidentCommonFns.addPageMessage('Successfully Sent Email','Confirm');
    } else {
  • 2
    .replaceAll('=','%3D') should instead be EncodingUtil.urlEncode(... ,'utf-8')However, I don't think this will fix your problem.
    – sfdcfox
    Oct 5, 2017 at 18:07
  • You nailed it - that completely fixes the issue.
    – Ben Kass
    Oct 6, 2017 at 18:29
  • You'd be surprised how often I underestimate my own ability to fix an issue. I'm glad I was able to help you out with that.
    – sfdcfox
    Oct 6, 2017 at 18:35
  • Thanks so much. After a bit more digging 'x">' as in ....px"> becomes 'eCI+', which became (I assume) eCI/+, which translates back as 'x"?'.
    – Ben Kass
    Oct 6, 2017 at 18:47
  • It depends on the position of the bits. In base-64 encoding, every 3 bytes of data becomes 4 bytes of encoded data. So depending on its alignment, it could have been one of three possible values, and yes, it would translate backwards. The reason why you had the problem is that + is translated as a space in URL encoding, so + also has to be encoded. That's why its safer to use urlEncode, so you don't miss anything.
    – sfdcfox
    Oct 6, 2017 at 19:03

1 Answer 1


.replaceAll('=','%3D') should instead be EncodingUtil.urlEncode(... ,'utf-8'). This will make sure that all characters are properly encoded.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .