Mailgun forwarding can result in your domain being treated as spam

I love Mailgun -- I have had the experience of working for an email company before, and I know email is hard to get right. As a result, deciding to offload transactional mail when developing Zoetic was a no-brainer. However, the expectation is that a company focused on email would be experts in email and get it right.

The problem is, if you're using Mailgun right now to forward your email to Gmail or another destination, it's not always done right. We noticed that many of our Mailgun-forwarded incoming emails were ending up classified as spam by Gmail, at a false-positive rate higher than we had experienced before. It turns out that these emails are failing the DKIM authentication check:

Received: by with SMTP id c206csp112846lfd;
        Fri, 19 Sep 2014 07:46:41 -0700 (PDT)
X-Received: by with SMTP id z9mr3549915wiv.51.1411138001622;
        Fri, 19 Sep 2014 07:46:41 -0700 (PDT)
Return-Path: <[email protected]>
Received: from ( [])
        by with ESMTPS id fu1si2344154wjb.120.2014.
        for <[email protected]>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 19 Sep 2014 07:46:41 -0700 (PDT)
Received-SPF: pass ( domain of [email protected] designates as permitted sender) client-ip=;
       spf=pass ( domain of [email protected] designates as permitted sender) [email protected];
       dkim=fail [email protected]

This was strange, because if all is right, forwarded email should still pass DKIM. In addition, we determined it was not misconfiguration of the origin email domain because emails not passing through Mailgun were not being classified as spam, and this was happening across many well-known email domains. At first I thought this was because Mailgun was appending and prepending headers to the email-- which, as Mailgun support pointed out, is actually okay as long as there are no modifications to the existing header sets.

Just as an aside, for those not familiar with DKIM-- essentially, a DNS TXT record holds a public key corresponding to a private key the originating SMTP server uses to sign the email headers and body. This allows the recipient to check the signature and ensure the email is authentic (i.e. sent from a server that the domain allows).

While having DKIM authentication fail does not automatically mean that an email ...

continue reading this post ...

Your own mini-Heroku for $5/month

Dokku is a lightweight PaaS solution that let's you essentially have a mini self-hosted Heroku. This means you can easily take a web application (Django, Rails, etc.) and deploy it with little to no setup. While Heroku offers scalability and support, it does so at a significant cost ($) beyond a very low volume; if you're planning to deploy lots of small or in-development apps, then you don't necessarily need everything Heroku offers, you just need an easy way to (git) push your apps out there.

I'm going to walk through the setup of Dokku and then demonstrate how to deploy a Django app with a PostgreSQL database (however, the instructions can be easily re-applied to other frameworks, like Rails).

Initial Dokku Setup

We can host Dokku on almost any VM or Dedicated Hosting provider (or even your own machine). I went with DigitalOcean which offers a small instance for only $5/month (and can easily be grown as needed); other great options are Linode (which I also use), and EC2.

Not doing any advance reading about it's requirements, I first tried to set it up on an existing 32bit VM, and then again an Ubuntu 12.10 64bit VM. Unfortunately, I came to the late realization that Docker, the lxc-based container solution that Dokku is built atop, is only compatible with 64bit Linux, and only runs stable on kernel versions greater than 3.8 (Ubuntu 12.10 comes with 3.2, 12.04 is easily upgradable to 3.8). [4/2014 Note: there are currently issues with Docker and Ubuntu 13.10] Eventually, I went with the Dokku's preferred target OS of Ubuntu 13.04 x64. After this point, setup was trivial:

wget -qO- | sudo DOKKU_TAG=v0.2.2 bash

After the bootstrapping has run, you'll want to register your SSH public key with Dokku (USERNAME in this case is an arbitrary identifier for your key) so you're able to push your apps up; from your machine:

cat ~/.ssh/ | ssh "sudo sshcommand acl-add dokku USERNAME"

It's also simplest to have a domain dedicated to your Dokku instance, with a wildcard subdomain DNS entry so that any apps you deploy instantly have an easily accessible address. On many DNS management tools (including that of DigitalOcean and Linode) you can setup a CNAME or A record that points * to your new instance.

Once you have setup your DNS records, verify that /home/git/VHOST on your server is set to the base of your domain ...

continue reading this post ...