Bulletproof email infrastructure setup guide

Great guide a couple of comments:<p>- DKIM, aside from buying you a "non-spam" pass (or at least more generous first treatment), can get you into "most favored sender" status with big email providers. Notably Yahoo, who, despite corporate troubles is still a huge player in hosted email.<p>- Even if you're using a mail service provider, setting up an SPF record for your domain, with your <i>MSP's</i> IPs (or better, an "include:" record to their sending SPF record) will help your mails go through.<p>- If you're using postfix, then you'll want to use 'qshape' and 'pflogsumm' to track your queues and delivery stats.<p>- VERPs are great. Until you run into an idiot recipient who insists on explicitly whitelisting all sender addresses. Including envelope sender. We at Krell Power have encountered ... a large energy sector company relying on Microsoft products who apparently favor this route. We've de-VERP'd their mails.<p>- Throttled delivery services with domain-based assignments are a great way to manage queues. Strong endorsement of that here.<p>- Track your mail reputation. Look up your domain and sending IPs on Senderbase, SpamHaus, Spamcop, and other reputation systems. Address complaints quickly.

Another option for bounce handling is to setup a client/server architecture. Continuing with the rails example: since directly spawning a rake task from a postfix hook will slaughter your machine if you get any decent amount of emails due to loading the whole rails stack each time, what I have chosen to do is this:<p>Postfix pipes the bounced email through command line to a simple client that shoves the body over a socket to a server process which has my full stack running. It then shoves the email into a resque queue to be handled by my normal job queue.<p>There are many ways to skin this beast, however if you need/want realtime response to emails, maybe to facilitate reply to notifications email to add a comment, and you get any decent volume of traffic, you want your postfix hook to be as fast as possible.

I'd be careful about using the term "bulletproof" in this context. Before reading the article, I assumed it was talking about sending spam without getting blacklisted.

Recently there's also DMARC, which allows a domain owner to specify their support of SPF and DKIM, and how to handle email that doesn't pass authentication.<p>Another benefit is feedback reports from major email providers on messages that have passed or failed authentication.<p><a href="http://dmarc.org/" rel="nofollow">http://dmarc.org/</a> <a href="http://en.wikipedia.org/wiki/DMARC" rel="nofollow">http://en.wikipedia.org/wiki/DMARC</a>

This is a great resource for those that want to roll their own email infrastructure.<p>We also have some tips about email content in our FAQs: <a href="http://documentation.mailgun.net/faqs.html#does-the-content-of-my-email-matter-for-deliverability" rel="nofollow">http://documentation.mailgun.net/faqs.html#does-the-content-...</a><p>The Mailchimp resource mentioned in the OP is also highly recommended reading.

How likely are servers to reject your emails simply because the PTR records don't match? I'm using my ISP's SMTP server as a smarthost and I've configured the SPF record to match their server, but making them add a PTR record is out of the question, unfortunately.<p>(This is just for personal mail, that's why I'm avoiding paying for a proper setup)

Thanks! This is a great walk-through for those using a solution with only 1 or a few IP addresses associated with little chance of that IP changing. Do you have any experience for those using services such as Amazon SES or Google Apps?<p>Setting up the PTR records for reverse DNS lookups are very tricky since Amazon and Google are always rotating the IP addresses for their mail servers. We've been fighting with this in our application for a little while now (using Python, not Ruby).<p>We're getting about 90% of our emails through, but some are getting denied for no reason whatsoever. The worst part is, they are server-side denials, so the emails aren't even going into the spam folders of the users.<p>Also, I second adding the DMARC section. DMARC is extremely simple, and it's very easy to implement gradually.

If I'm using a service such as Mailgun or Sendgrid, what parts of the article apply to me?

Igor, thank you, excellent guide/walk-through.

it's down for me for some reason, but here's the article in the gh repo: <a href="https://github.com/iafonov/iafonov.github.com/blob/master/blog/hardcore-email-infrastructure-setup.markdown" rel="nofollow">https://github.com/iafonov/iafonov.github.com/blob/master/bl...</a>

FWIW domain_info doesn't appear to be on rubygems.org.