We know you're a curious bunch—and we love answering your questions. So we started a brand new webinar series, Postmark Office Hours, where you get to ask the Postmark team all your burning questions.
Our first sessions were all about Message Streams, Postmark's clever way to separate promotional and transactional email.
You can watch the recording below (it features both Office Hours sessions combined into one) or read the answers to the questions your fellow Postmark users asked us about Message Streams. (If you're opting for the written version, you'll miss the guest appearance of Brian's dog though. 🐶)
- How are Message Streams different from how Postmark worked in the past? I thought there was always streams.
- Do I have to add an unsubscribe link to Broadcast messages?
- How are lists maintained in Postmark?
- Do we have to rate-limit the number of bulk Broadcast messages that we send?
- Our messages are going to spam. Why is that happening, and how can we fix it?
- Can I send bulk Broadcast messages over a Transactional Message Stream, or vice versa?
- If a user gave consent to your MailChimp list can you send to them using Postmark?
- Is there a payload max for Postmark’s /email/batch API endpoint and how quickly will you get a response?
- How do I get started sending through Postmark? Do I need to migrate anything over?
- Can one account using Message Streams set up and send from multiple domains?
- What about GDPR when sending from the EU?
- Can I send through a Broadcast Message Stream if my SMTP client does not support custom headers?
- Do I have to worry about Postmark's upcoming TLS changes?
- Does Postmark have a sending limit for Broadcast sending?
- Should I separate my different clients into their own servers / Message Streams?
- Should I use a different email address for sending my Broadcast messages?
How are Message Streams different from how Postmark worked in the past? I thought there was always streams. #
Well, we’ve always had servers—think of those as folders to help you organize email for different clients, use cases, production and staging environments, or similar.
Message Streams are different. With Broadcast Message Streams we’ve created a separate, but parallel, infrastructure for sending promotional email like your newsletters, product announcements, or similar. Because different types of email have various origins as well as vulnerabilities, we have always recommended separating transactional traffic from other types of email by using different sending IPs and From domains. Message Streams let you do just that.
Other email providers send promotional and transactional email over—shudder—the very same set of IP pools. That means your time-critical password reset emails might get stuck behind a big newsletter send. Or a wonky marketing campaign that caused lots of spam complaints might cause deliverability issues with your transactional emails.
When you separate your email with Postmark Message Streams, that won’t happen—and you can see great results for your transactional and marketing email.
Do I have to add an unsubscribe link to Broadcast messages? #
Nobody likes finding email in their inbox that they don’t wish to receive. Giving your subscribers an opportunity to opt-out from receiving email is crucial—and that’s why all emails that are sent through a Broadcast Message Stream are required to have an unsubscribe link. We’re adding them by default.
Transactional emails sent through a transactional stream, on the other hand, don’t require an unsubscribe link.
And what if I have my own unsubscribe process?
We understand that you might want to integrate Postmark into your existing unsubscribe processes to avoid duplicate unsubscribes. If that’s the case, reach out to us and tell us more about how you’re managing your unsubscribes and we might be able to help you out!
How are lists maintained in Postmark? #
We do not store any of your mailing lists in Postmark. You host those yourself and keep them all in your own database outside of Postmark.
What we do manage, though, is suppressions. We keep track of your bounces, spam complaints, and unsubscribes, and it’s important that you keep this list up-to-date with similar lists you might keep outside of Postmark. You can either import those via the UI or access it via the API.
Do we have to rate-limit the number of bulk Broadcast messages that we send? #
For your first bulk send through a server’s Broadcast Message Stream, we ask that you stick with batches of 20k messages per hour for the first 12 hours of sending. This provides some time for receivers to see engagement, and for you to spot any deliverability issues before the real sending begins.
Sending in larger, faster batches right out of the gates can cause deliverability issues. ISPs, like Gmail, might think your messages are spam if you’re suddenly sending 200k-300k messages out of the blue from a new sending service.
So limiting your sending for at least the first 12 hours is highly recommend. Once you’ve done that and things are looking good, you can ramp up your sends.
Our messages are going to spam. Why is that happening, and how can we fix it? #
It’s never fun to see your messages land in spam, and it’s not always clear right away what may be causing it. Postmark has a 99% deliverability rate, so we have you covered on our end of things. But the sending reputation of your FROM domain, your message’s content, and your past recipient engagement are all major factors that come into play.
The first step we’d recommend is to make sure you’re following as many sending best practices as possible. We have a great guide on best practices for Broadcast Sending that provides tons of ways to increase your chances of landing in the inbox (and most can be applied to transactional sending, too.)
If you're following all that advice and still seeing deliverability issues, definitely feel free to reach out to our support team with some details and we’re always happy to help.
Can I send bulk Broadcast messages over a Transactional Message Stream or vice versa? #
We ask that all bulk messaging be sent through a Broadcast Message Stream and all one-off transactional messages through a Transactional Message Stream. The reason for this is that our message streams are set up on completely separate sending infrastructures, with specific IPs used for the different types of sending.
So sending a bulk Broadcast message through a Transactional Message Stream means the message will use our transactional IPs which can cause issues with deliverability and harm to our transactional IPs—which are managed in a way to only send transactional messages.
We have more here on how to create and send through Message Streams.
And if you’re ever having trouble deciding whether your email should be sent using a Broadcast or a Transactional Message Stream, don’t hesitate to reach out! We’re here to help.
If a user gave consent to your MailChimp list can you send to them using Postmark? #
Yes, you can! Consent isn’t typically specific to the service you use to send the messages, so as long as those recipients have explicitly opted-in to receive the messages you’ll be sending through Postmark, you’ll be fine.
You’ll want to make sure all recipients meet these permission requirements for any sort of bulk Broadcast Message you send:
- You're only sending to recipients who explicitly opted-in for that specific message(s). So that means no sending to general customer/contact lists, or people who simply gave their permission by agreeing to a Terms of Service, etc. They must have explicitly made an action, like checking a box, to opt-in to receive these messages.
- You're only sending to recipients who you've been in touch with within the past 3 months, or who have opted-in within the past 3 months. Sending to recipients who you haven't been in touch with over the past three months will always lead to high bounce rates and spam complaint rates.
We have more details about what Postmark considers as permission to send here.
Is there a payload max for Postmark’s /email/batch API endpoint and how quickly will you get a response? #
When using the batch sending endpoint the total payload size, including attachments, cannot exceed 50 MB. We also ask that you only ever have 10 concurrent connections open at a given time with a single API token.
Typically the response back from our API when using our batch endpoint will be within a second or two, though for larger sends it may take a bit longer.
How do I get started sending through Postmark? Do I need to migrate anything over? #
In most cases, you can just create a Postmark account and go! If you have an existing list of inactive recipients to exclude from sending, you can add them to your Message Stream’s Suppressions tab in the UI or via our Suppressions API.
Can one account using Message Streams set up and send from multiple domains? #
You can do this by setting up Sender Signature email addresses for sending or by verifying a sending domain via DKIM (preferred). Sender Signatures and domains are account-wide—meaning they can be used across all Message Streams and servers in an account.
We have some in-depth information here on how you can send on your customers' behalf and how to add multiple sender signatures and domains in one account.
What about GDPR when sending from the EU? #
Postmark has worked very hard to ensure we are GDPR compliant and we have a dedicated page that goes more in-depth and covers how we’ve accomplished that. GDPR does not require you to send through servers in the EU, and you are totally fine to send EU emails through Postmark.
We also have a wonderful blog post written by our GDPR expert, Rian, about Postmark’s response to the recent Schrems II Judgment.
Can I send through a Broadcast Message Stream if my SMTP client does not support custom headers? #
Unfortunately, not yet. In order to send through a Broadcast Message Stream, your SMTP client must have the ability to add additional headers. Specifically, the X-PM-Message-Stream header where you’d specific your Broadcast Message Stream’s Stream ID.
If your SMTP client does not allow for those additional headers then messages will automatically be sent through your default Transactional Message Stream and there is not a way to set a different stream as the default.
We’re actively looking into ways to allow you to send through a Broadcast Message Stream without having to add those additional headers, so stayed tuned!
Do I have to worry about Postmark's upcoming TLS changes? #
No. Yes. Maybe! For context, on April 13, 2021, Postmark is going to (1) disable TLSv1.0 access, (2) disable all RC4 and low-strength ciphers, and (3) add HSTS headers.
To help, we've contacted all Postmark accounts who are still using a TLSv1.0 connection with some details on how to upgrade so that your sending is not impacted. If you are a Postmark account owner, admin, or emergency contact and you have not received an email from us about this to your Postmark-related email address, then that means no action would be needed and you're already set to go.
If you'd like to learn more about our TLS changes and how you can ensure your sending infrastructure is able to deal with these changes prior to the April 13 cutover date, check out our helpful update on the subject here.
Does Postmark have a sending limit for Broadcast sending? #
We do not have an overall sending limit for Broadcast sending. Using our /email/batch API endpoint you can send in batches of 500 recipients through your Broadcast Message Stream. Beyond that, we just require that your Broadcast Messages Stream's spam complaint remains below 0.1% and the bounce rate below 10%! Happy sending!
Should I separate my different clients into their own servers / Message Streams? #
That'd be a big heck ya! We definitely recommend you set up each client/customer on their own server within your Postmark account, and then you can separate a client's own sending even more with Message Streams.
Having each client set up on their own server helps separate their sending and sending stats. This makes it easy to see which of your customers is seeing an awesome open rate, or if a client is struggling with their bounce or spam complaint rate.
Even more importantly, separating clients across servers makes sure if on the off chance we need to pause a client's sending due to a high bounce or spam complaint rate that it only impacts that specific message stream's sending, and not the sending of your other servers or streams.
Should I use a different email address for sending my Broadcast messages? #
Yes! Even more so, we recommend using a sub-domain to help separate your transactional and bulk Broadcast sending. So, for example, for transactional sends you could use your overall domain (firstname.lastname@example.org), and for bulk Broadcast sends you would want to use a sub-domain of that (email@example.com).
Sub-domains develop their own, separate sending reputation! How cool is that? So by separating your sending like this, you can ensure that any negative reputation issues to your overall domain wouldn't impact your sub-domain sending, or vice versa.
We have some really great information on how domains and deliverability work here!
“There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question.”
― Carl Sagan
Have question that just can't wait? Don't hesitate to reach out to our customer success team and we'll be more than happy to help!