Transactional emails that are sent by a software system have a specific reason compared to a newsletter. Password resets, order confirmations, invoices and reminders are just a few examples. Such emails are an integral part of a system and not something that is done on the side just for fun.

But best practices moves sending emails literally outside the HTTP request cycle into background jobs. While this is a good thing for various reasons it also makes sending emails even more obscure to developers and operators.

Instead of shoving emails into a generic background job framework they should be treated with the respect any other value generating part of the system receives.

Privileged operators should have insight into what emails are getting sent and their delivery status. Services like Postmark have rich APIs to make email delivery insightful.

Similar to a letter an undeliverable email should come back to the system so a human can take action to resolve the problem. Instead an undeliverable email usually ends up in a dead job queue.

To provide even better insights the system can show upcoming email deliveries that will be triggered by the passing of time. This is not trivial to implement but helps immensely understanding a complex software system.