Recently opened a SendGrid account on their $14.95 tier for a new project and found the shared IP blocked by MS domains (outlook.com, live.com, hotmail.com). MS servers confirmed the reason in the SMTP negotiaton as owed to the IP/provider.

We reported it to SendGrid and their only option was to upgrade to their $89.95 plan to get a dedicated IP. That plan comes with 100K monthly sends and we are nowhere near that.

So, the choice was to have a significant portion of important transactional emails, like registration, not go through or overpay for a plan that is wildly overmatched for us.

Email is hard, but this borders on unethical. Customers pay for and integrate a service that simply doesn't work as advertised. They make no offer to mitigate (e.g. change to a new shared IP). It's just "oh yeah, if you want the service to actually work reliably, you need to pay us 6X more".

You often pay for "good company" when you choose a more expensive provider. So the cheaper the provider the lower quality of their shared IP pool due to the type of customers they tend to have on the platform. The free tier lowers the customer quality even more. IF you are sending mission critical email then dedicated IP makes a lot of sense, but probably not at a huge price multiple mentioned for Sendgrid.

Amazon SES shared IP pool isn't better than Sendgrid or Mailgun but their dedicated IPs are only $25/month. If your volume is low that might be the only cost since they offer 62k/month completely free and after that it's $0.1 per 1000 emails.

Unfortunately not a lot of providers offer dedicated IP option on lower level plans.

>Amazon SES shared IP pool isn't better than Sendgrid or Mailgun...Unfortunately not a lot of providers offer dedicated IP option on lower level plans.

I think the main problem I have with SendGrid here is that they knowingly offer a paid product with such abysmal shared IP deliverability out of the gate, then offer no meaningful mitigation except to upgrade to a plan that includes the dedicated IP at a 6X premium, along with features many customers don't need (primarily send volume). Many customers will say "that's overkill, I don't need that send volume".

Very much a bait-and-switch feel to it. If they're going to offer the lower cost plans, then they need to be forthcoming about the disparity in deliverability. Instead, they say vague things like "own your reputation with a dedicated IP", when the truth is actually "12%-15% of your emails may suddenly stop being delivered unless you choose a dedicated IP plan".

Publish metrics and let people choose.

Same story here, but being a Sendgrid customer for 6+ years, suddenly the shared IP is blocked as well. After opening a lot of support tickets and getting no response, I had to nag someone here in HN who mentioned working for Sendgrid, he escalated but the response was the same: pay a lot more to get what you used to have.

Migrated to Postmark right away and we've been a happy customer for 2+ years now.

Yeah, I'd used SendGrid's higher tier on other projects for years, as the send volume justified it. So, generally had the dedicated IP address.

They need to do a better job of managing their shared IP pool. As it is, they are offering paid plans that are unsuitable for many common use cases. Really, unless you have control of all possible receiving domains (e.g you're using it for an internal app), you're rolling the dice.

Else, at a minimum, they should disclose deliverability metrics on their various plans so customers can make informed choices. As it is, their marketing is deliberately misleading.

Thanks for the feedback on Postmark. I'll have another look at them.

EDIT: Just glanced at Postmark and they're already looking much stronger than SendGrid, and with much better pricing. The "deliverability without a dedicated IP" language seems to be directly aimed at providers like SendGrid. Are they able to live up to that promise?

Also like their policy around content retention.

Will be exploring switching costs.

> Are they able to live up to that promise?

Postmark product manager here, so I'm a little biased but... yes we are! You can see our Time To Inbox stats on our status page: https://status.postmarkapp.com/

We also have a handy migration guide here: https://postmarkapp.com/migration-guides/sendgrid

Thanks for the heads up. You guys do a good job on documentation. A little redundant on the marketing side, but overall very clear. That migration guide is very well-done/thorough.

Off topic: What does "he scaled" mean in this context?

I'd guess "escalated", meaning engaged someone higher up in the company with more authority.

To me, there is one big difference with postmark. Their focus is on transactional emails. Not marketing emails. I believe they have a separate service now for marketing emails, but the big reason I chose them is that they are very focused on keeping their IP addresses clean. One way they do this is by only allowing users of their service to send transactional emails like invoices, password resets, or thing that have been specifically requested by users. I assume they keep all that on IP addresses reserved only for that. Most people won't mark a password reset email as spam. But they will frequently mark recurring marketing emails as such.

I use Postmark for everything that is very important that it gets through. I actually use mailgun for mass emails, marketing, announcements, etc.

I opened an account with Sendgrid for a new project the other week. Account got banned right away, didn't even log in one time and they said to contact support to get it unblocked. Only issue is to contact support you have to be logged in and their alternative form also wants you to log in.

Sendgrid is not friendly.

Are you using linux, by chance? Recently I've noticed Amazon, Google, and others reporting my logins from linux as "suspicious activity". I've never logged-in from another OS, so I'm wondering if they're all relying on some third-party service that automatically equates linux with "suspicious".

Yet Amazon, Google, and others all use, produce and offer Linux themselves. How can logging into a server running Linux from a desktop/laptop/handheld computer running Linux be "suspicious" activity. Is Android not Linux.

I am on Mac OS on a residential IP ¯\_(ツ)_/¯

It could be that Linux drive spam bots are using their system.

Spoofing the user agent is probably the first thing these spam bots would do.

Heavy SG user here and while it's still pretty functional and not problematic enough to move away from, it's not as good as it used to be.

Before being acquired, SG's support was fantastic. There are also various oddities that have cropped up, such as how they're currently hitting our webhook endpoint with the same event every 20 seconds for the past 8 days (a similar problem occurred last year too). They also seem to have suffered some dings to their IP reputation in numerous places due to, I assume, this: https://krebsonsecurity.com/2020/08/sendgrid-under-siege-fro... .. I continue to encounter numerous systems that flat out refuse any email from any IP I can muster at Sendgrid and we have a bunch on different subnets. So anyone who works at Red Hat, Packt, Akqa, Zendesk, etc.. they're not getting our mail.

We use Postmark as a fallback for users when we get the inevitable error messages back, and they have been pretty good, although I find their API a little too slow to move everything over to them and SG has a fantastic "delayed send" feature which is a must for deliverability to iCloud addresses.

Pragmatically I prefer Sendgrid, but Postmark is very good and feels somewhat more wholesome to use, particularly if your levels are low. I'd use Postmark for the same reason I'd rather use a local bakery than buy presliced at a supermarket.

> although I find their API a little too slow to move everything over to them

Postmark product manager here... I'd love to know more about this. We publish our API response times on our status page (https://status.postmarkapp.com/), so this is a surprising comment. Can you email [email protected] with your account details and we'll look into this for you?

To clarify for the benefit of any onlookers, I do not mean to say that Postmark's API is slow absolutely, but that it is slow(er) for how we use an email sending API relative to SG.

Our email system is custom and does all of its own merging on a per subscriber basis, so we send a distinct request for every email, so even an otherwise minor difference between a 30ms and 85ms round trip "feels" slow at scale. I believe PM has a "batch" call available, but this requires some extra dev time at our end if it would resolve our issues (and it may!)

I will get in touch, though, in case there are ways to help mitigate this problem or if the batch mechanism will solve it all. We have previously encountered similar performance issues with SG from time to time due to DNS sending us to unsuitable endpoints, etc. so it can be a universal problem to some extent based on how we've approached the problem.

(Edit: Actually, that status page maybe demonstrates what I'm talking about, since the average API response time shown is 437ms. Even with 5 concurrent threads that would take 2.42 hrs to send 100,000 emails - so I am guessing the batch API is the way to go with PM :-))

Yep /batch is definitely the way to go! But feel free to reach out to support and we can take it from there.

> What's the advantage here over SendGrid?

I am not familiar with products mentioned above but SendGrid is often discussed as a source of spoofed messages. They allow sending as 3rd party domains, or at least allowed it until recently. I suspect that this may be affecting their deliverability.

Postmark has way better visibility into what is being sent. You get per-email history/status, so you can easily tell if something is queued or bouncing. Trying to debug errors on Sendgrid is less fun.

On the other hand, postmark is a bit more flaky - I track delivery RTT and had had a few cases in my first year with them where Postmark had > 30m delays (and no outage reported). Sendgrid has always been bombproof on delivery times over many years of usage.

I still prefer Postmark on balance.

> On the other hand, postmark is a bit more flaky - I track delivery RTT and had had a few cases in my first year with them where Postmark had > 30m delays

Postmark product manager here... I'd love to know more about this. We publish our Time To Inbox on our status page: https://status.postmarkapp.com/

The only time emails might sit for longer than a few seconds is if there is some issue with the account (such a accidental spam being sent due to form abuse). If you have specific examples, can you please email [email protected] and we'll look into it for you?

i use sendgrid for a small project because it's free and has template support, but the site is unbelievably unresponsive. it takes 30+ seconds for anything to load. we have a paid account at work and it's exactly the same, so it's not my connection or the free tier. my assumption is that twilio has left it on autopilot.