SendGrid on X

The largest theme is exit. 9 people are migrating off SendGrid, thinking about it, or objecting to how central it is. A marketing agency running some 100 client sites and about 800 sends a day is asking Resend about scale and dedicated IP requirements; one developer moved two servers across roughly 10 sending domains at the Postfix relay so no app code changed, carrying over 24 blocked addresses; others went to their own mail servers after getting "burned". One reply puts it as a principle — that you cannot just accept SendGrid is who you pay to send your email.

5 people describe a tool that simply sends: behind a hand-built newsletter, in a custom web app through the API, and for support ticket and CRM mail through the inbound parse API, with no complaints attached. 2 stay for deliverability, saying rivals' mail "all goes to spam" while SendGrid's reaches inboxes.

The largest complaint is mail that gets stopped. 7 people report being blacklisted by SendGrid, sign-up confirmations landing in spam, and a new domain-ownership compliance check that killed all of one company's inbound email with, they say, no notice. One reading of SendGrid's shared sending pool: senders get listed on blocklists because of it. Separately, someone sending at volume wonders whether Apple's private relay addresses produce fake permanent bounces claiming the inbox doesn't exist.

4 people report codes and other mail arriving late, stuck or never; three of them are about one site's sign-up codes, and one suggests a TOTP fallback because mail "doesn't arrive easily". 4 name outages and limits: emergency maintenance flagged, a monthly send cap possibly exhausted by a traffic surge, an outbox built so a provider outage doesn't block requests, and duplicate sends when retry logic breaks.

3 describe lockouts — an enterprise account unusable with support silent, a login demanding the captcha twice, a subaccount trapping settings. 3 object to the cost, one asking how to cut a $200-a-month transactional bill. 2 say one key does too much.

Resend leads the comparisons: 5 people are migrating or weighing it. A developer moved two servers over at the Postfix relay across about 10 sending domains, one at a time, testing each; another is in talks about volume for a roster of 100 client sites. One post counts 82 public pull requests that moved projects to Resend in two years, 60 of them from SendGrid, and says that among 2026 launches 82% use it. Others keep it simpler: one uses SendGrid but is "thinking to use resend", and one moved after not getting SendGrid working.

4 people weigh Amazon SES on price and per-client setup — a verified domain and configuration set per client gives a per-client bounce view, at the cost of building suppression and alerting yourself — and two of them say SES mail lands in spam where SendGrid's doesn't. 3 run their own servers after being "burned" or to cut cost, one reporting 25K–45K sends a day on four instances for about $120 a month. 2 name Cloudflare Email Sending on generous quotas and saving a subscription, and one calls Mailgun the "escape hatch" when SendGrid gets too painful.

Both questions are choice questions, and SendGrid is one candidate among several. One asks an open poll for an app sending thousands of emails a month — Resend, Postmark, SendGrid or Amazon SES — and asks which gives the best value. The other, a reply to someone who had just described what they built, asks simply "sendgrid or SES?"

Nobody asks about SendGrid's features, setup or pricing in their own right; the question is where it sits in a shortlist. With 2 posts from 2 people there is nothing more to say about what people ask.

The only wish on the page is about API key defaults. One user objects that SendGrid's API keys start with full access when, in their words, the vast majority of users "just need to send emails via apikey", and asks the company directly to make "Send Transactional Mail Only" the default instead.

It connects to a complaint elsewhere on the page, where a user with 100 domains wants a separate key per domain so a leaked key can't touch the rest, and another describes transactional email keys being drained to blast phishing until a domain is blacklisted. On its own the wish has 1 person behind it, and that is the whole of it.