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 the domain verification. I'm using Google
Domains with Google Workspace which creates its own SPF record. It's not
immediately obvious that exists in Google Domains and then requires deleting
the entire Google Workspace sythetic record. That's not MailerSend's fault
though as they did have a useful error message that I didn't read.

They require filling out a form to approve everyone before sending email
outside your domain. Seems like humans are actual doing the approval.
My initial submission was denied, but resubmitting with more detailed info
about company/site (more than 6 words) was approved.

MailerSend's domain verification success email went to my gmail spam. So that
wasn't a good start.

The IP isn't in a blacklist and my test users that were having problems are at
least receiving login codes now. At least 1 went to spam.

I can't say if MailerSend will turn out to be any good long term, but ok so far.

Conclusion

A recurring problem with all of these services is that my usage will likely
only fall into the free tier with paid tiers being excessively expensive for a
small site. If they aren't making money off me, they likely aren't going to
care if I have problems. A $20/yr plan would probably be fine or up front buy
a bunch of email sends or something.

It feels like any company that starts out targeting transactional only
eventually is either bought by a marketing company or adds marketing emails.
You certainly can't grow revenue off small sites using free tiers and likely
can't if VC backed either.

Since it's a low volume of emails, it seems like as long as my server IP isn't
already blacklisted and I setup SPF/DKIM I could probably send the SMTP directly
and skip the middleman. Maybe when I get time.

Sorry that's so long. Maybe some of its useful. Did anyone actually read to the end?

EDIT: I don't care at all about email templates