Most of you know Postmark as a tool to send your transactional emails and track delivery. What many people don’t know is that a big part of our service is troubleshooting actual delivery problems with customers. We have an excellent infrastructure and a fantastic reputation with the ISPs. While that gets most emails delivered, we’ve learned that even the slightest content issue can send your email to bulk. Here is a great example from a recent review with a customer.

PDFs going to junk in Postini #

We had a potential customer reach out to us recently. They send critical invoice emails with PDF attachments. No matter what they tried, if the email had the PDF attached, it would always go to the bulk folder in Postini (spam filter for Google Apps). I’ve seen a lot of content issues over the years, so I decided to roll up my sleeves and see what I could discover.

There are a number of things you can look at when troubleshooting an email delivery problem. Maybe it is an IP address reputation problem. It could be related to the “from address” domain of the sender. What about the subject? With just these items, you can run a number of trial and error tests against Postini to see what works. I tried everything from different subject lines, different IPs and different senders just to be sure. One thing we knew for sure was that the email went right to the inbox if the PDF was not attached. Hmm, odd. The obvious next step is to figure out what is going on with the PDF.

Since a PDF is just text content, the best test is to take that exact content and try sending it in the body of the email. We know that some filters will actually scan the content of the PDF, maybe there was something in there that Postini didn’t like. I gave it a shot, unfortunately in this case, it went right to the Inbox. Now I am back at the beginning. It’s not the sender address, IP, subject, body content or the PDF content. At this point I started to ask questions about how the PDF is generated, maybe there is some metadata in there that Postini doesn’t like.

While waiting for a response from the customer, I had another thought. What if I tried sending from one of our own domains, like info@beanstalkapp.com? I took the original content, subject, and PDF attachment and sent a test email off to Postini.

OMG! It worked! #

What was the difference? I started looking at the headers in detail. The only thing I noticed was that we have DKIM signing and SenderID for beanstalkapp.com through Postmark. The customer at this point had not set it up yet, which I somehow missed in the initial review. In Postmark we still sign with DKIM on our own Mail From (Return-Path) header if you leave yours out, but apparently that did not matter. I sent a quick email to the customer telling him what I found and asked him to add DKIM and SenderID to his domain. I patiently waited for the reply...

After a little while waiting, he replied. Guess what? With DKIM and SenderID on his own domain, the email went straight to the Inbox on Postini.

DKIM and SPF on your own domain are critical for email delivery. Skip it at your own risk.

In Postmark, even in our private beta we launched with DKIM and SPF support for all customers. We know how important it is, but having proof like this tells a great story and backs up our intentions. We make it super easy to set up DKIM and SPF, all you have to do is add two simple TXT records to your DNS.

Do you have DKIM and SPF setup for your sender signatures in Postmark? If not, login to Postmark and go to the Signatures page. You can also learn more in our help articles.