2018/11/27 by Willem Stam.
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
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?
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 however 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. In this case 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. By sending a few test emails, we continued collecting the binaries 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.
Conclusions
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.
More information?
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.