EMAIL / LESSON 09
Postmark Basics.
What Postmark is, how message streams and servers work, and when to pick it
Loading the lesson…
Loading activities…
Browse lessons
EMAIL / LESSON 09
What Postmark is, how message streams and servers work, and when to pick it
Loading the lesson…
Loading activities…
You've already met Resend, SendGrid and Amazon SES, three ways to send email from your app. Postmark is one more service doing the same core job, except it's built around one idea above everything else... getting the emails your users are actually waiting for into their inbox, FAST.
Postmark is an email sending service. Your app talks to it through an API (or through SMTP, the older standard way computers pass email around), and Postmark handles the hard part, which is actually delivering the message.
Postmark calls itself a transactional email service. That word "transactional" matters a lot here, so let's slow down on it for a sec.
An app sends two broad kinds of email.
Transactional email is a one-to-one message that somebody triggered by doing something. Postmark's own description is that transactional email "is typically a unique, high-priority message sent to a single recipient." Here are a few examples.
The person is usually sitting there staring at their inbox waiting for it. If it shows up ten minutes late, or lands in spam, your app feels broken to them.
I've watched what that looks like in real life. A client of mine had 49 form-fill notifications silently disappear after an Outlook update on their end. The sending side said "delivered" every single time... and nothing ever hit the inbox. "Delivered" and "in front of a human" are two VERY different things.
Broadcast email is one message going out to lots of people at once. Newsletters, product announcements and marketing campaigns all live here. Postmark describes broadcast email as email that "is sent to multiple recipients at once."
| Transactional | Broadcast | |
|---|---|---|
| Who gets it | One person | Many people |
| Why it is sent | Something the person did | You decided to send it |
| Examples | Password reset, receipt | Newsletter, announcement |
| Unsubscribe link | Not required | Required by Postmark |
Postmark keeps those two kinds of email apart with something called message streams. A message stream is basically a lane that a group of emails travels down.
There are two sending types of stream.
Postmark says it runs these on separate sending infrastructure, with "Dedicated transactional IPs" and "Separate, parallel broadcast IPs." An IP here is the address of the machine that sends the email. Keeping them apart means a noisy newsletter can't drag down the reputation of your password resets.
Every Postmark server comes with a default Transactional stream. In the API, that stream's ID is outbound. If you send an email and don't say which stream to use, Postmark sends it through that default Transactional stream. You can add a Broadcast stream yourself whenever you need one.
When you send, you pick your lane with a field called MessageStream. For example, "MessageStream": "outbound" sends through the default Transactional stream.
There's also an Inbound stream type, which is for receiving email into your app instead of sending it. You won't need it for a first project.
The second idea to get comfy with is the server. In Postmark, a server isn't a physical computer you have to babysit. Postmark's documentation calls servers "a way to organize the emails that you are sending or parsing."
The easiest way to picture a server is as a folder for one project. Postmark gives these example uses.
Each server gets its own API token (the secret key your code uses to send), and its activity and stats are tracked separately. So if you build two apps, giving each one its own server keeps their emails, stats and keys from getting tangled up.
Message streams live inside a server. Put together, the full picture looks like this.
Postmark manually reviews every new account before it can send to anybody. Until your account's approved, you can only send to email addresses on the domains you've added to your account and verified.
Postmark says the review gets done "in less than 24 hours on weekdays and a little longer on the weekends." While you wait you can still use the API, build templates, try out webhooks and send test emails to your own verified domain. You can also send to Postmark's test address, test@blackhole.postmarkapp.com. Anything sent there gets dropped on the receiving end, but you can still see it in your Activity.
Postmark's pricing page says every new account starts on a free developer plan with 100 emails per month, and that plan doesn't expire. That's plenty to build and test with, but it won't cover a real app with real users.
Paid plans are priced by how many emails you send each month. Prices change over time, so check the pricing page for current numbers before you pick a plan.
Postmark and Resend can both send your app's emails. So how do you choose? Here's a plain way to think about it.
Postmark is a good fit in these cases.
If you've already got Resend working and you're happy with it, there's no need to switch. Neither choice is forever, either. Both are reached through an API, so switching later mostly means changing the handful of lines of code that send mail.
outbound, and you choose a stream with the MessageStream fieldIn the next lesson you'll set up a Postmark account, create a server, verify your domain and send your very first email from Node...