We constantly talk about the importance of your transactional emails arriving quickly to your customers. Even a minute late can cause problems or frustration, so we work hard to maintain the best performance possible. Customer facing emails are the obvious messages, but what about the messages that only a select group in your company views? I’m talking about messages that come from your servers such as alerts, cron tasks, error emails, and so on.
What would happen if you didn't get an error email, or your backup script had an error and you didn’t get the email?
This sounds obvious, but emails from your systems and servers are critical. What would happen if you didn't get an error email, or your backup script had an error and you didn’t get the email? The truth is, these emails are easy to neglect. They are only seen when things go wrong and usually only visible to a small group of people. A good example is Gitlab’s recent outage where a single alert for database backups was missed due to a DMARC reject policy, causing disastrous results.
Let’s go through some types of emails and how you can handle them for proper delivery.
Application error emails #
It’s common in Postmark to see customers tie in error reporting into their email. You already have the Postmark library integrated with your app and it’s easy to push those errors to an email address. For the most part this works, until something breaks. It’s not until you’ve sent 100,000 emails to a single Gmail account that you realize this is incredibly inefficient. Not only will some alerts go off on our side, but Gmail will probably start locking up your mailbox as well. When your app is on fire, this is the last thing you need.
Instead, a better approach is to use one of the purpose built products that handles error reporting. A few products that come to mind are Bugsnag, Honeybadger, Sentry, Raygun, and New Relic. With these products you not only avoid delivery issues and delays, but you get a concise way to parse and combine errors from your app.
It’s not until you’ve sent 100,000 emails to a single Gmail account that you realize this is incredibly inefficient.
Servers: Cron, scripts, and user accounts #
In most cases your servers will have some tasks or processes running that send emails. This could range from backup scripts, to user accounts, to cron tasks. It’s common for these emails to be sent directly from the localhost. In most cases the localhost mail server has not been configured and lacks the proper infrastructure to get emails to the inbox. Sure, you may receive them, but it’s risky. For example, many EC2 IP addresses are already on black lists, you will lack proper bounce and spam handling, and SPF or DKIM support is usually not considered at all.
Instead, a more effective approach is to relay these through Postmark. This can be done through something like Postfix or Sendmail. By relaying through Postmark you immediately benefit from the same infrastructure that you rely on for your customer facing emails. You will make sure you use proper ‘From’ domains, as well as email authentication.
Ideally, and if possible, the best approach is to use an alternative alerting or check-in system. Services like Pagerduty, OpsGenie, and Dead Man’s Snitch are a great fit. This approach builds on the infrastructure and process they’ve built into their systems to improve your reaction time and ability to get the right person on the task.
Using DMARC to identify sources #
What if you have an established application and don’t know all the sources where email for your domain originates? As we’ve seen, publishing a DMARC “reject” policy can backfire. On the other hand, DMARC with a “none” (or monitor) policy can go a long way to help you identify email sources. By using a service like our DMARC reporting tool you can slowly identify the servers on your network that are sending emails. In each case you can determine if they are properly authenticated, and if not make sure you relay them through Postmark or hand them off to an external service.
Handle system emails with care #
Even though system emails may not be high volume, they're absolutely mission critical by every definition of the word. A single missed or undelivered email address can lead to catastrophic failure of key processes that ensure your business runs smoothly and reliably. Make sure you're giving these critical emails the attention they deserve and not relegating them to afterthoughts of implementation.