Looking for help with web or mobile software design & development? Check us out:
Flyoverworks blue
Migrating Application Email Sending to a New Server
Headshot 128 Ben, May 30, 2013
At Inkling Markets, we recently moved off of dedicated hardware and onto the Rackspace Cloud. Our old servers had good spam reputation, and we didn't want to jeopardize that with the move. There are several things that you can do to help improve your reputation and deliverability, but here are a few that we did.

Check the Existing Reputation of the Server's IP

If you're using cloud servers, you could easily end up with a recycled IP address that was previously used by another server. And what type of person needs to constantly move to new servers with new IP addresses? Spammers. The first IP that we got for our jobs server turned out to be one that was recently used by someone for sending a bunch of email spam. I used MX Toolbox to check blacklists for our IP, and it was on several. The good news is that we could spin up a new cloud server and get a new IP. I would recommend checking this as soon as you get the IP, before wasting any time on configuring the server.

Set Up an SPF Record

SPF (sender policy framework) records verify that a server is allowed to send email for the given domain. Our new jobs server was going to be responsible for sending our email, so we simply needed to add a DNS TXT record like: v=spf1 ip4:jobs.server.ip.address

For verifying spf records, I found http://www.kitterman.com/spf/validate.html very useful. If you use gmail, you can also open a message and select "Show Original" from the dropdown menu on the right. There should be some SPF info in the headers, which will show if the server that sent the email is designated as a permitted sender.

Set Up a Reverse DNS (PTR) Record

A normal DNS A record points a domain to an IP. PTR records do the opposite, pointing an IP to a domain. Many email servers use PTR records as another signal that the given IP is allowed to send email for a domain and may reject email from servers that don't have one. These are typically set up with whomever provided you with the IP address (ie. the server provider, in our case Rackspace). So if you send email from a server with an IP of 123.123.123.123 (and your A record is mydomain.com -> 123.123.123.123), then you'd want to set a PTR that points 123.123.123.123 to mydomain.com.

Warm Up the IP

In the email world, there is a concept known as "warming up" an IP address, which was news to me. The idea is that if a new server pops up and starts sending massive quantities of email, it is probably spam. To avoid this, you can gradually ramp up email sending by the new server over the course of several days. This was a tricky piece for us, since we planned to have a single-night cutover where we switched everything from our old environment to the new one. Fortunately, a large proportion of our email was generated by cron jobs. We gave the new jobs server access to the old db server and, over the course of a week, we started turning off cron jobs on the old server and enabling them on the new jobs server. This allowed us to gradually ramp up the volume of email coming out of the jobs server until the day of cutover, when all of our email starting running through it.


If you found this post helpful, I'd love to hear from you on twitter: @bcroesch
comments powered by Disqus