E-mail deliverability

Updated . Posted . Visible to the public. Repeats.

When your application is open for public sign up and sends out transactional e-mails to a large number of users, e-mail deliverability becomes an issue.

E-mail providers work hard to eliminate spam and have put in place relatively tight checks what kinds of emails they will accept, and from whom. To that end we use tools like mail-tester.com to make our mails as acceptable as possible. Unfortunately, there will always be providers that reject our e-mails for some reason or other, sometimes outside of our control.

For example, on one of our bigger projects, our servers are on a denylist for all of Microsoft's cloud e-mail (like @outlook.com) for no apparent reason. Attempts to get removed from the denylist were rejected. We then started to send out e-mails via Amazon's SES service, only to discover that we were now blocked by several German providers like @web.de.

Thus, the recommendation is to use a service that specializes in maintaining high deliverability. Integration is always simple, they all can be used as a standard SMTP relay.

Providers that we have tried

In the past, we have used the following providers:

brevo/sendinblue Show archive.org snapshot

Pro:

  • Very good deliverability
  • European company with european servers (hence no GDPR headaches)

Cons:

  • Quite expensive
  • No staging sandbox
  • No permission system for api keys
  • No authentication mechanism for webhooks besides IP ranges
  • Buggy admin UI

SendGrid Show archive.org snapshot

Pro:

  • Very good deliverability
  • Not quite as expensive

Cons:

  • No european servers

Mailgun Show archive.org snapshot

Pro:

  • Very good deliverability
  • Dedicated IP address
  • API and API client for Ruby

More about deliverability

Tobias Kraze
Last edit
Henning Koch
License
Source code in this card is licensed under the MIT License.
Posted by Tobias Kraze to makandra dev (2021-03-10 10:10)