Amazon SES: Swaks, Postfix and more

If you subscribe to my email newsletter, you already know that I’ve been complaining about how my ISP, where I host my MTA (mail server aka mail transfer agent), is changing their range of IP addresses. Which means that my dedicated IP address, which hosted my dedicated MTA, where I send mail from, is changing after thirteen years.

That’s not a lot of fun from an IP reputation perspective. I guess the volume is low enough that I could just switch over to the new IP and let the regular traffic warm things up; but I wasn’t really looking forward to a few weeks of pain while spam folder placement issues worked themselves out.

So, I investigated a bit to see what else I could do here, and realized that there are a plethora of email services out there that support SMTP relay or email-via-API that I could just link my newsletter and other mail up to. Also, I’ve always wanted to learn more about how Amazon SES works, and I’ve had an account half set up for more than a year. So, why not switch this thing over to Amazon SES? And thus, I switched over my outbound email to use Amazon SES on June 28th.

Setting up DKIM for my handful of primary sending domains was a breeze; in Amazon SES, they use three CNAMEs to configure DKIM for each domain. Copy and paste, copy and paste, copy and paste. Then I disabled DKIM on my own server, as I didn’t also need to sign the mail, if Amazon SES was going to sign it for me. They also have a custom return-path subdomain setting, which I set up for each domain; I strongly recommend this, because there will be somebody out there that doesn’t like amazonses.com and might block it. Using a custom return path domain means your domain reputation is slightly more under your control, compared to using the default.

Then it’s just a question of configuring SMTP relay credentials and away we go. Testing was easy. With my favorite email geek tool Swaks, one can generate a test email thusly:

swaks -tls --auth \
--server email-smtp.us-east-2.amazonaws.com --port 587 \
--au [ SES SMTP Relay User ] \
--ap [ SES SMTP Relay Password ] \
--from sender@example.com \
--to user@recipient.com \
--header “Subject: Test Email”

(And since Matthew Vernhout recently collected Swaks examples for different email sending platforms, I passed this along to him to add to his excellent article on this topic.)

And then, for me, it was time to configure my Postfix server (hosted on Google Cloud) to relay mail out through the Amazon SES SMTP relay configuration. This was also very easy to set up, thanks to Stefan Wieczorek from Cloudpanel, who put together just the guide I needed. Configure SASL for SMTP auth, make sure TLS is set up, store your credentials, and set the proper Amazon SES inbound SMTP server (and port 587) as your “relayhost” in the Postfix main.cf configuration file.

All that complete, Postfix now treats Amazon SES as its outbound relay and the mail flows nicely. And that’s how I’ve been configured since June 28th.

What issues did I run into?

• You need to wrap the Amazon hostname in [brackets] when configuring both the Postfix main.cf and sasl_passwd file. I only used brackets in once place and not the other, so I was confused at first, receiving an error indicating that Postfix wasn’t trying to authenticate the SMTP relay connection.
• Of course, I forgot about one of my domains, so I woke up the next morning to find that Amazon SES rejected attempts to relay mail for that domain. Easily fixed.
• Recipients at RCN and Charter weren’t receiving my mail when sent via Amazon SES. They were receiving my mail just fine previously. The RCN error seemed to be content related and went away on its own, and the Charter/Spectrum error seemed to be a rate limit issue (“You’re sending too much mail/too fast”). This is out of my control because when I outsource my MTA to Amazon (or anyone else), I outsource those and other settings. And when on a shared IP pool, other mail (lots of other mail) is also being sent by others. This issue has since been resolved.

I share information about the bounces just to enlighten; I don’t consider these (or the other issues) to be significant problems. Bulk mail is bulk mail; not Fedex. Delivery is not guaranteed, and shared pools are more likely to run into issues like this. Two bounces out of thousands of emails sent? Not bad.

And as far as inbox testing; my personal seedlist shows 100% inbox placement to the usual places. And the Monday email newsletter was at about a 48% open rate shortly after sending. None of this is scientific testing, but things seem to be going just fine.

One question remains: Do I switch back to my (newly renumbered) legacy MTA? Or just keep on trucking on Amazon SES? What would you do, if you were in my shoes? Part of me wants to just leave it on Amazon and continue to explore what I can do with their platform. But part of me also wants to get back into the MTA game; I love proving to people that it's still possible for a hobbyist to run an MTA in this modern age of email, mostly to spite those who complain about how there's a conspiracy against the little guy. (Spoiler alert: there's not; there are a zillion little guys sending mail just fine via a zillion different methods; it's just that running an MTA requires more work today than it did in 1998, and not everybody wants to keep up with the time. Maybe that's why even the IETF switched over to Amazon SES? Anyway.)