I've been dealing with email deliverability for the past 4 days as part of a new project.

The requirements are to send login codes when the user provides the email for a likely small site (maybe 100 active users a month). Eventually maybe send 1 email per day per user for notification reminders or something. Everything is transactional, no marketing. (Are notifications marketing or transactional?)

I'm directly implementing the http call. Most services don't have that different of request JSON so it's pretty straightforward. I'm likely not going to use the API for anything else. A curl example will typical show everything I need to know.

The emails I want to send are basically SMS style messages. No HTML or other noise. I would prefer no body logging. I assume such short messages may be an issue for spam filters?

subject: login code body: login code: abcd

(I did have the login code in the subject too, but those show up in some console pages and I suppose are more likely to be logged)

SendGrid

I initial used SendGrid since we used it at my prior job. Generally fine when using gmail addresses, but every non-gmail mta was rejecting the emails due to the IP being in multiple blacklists. So as a new SendGrid account we were placed in a shared IP pool with blacklisted IPs.

A support request reply included a link to an April 6, 2023 blog post discussing their "shared IP address pool improvements" (https://sendgrid.com/blog/shared-ip-address-pool-improvement...). Since I won't be sending a lot of emails, don't want to track users, and users don't even have to open the email to see login codes it sounded like we would never get a better IP pool.

IDK if our usage would ever require more than the free tier max emails. However, to get out of shared IP pools, $80/mon ($960/yr, maybe theirs a deal but doesn't matter because it's a small site) is required. OK, but their support docs also say that it's up to the user to initial monitor the IP in spam blacklists, etc.

The entire thing I want to pay for is NOT having to deal with any of that and have my transactional emails delivered. Yes, some of that is on the user not spamming, but I would also be fine if they were scanning emails and notifying me of spammy behavior proactively.

So I moved on.

Postmark

Seemed promising. Said all the right things on the website. Created an account, verfied an email, got a server token, and started implementing. For unknown reasons, the use a custom header instead of standard oauth2 bearer authorization header. I could modify my code to send the custom header, but I don't like that idea. Additionally, it seems like a potential security issue as general proxies or other things that log http requests would like not log authorization headers, but would log unknown headers. Probably small.

Maybe unreasonable to abandon for such a "small" reason, but does this imply anything about their other design decisions? I didn't have a lot to lose so moved on.

Mailgun

This time checked the API first. Uses the http user for the token. Pass

smtp.com

Didn't seem like they had a free tier, seemed more oriented towards marketing. Didn't care for their website so moved on.

Amazon Simple Email Service

I don't use AWS. Terrible docs. I just need one endpoint to send an email. Not immediately obvious how to authenticate. Doesn't sound like it provides else but sending. Searches indicated maybe blacklist type problems, IDK.

SES doesn't have a standalone email company type of home page with a curl example or anything. It's just some service down in the bowels nobody cares about until it breaks. That's fine though.

MailerSend

Through Google I found MailerSend. Curl example on homepage. Signup was realitively easy except I messed up...