2018/11/27 by Willem.
Proper MIME prevents DKIM failures in Outlook
At Postmastery, we work for various ESPs and brands to optimise email delivery.
Recently, one of our clients faced a mysterious DKIM failure when sending mail to Outlook.com domains. (A generic explanation of what DKIM is and how it works is available on dkim.org.)
Analysing SMTP headers
The first thing we did was to analyse the client’s email headers by sending a sample email to Postmastery’s free EmailAudit.com tool. We found our primary error indication in the headers.
Authentication-Results: spf=pass (sender IP is xxxx) smtp.mailfrom=cebounce.domain.com; Hotmail.com; dkim=fail (body hash did not verify) header.d=domain.com;Hotmail.com; dmarc=pass action=none header.from=domain.com
Hashing is the way DKIM uses parts of an email to work. The body hash is a certain value which consists of a string of characters determined by the hash algorithm. In this case, it is computed based on the message body.
After seeing this error, we concluded that the ‘body canocalization’ was set on relaxed, which should avoid issues with body hash calculations. This is a recommended setting if you want to minimise DKIM issues.
Analyse DMARC reports to check DKIM validation?
The logical next step was to analyse DMARC reports to check DKIM validation across all the messages. Unfortunately, at the end of April this year (2018), Hotmail.com temporarily stopped sending DMARC reports so we could not check this with DMARC reports. The only solution was to check DKIM validation by looking at mails in our own accounts.
We first extracted the contents of the sample emails and tried to send the exact same email from our end directly to the MTA. We used the following encoding in our test setup:
–add-header “MIME-Version: 1.0” –add-header “Content-Type: text/html” –add-header “Content-Transfer-Encoding: quoted-printable”
All our tests succeeded in DKIM. We again checked the emails that were submitted by our client. We were getting closer. We continued collecting the binaries by sending a few test emails while logging the complete SMTP transactions at DATA level. By doing this we were hoping to uncover something in the content that was manipulated or failed to validate at Microsoft.
And yes, by comparing the customer’s binaries to our own, we found the culprit. The customer’s application did not properly encode NON-ASCII in the TEXT/PLAIN part.
The content contained UTF-8 characters that are not included in the ASCIII character set while the suggested MIME headers are ASCII. It should have said it was UTF-8. However, as this may not work with some receivers that don’t support 8BITMIME, it’s best to ‘transfer encode’ UTF-8 using ‘quoted-printable’ encoding.
Use proper encoding and always test your output at a header level with various large ISPs like Outlook, Gmail and Yahoo. We advise using Quoted-Printable transfer encoding for best results.
If you would like to know more about how we can help you solve delivery issues, just send us a note via our contact page.