Mailgun doesn't validate the email headers of email sent through their system

Natural email decay rate is 2-3% per month so the goal is to stay close to this range, but the lower the better.

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.

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.

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 :-))