I read blogs, as well as write one. The 'blogroll' on this site reproduces some posts from some of the people I enjoy reading. There are currently 2 posts from the blog 'Postmark.'
Disclaimer: Reproducing an article here need not necessarily imply agreement or endorsement!
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.
Hot off the heels of releasing advanced user roles and permissions, today we’re giving you a way to add extra security to your account by enabling two-factor authentication (2FA). This is another feature that we get tons of requests for, so we’re happy to finally have it in your hands.
If you’ve ever set up 2FA on any of your online accounts the process should feel familiar to you, and you should be able to use your preferred tool for Postmark authentication. You can set up 2FA with an authenticator app (we support Google Authenticator, 1Password, and Authy) or using your mobile phone number (SMS).
To set up 2FA on your account, log in to Postmark and click on your name to go to your user profile. From there you can click “Enable” next to the “Two-factor authentication” heading to start the setup process:
The setup process is straightforward, and you’ll receive an email to confirm that you’ve successfully set up 2FA on your account. We also highly encourage you to download your backup codes and save them in a safe place once you’re all set up. If you lose (or don’t have access to) your device and don’t have your backup codes handy it will be a really painful process to verify your identity and get you back into your account. You can find more detailed information about how the feature works (and what happens if you get locked out of your account) in the help doc.