Hacker News Reader

Hacker News

Comment by etjossem | Hacker News Reader

Full thread

etjossem

Some head-to-head comparisons of Mailgun and SendGrid, for those trying to find an alternative provider.

- Free Tier: Up to 10k emails/mo with Mailgun, up to 12k with SendGrid.

- Low Volume: To send 100,000 emails/mo on a shared IP, you'll pay $45 with Mailgun or $20 with SendGrid.

- High Volume: To send 300,000 emails/mo on a dedicated IP, you'll pay $204 with Mailgun or $199 with SendGrid.

- Deliverability: In today's InboxTrail comparison, Mailgun shows 62.5% inboxing, SendGrid shows 97.5%. [1]

If you need any help with your integration, I'd be happy to put you in touch with the right people on our team. My email's in my profile.

Disclosure: I'm a SendGrid engineer.

[1] https://www.inboxtrail.com/compare

View on HN

- Mailgun’s prices scale much better than Sengrid. 700,000 emails per month w/ Mailgun $316.50 vs w/ Sendgrid $399

- All paid accounts are given unrestricted access to all Mailgun features. Sendgrid feature gates by plan

- Mailgun has no punitive overages, with Sendgrid you’ll pay as high as $1 per 1000 emails for exceeding your plan. https://sendgrid.com/mkt/assets/pdfs/1-16_SendGrid_Compariso...

Disclosure: I work for Mailgun

- After Mailgun's $59 surcharge per dedicated IP (which customers will need, given your shared pool deliverability record), you'll find SendGrid's high volume prices scale pretty closely.

- We do offer plans without subuser management and whitelabeling. That's so we can be a cost-effective choice for startups and low-volume senders, which I'd argue is a good thing! Pro customers always get every feature we have to offer, including a dedicated IP.

- Overages rarely happen. In the specific case he's describing, it's nearly always going to make sense to pay $10 for 60,000 more emails.

The Mailgun spam rate of 37.5% [1] seems both awful and unusual as no other provider seems to suffer from this. Does anyone know if this data is flawed, or what's the story here?

[1] As reported by https://www.inboxtrail.com/compare

Email from Mailgun's shared IPs is being flagged as spam by Hotmail and AOL, which may indicate insufficient warmup with those services (e.g. Hotmail is not familiar with some of their shared IPs yet, and suspects them of sending spam until proven otherwise).

Methodology: a mock verification email with properly structured markup, a verification button, and no marketing content, sent to each provider. https://www.inboxtrail.com/compare#how

We had issues every few months because the server we were assigned would be added to a RBL. Customers would notice, we'd talk to Mailgun and they would move us to another server. rinse, repeat.

The only way to avoid this was to get a dedicated IP which is an additional $59 / month.

I'm not sure why Mailgun couldn't detect this themselves, maybe they do now.

We are working on this based on what we have discovered so far, there appears to be a content issue that's impacting deliverability. We have ruled out any issues with the IP address these messages are being sent from. Our lead reputation engineer going through this and we've not been successful in reaching out to the inboxtrail team yet.

Disclosure: I lead product development for Mailgun.

Though you definitely still have space for improvements. I have a Mailgun account and:

1. I didn't configure my MX so you don't track delayed (asynchronous) bounces. It should be your responsibility as an email provider to use an appropriate Return-Path so spam complaints/bounces reach back to the client in this situation.

2. I opened ticket #212817 a while ago (September) about how a MITM could capture emails and replay them by injecting duplicate Subject/From/To headers (article here: https://wordtothewise.com/2014/05/dkim-injected-headers/) but this still isn't fixed today :(

That said, we're very happy with the service :), one of the killer features is how easy it is to manage wildcard sub-domains (compared to the pain it is with Mandrill).

On issue #1, we're going to update the language around this in our control panel and put together better documentation. In reality, having MX records are important to allow for sender address verification [1], which many SMTP servers require.

On issue #2, Thanks and apologies for the slow response, This ticket slipped under our radar.

To give you a quick answer: we'll look into the approach you described in your blog post as well as RFC 6376. It seems legit but we'll need to do some more testing to ensure that deliverability does not suffer due to changing how we sign messages. If deliverability does suffer, we can always make this something that is an optional security setting that can be toggled, like how you can enable and disable TLS certificate validation now.

Our security engineer will take a look and reach out to you with more details in the ticket.

[1] https://en.wikipedia.org/wiki/Callback_verification

Thank you for replying. Glad you guys are considering this :)

Disclosure: I'm not in any way financially linked to SendGrid.

A startup I used to work at used SendGrid. I have nothing but good things to say about the experience. I liked it better than Mandrill, which I've used more recently.

I have been using SendGrid for a side project. Can't recommend it enough.

SparkPost gives you 100k emails/m for free.

I don't work for them.

Very happy with SparkPost. Love their webhooks and their advanced content substitution engine.

Reply on news.ycombinator.com