We manage our own mail server; however, some big mail provider company (among other things), let’s name it the big M, has the very annoying habit of randomly blacklisting the entire IP range of our hosting provider because, maybe, some hosts within the DC are botnet-ed to the core. And we could ask to whitelist our IP, the entire block would get blacklisted again the following month, and that would take precedence.

Now since virtually everybody on the Internet uses either Outlook or Gmail as it’s email provider, that meant that at times a large chunk of our outbound emails would just get totally dropped, and we wouldn’t know about it until users complained.

Having given up with the big M since early 2000, I configured an Amazon SES relay for those problematic destinations. Our emails are relayed there when they need to reach an Outlook destination, and thankfully, they didn’t block AWS yet.

In addition, we also configured SPF and DKIM, so our domain doesn’t get wickedly used for spam. That works well when using our own SMTP, but when passing through the SES relay, the Mail-From/Return-Path/Bounce-Address would be rewritten as coming from {region}.amazonses.com. Hence, the relaxed SPF alignment check would fail. It requires that the Return-Path (rewritten to {region}.amazonses.com) be a subdomain or exact match of the From header (our own domain).

To remedy that, you need to have your domain registered as a verified identity in SES. Then in Amazon SES > Configuration: Identities > yourdomain, edit Custom MAIL FROM domain to a subdomain of yours. In our case, we used ses-relay.ourdomain, but it can be anything really. It just has to be a sub-domain.

You will also have to configure an MX record on that subdomain to bounce back to Amazon SES. The console gives you proper record to use, it looks like MX 10 feedback-smtp.{region}.amazonses.com. You also need to configure an SPF record on that subdomain to ensure that mail sent from the relay pass the SPF check. They recommend "v=spf1 include:amazonses.com ~all" for that, but we were a bit stricter and went with "v=spf1 include:{region}.amazonses.com -all".

You can choose the behavior should your MX on the subdomain be improperly configured or unreachable. Either it will reject the mail, or it will fallback to rewriting the Mail-From to the default of {region}.amazonses.com. I choose the former, because if it fails, I want it to fail hard. The latter, you would only find in your DMARC reports if you dutifully analyze all of them, all the time. That could be done if the DMARC reports were somehow automatically analyzed be we don’t do that yet.

Another thing that got me scratching my head for like an hour is that, in our case the custom Mail-From was not honored. Even though it was configured correctly in the console and the configuration marked as Successful, the source of the mail were still showing with a Return-Path under {region}.amazonses.com. The reason why was that we still had other SES identities that were used for testing, especially Email address identities. And seeing the matching email address, it would use those identities configuration instead of the domain identity configuration, thus ignoring the custom Mail-From. Actually found that out from this stackoverflow post.