Amazon AWS’ SES service is sadly failing its customers with a debilitating problem right now: a “SPF record not found for custom MAIL FROM domain” error that is entirely avoidable, but is acting like a locked door for new users who are trying to access the service.

Our team’s been struggling with this for days, beating our heads against a configuration issue that’s generating the “SPF record not found for custom MAIL FROM domain” error for no obvious reason. We’ve followed all the instructions to a T. Turns out that was our mistake…!

What’s Amazon SES?

For those unaware, Amazon AWS is the formidable suite of Amazon backend services that powers the retail giant as well as much of the internet. SES is their “Simple Email Service,” which is powerful but not as simple as you might think.

Amazon SES’ documentation is generally quite comprehensive. In this era of sloppy product and rapid, decentralized deployment, you could say that it’s quite above-average. Still, it’s pretty shocking to see that this entire product, used by thousands, is currently impossible to set up and use as described. And we’re not even dorking with the API or trying to do anything non-vanilla. It’s just the basics here.

What’s An SPF Record and What’s a MAIL FROM Domain?

Ha ha… that’s a trick header. We’re not going to define this stuff, because there are many web resources out there that will do that for you. And we know you’re not here for definitions. Let’s just say that we’re doing a standard email setup so that we can use SES, and that involves configuring everything so we show our email recipients (and their email servers) that our email is legit and coming from authorized sources.

Narrowing Down The SPF Record Error

Setting up SES required us to enter a good handful of records into our DNS configuration. And, if we were to believe Amazon’s error message, the problem centered around the SPF record. As “SPF record not found for custom MAIL FROM domain” clearly states, Amazon SES just couldn’t see our SPF record, even though it was configured exactly as Amazon asked.

Have you ever run into an error caused by an extra space or control character? We have. Computers are picky creatures, and sometimes you can even type an invisible character by inadvertently holding down the CONTROL key while typing. That character will freak computers out. Well, that wasn’t the problem, because we were using Amazon’s data, copied straight out of their SES dashboard.

Was it because of our subdomain? Was it because we had an MX record for both the main domain (example.com) and the MAIL FROM subdomain (subdomain.example.com)?

Here’s the Amazon SES documentation screenshot:

The bottom callout warning about multiple MX records was concerning, so we spent some time digging into that. Fortunately we found a StackExchange post that made it clear that a master domain MX record was a-okay (Amazon SES fails to weigh in on this obvious question).

SPF The Whole Damned Time

The whole time, we were grateful for one unambiguous part of Amazon SES’ instructions: “The SPF’s TXT record value has to include the quotation marks”. You can see that at the bottom of the bulleted list in the screenshot above. Thanks to that instruction, we were free to focus on many other parts of the configuration.

We also made steps by locating MXtoolbox’s SPF tester, which made it clear: Amazon SES wasn’t the only one having problems finding our SPF record. Progress!

So… eventually in our desperation we scratched our heads and threw up our hands and removed the quotation marks from the TXT record value for SPF. We had other SPF entries for other subdomains that didn’t have quotation marks, with almost exactly the same data fields.

And there you have it. That solved our “SPF record not found for custom MAIL FROM domain” problem and got us to full configuration. Don’t believe Amazon SES when setting up Amazon SES, and you are good to go. Happy sending.

Leave a Reply

Your email address will not be published. Required fields are marked *