What is Postmark and what are its top alternatives?
Top Alternatives to Postmark
- Mailgun
Mailgun is a set of powerful APIs that allow you to send, receive, track and store email effortlessly. ...
- SparkPost
SparkPost is the world’s #1 email delivery provider. We empower companies with actionable, real-time data to send relevant email to their customers which increases engagement and both top and bottom line revenue. ...
- Twilio SendGrid
Twilio SendGrid's cloud-based email infrastructure relieves businesses of the cost and complexity of maintaining custom email systems. Twilio SendGrid provides reliable delivery, scalability & real-time analytics along with flexible API's. ...
- Mandrill
Mandrill is a new way for apps to send transactional email. It runs on the delivery infrastructure that powers MailChimp. ...
- Amazon SES
Amazon SES eliminates the complexity and expense of building an in-house email solution or licensing, installing, and operating a third-party email service. The service integrates with other AWS services, making it easy to send emails from applications being hosted on services such as Amazon EC2. ...
- Mailjet
Mailjet is a real-time Cloud Emailing platform: scalable, agile and flexible. Our unique algorithm boosts your deliverability and our platform provides in-depth insight so you can optimize more than ever. ...
- Mailchimp
MailChimp helps you design email newsletters, share them on social networks, integrate with services you already use, and track your results. It's like your own personal publishing platform. ...
- SendinBlue
It is a digital marketing toolbox that's built to scale and adapt with you as you grow. You can save time and boost performance by automating your segmentation and marketing messages. ...
Postmark alternatives & related posts
- Quick email integration178
- Free plan148
- Easy setup91
- Ridiculously reliable67
- Extensive apis53
- Great for parsing inbound emails30
- Nice UI25
- Developer-centric22
- Excellent customer support15
- Heroku Add-on12
- Easy to view logs of sent emails4
- Email mailbox management for developers4
- Great PHP library2
- Great documentation2
- Great customer support, love rackspace2
- Better than sendgrid not ask too many question1
- Cost2
- No HTTPS tracking links supported2
- Emails go to spam due to blacklisted IP's of mailgun1
- Cannot create multiple api keys1
related Mailgun posts
We've moved our transactional email away from Mandrill to Mailgun. We had continued using Mandrill after Mailchimp deprecated the service awhile back, because the amount of credits we were offered essentially made it free.
However, following a couple weeks of frequent downtime and poor service transparency from Mandrill, we decided it was time to make the switch. It appears they no longer had any engineers with the ability to identify the core problems.
Mailgun has been more reliable, yet not as reliable as we expected. We still see issues a few times per week with the API failing when we attempt to make a call. The Reporting UI is way better.
- I could start sending real emails in less than 5 mins10
- Email don't end up in spam after DNS verification2
- Flexible, robust API1
- Very easy to integrate with Laravel1
- Suspended paid acount without warning or reason1
- Spam trap reports are suspicious b/c all users opted in1
- Support won't answer mail (9h so far)1
- Only free for 100 emails/day1
- New dedicated ip blacklisted by some clients1
related SparkPost posts
- Easy setup190
- Cheap and simple137
- Easy email integration!107
- Reliable86
- Well-documented58
- Generous free allowance to get you started28
- Trackable25
- Heroku add-on21
- Azure add-on15
- Better support for third party integrations13
- Simple installation6
- Free plan6
- Helpful evangelist staff4
- Great client libraries4
- Great support3
- Better customer support than the competition3
- Great add-ons3
- Nice dashboard2
- Scalable2
- Web editor for templates1
- Cool setup1
- Within integration1
- Easy set up1
- Free1
- Great customer support1
- Google cloud messaging1
- Google analytics integration is not campaign-specific3
- Shared IP blacklist removal takes months1
- Shares IP blacklist removal0
related Twilio SendGrid posts
Repost
Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.
Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.
Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.
Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.
Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku. However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.
Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.
Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.
Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.
Mandrill
- Simple installation189
- Great api141
- Generous free allowance to get you started123
- Cheap and simple114
- Trackable99
- Well-documented59
- Doesn't go to spam54
- Great for mailchimp users47
- Webhooks32
- Client libraries28
- Heroku Add-on7
- Easy to use6
- Meaningful Metrics5
- Free5
- Advanced Tagging and Reports3
- Mobile Access3
- Status Update3
- Very chimp-like2
- Great Documentation2
- love this service2
- Free Plan1
- Webhooks for bounce mail1
- Really hard to pull analytics out via api1
related Mandrill posts
We've moved our transactional email away from Mandrill to Mailgun. We had continued using Mandrill after Mailchimp deprecated the service awhile back, because the amount of credits we were offered essentially made it free.
However, following a couple weeks of frequent downtime and poor service transparency from Mandrill, we decided it was time to make the switch. It appears they no longer had any engineers with the ability to identify the core problems.
Mailgun has been more reliable, yet not as reliable as we expected. We still see issues a few times per week with the API failing when we attempt to make a call. The Reporting UI is way better.
Hi, I've noticed my Mandrill emails are being received fine but my Mailchimp emails, about 75% are going into junk mail. I was wondering is it possible I have missed some sort of integration or can I send my Mailchimp marketing emails via mandrill?
Need help to somehow reduce the number of my emails going into junk mail, can someone help?
- Reliable102
- Cheap96
- Integrates with other aws services57
- Easy setup52
- Trackable18
- Easy rails setup2
related Amazon SES posts
We decided to use AWS Lambda for several serverless tasks such as
- Managing AWS backups
- Processing emails received on Amazon SES and stored to Amazon S3 and notified via Amazon SNS, so as to push a message on our Redis so our Sidekiq Rails workers can process inbound emails
- Pushing some relevant Amazon CloudWatch metrics and alarms to Slack
In 2012 we made the very difficult decision to entirely re-engineer our existing monolithic LAMP application from the ground up in order to address some growing concerns about it's long term viability as a platform.
Full application re-write is almost always never the answer, because of the risks involved. However the situation warranted drastic action as it was clear that the existing product was going to face severe scaling issues. We felt it better address these sooner rather than later and also take the opportunity to improve the international architecture and also to refactor the database in. order that it better matched the changes in core functionality.
PostgreSQL was chosen for its reputation as being solid ACID compliant database backend, it was available as an offering AWS RDS service which reduced the management overhead of us having to configure it ourselves. In order to reduce read load on the primary database we implemented an Elasticsearch layer for fast and scalable search operations. Synchronisation of these indexes was to be achieved through the use of Sidekiq's Redis based background workers on Amazon ElastiCache. Again the AWS solution here looked to be an easy way to keep our involvement in managing this part of the platform at a minimum. Allowing us to focus on our core business.
Rails ls was chosen for its ability to quickly get core functionality up and running, its MVC architecture and also its focus on Test Driven Development using RSpec and Selenium with Travis CI providing continual integration. We also liked Ruby for its terse, clean and elegant syntax. Though YMMV on that one!
Unicorn was chosen for its continual deployment and reputation as a reliable application server, nginx for its reputation as a fast and stable reverse-proxy. We also took advantage of the Amazon CloudFront CDN here to further improve performance by caching static assets globally.
We tried to strike a balance between having control over management and configuration of our core application with the convenience of being able to leverage AWS hosted services for ancillary functions (Amazon SES , Amazon SQS Amazon Route 53 all hosted securely inside Amazon VPC of course!).
Whilst there is some compromise here with potential vendor lock in, the tasks being performed by these ancillary services are no particularly specialised which should mitigate this risk. Furthermore we have already containerised the stack in our development using Docker environment, and looking to how best to bring this into production - potentially using Amazon EC2 Container Service
- Simple7
- Cheap6
- Reliable2
- Setup1
- Integrates with Zapier1
- outsourcing1
- Support does not respond1
- Support is a joke1
related Mailjet posts
We are using React Native in #SmartHome to share the business logic between Android and iOS team and approach users with a unique brand experience. The drawback is that we require lots of native Android SDK and Objective-C modules, so a good part of the invested time is there. The gain for a app that relies less on native communication, sensors and OS tools should be even higher.
Also it helps us set different testing stages: we use Travis CI for the javascript (business logic), Bitrise to run build tests and @Detox for #end2end automated user tests.
We use a microservices structure on top of Zeit's @now that read from firebase. We use JWT auth to authenticate requests among services and from users, following GitHub philosophy of using the same infrastructure than its API consumers. Firebase is used mainly as a key-value store between services and as a backup database for users. We also use its authentication mechanisms.
You can be super locked-in if you also rely on it's analytics, but we use Amplitude for that, which offers us great insights. Intercom for communications with end-user and Mailjet for marketing.
- Smooth setup & ui259
- Mailing list248
- Robust e-mail creation148
- Integrates with a lot of external services120
- Custom templates109
- Free tier59
- Great api49
- Great UI42
- A/B Testing Subject Lines33
- Broad feature set30
- Subscriber Analytics11
- Great interface. The standard for email marketing9
- Great documentation8
- Mandrill integration8
- Segmentation7
- Best deliverability; helps you be the good guy6
- Facebook Integration5
- Autoresponders5
- Customization3
- RSS-to-email3
- Co-branding3
- Embedded signup forms3
- Automation2
- Great logo1
- Groups1
- Landing pages0
- Super expensive2
- Poor API1
- Charged based on subscribers as opposed to emails sent1
related Mailchimp posts
As a small startup we are very conscious about picking up the tools we use to run the project. After suffering with a mess of using at the same time Trello , Slack , Telegram and what not, we arrived at a small set of tools that cover all our current needs. For product management, file sharing, team communication etc we chose Basecamp and couldn't be more happy about it. For Customer Support and Sales Intercom works amazingly well. We are using MailChimp for email marketing since over 4 years and it still covers all our needs. Then on payment side combination of Stripe and Octobat helps us to process all the payments and generate compliant invoices. On techie side we use Rollbar and GitLab (for both code and CI). For corporate email we picked G Suite. That all costs us in total around 300$ a month, which is quite okay.
When starting a new company and building a new product w/ limited engineering we chose to optimize for expertise and rapid development, landing on Rails API, w/ AngularJS on the front.
The reality is that we're building a CRUD app, so we considered going w/ vanilla Rails MVC to optimize velocity early on (it may not be sexy, but it gets the job done). Instead, we opted to split the codebase to allow for a richer front-end experience, focus on skill specificity when hiring, and give us the flexibility to be consumed by multiple clients in the future.
We also considered .NET core or Node.js for the API layer, and React on the front-end, but our experiences dealing with mature Node APIs and the rapid-fire changes that comes with state management in React-land put us off, given our level of experience with those tools.
We're using GitHub and Trello to track issues and projects, and a plethora of other tools to help the operational team, like Zapier, MailChimp, Google Drive with some basic Vue.js & HTML5 apps for smaller internal-facing web projects.
- Cheap & Simple1
- Free Unlimited Contact Storage1
- French product1
related SendinBlue posts
Quasar Framework FeathersJS Node.js Vue.js SendinBlue Zeit Now GitHub
It was almost too easy to build a complete Feathers Rest API combined with Quasar SSR and reactive form that we are serving through an i-frame within our main site for serving our newsletter signup and opt-in page. Total time: 15 hrs. Check it out: