SendGrid
Reliable, once you treat it as infrastructure, not an API key
SendGrid sends transactional and campaign email in seven of our client systems. This is what running it past launch day has taught us.
The short answer
SendGrid is the right default for transactional email at real volume, provided someone treats domain setup and IP reputation as ongoing work, not a one-time step.
Choose differently on a new build with modest volume and a small team. Resend ships a cleaner setup with saner defaults, and we would weigh it for a new product today. We keep choosing SendGrid on existing systems because the integration already works and the setup cost is already paid.
What decides this
4 things that decide this
- 01Deliverability is not a feature you turn on. It depends on domain authentication, warm-up and ongoing list hygiene, and SendGrid's pricing page does not mention any of them.
- 02Skipping domain authentication leaves your mail sending from a shared SendGrid domain, which major inboxes trust less and route to spam more often.
- 03A new sending IP needs a gradual volume ramp. Send at full volume on day one and inbox providers read it as spam behaviour.
- 04The event webhook is the only reliable way to know a message bounced or was marked as spam. Without it, failures are invisible until a client tells you.
An email API with the delivery infrastructure behind it
SendGrid sends transactional email (receipts, password resets, verification codes) and marketing campaigns through one API. Dynamic templates, suppression lists and delivery analytics come built in. You send a request, and the pitch is that the message arrives.
What the pitch leaves out is everything between the API call and the inbox. Every major mailbox provider scores your sending domain and IP first. That score decides whether your message lands in the inbox, the promotions tab, or nowhere. SendGrid gives you the tools to earn a good score. It does not do the work for you.
Where it holds up and where it does not
Strengths
- Deliverability at scale is proven. It handles high transactional volume without us having to build retry and failover logic ourselves.
- The event webhook reports delivery, bounce, open and spam-report status per message, which is what lets a system react to a bad address automatically.
- Dynamic templates separate the email design from the send code, so a template edit does not need a deploy.
- Suppression management (bounces, spam reports, unsubscribes) is handled for you, which keeps a sender off blocklists it would otherwise earn by accident.
Trade-offs
- Domain authentication is a manual step. Skip the CNAME records for SPF and DKIM and mail still sends, from a shared domain, with worse inbox placement and no error telling you why.
- A dedicated IP needs a warm-up ramp over roughly two to four weeks. We hit this on TrialTriage: full volume from day one on a fresh IP got a chunk of appointment reminders filed as spam before we slowed the ramp down.
- Template edits made in the SendGrid dashboard are not versioned against your codebase. A marketer editing a live transactional template in the UI has broken a merge field with no pull request to review.
- The dashboard reports aggregate stats well but per-message debugging means reading the event webhook payloads yourself. There is no single screen that tells you why one specific email never arrived.
What actually needs setting up before launch
The operational chores a pricing page does not list. Get these wrong and the API call still returns 202, so nothing tells you the message failed to land.
| Chore | What it does | Skip it and |
|---|---|---|
| Domain authentication | SPF and DKIM records prove you own the sending domain | Mail sends from a shared domain with worse inbox placement |
| IP warm-up | Gradual volume ramp on a new dedicated IP over weeks | Inbox providers read full-volume sending as spam behaviour |
| Event webhook | Reports bounce, spam-report and delivery status per message | A bad address keeps getting mailed until a client complains |
| Template version control | Templates managed as code, not edited live in the dashboard | A dashboard edit to a transactional template ships with no review |
- API call sentReturns 202 whether or not it lands
- No domain authSends from a shared, lower-trust domain
- New IP, full volumeReads as spam behaviour to inbox providers
- No webhook wiredBounces and spam reports go unread
- Silent driftDeliverability degrades with nobody watching
Every one of these failures returns success from the API. To the code, a message that never arrives looks identical to one that did.
What we use it for, and what each one taught us
Broollie sends meeting summaries and billing receipts through SendGrid alongside Twilio for voice and WhatsApp. ExtraaJe uses it for HR-triggered campaign emails across a European workforce, run straight from the HR dashboard. Lexpair pairs it with Twilio to notify lawyers when a matched lead comes in, where a delayed notification is a lost case.
TrialTriage taught us the most. It runs SendGrid next to Paubox, a HIPAA-focused email provider, rather than instead of it. General appointment and status updates go through SendGrid. Anything carrying patient health information goes through the HIPAA-covered path instead. SendGrid's standard plans are not built for regulated health data. The decision was which messages needed which provider, not one choice for the whole system.
- 01Wire the event webhook before launch, not after the first support ticket about a missing email.
- 02Warm a new dedicated IP over weeks, and keep transactional and campaign sending on separate IP pools so a campaign's spam complaints do not sink password resets.
- 03Route anything carrying regulated health or financial data through a compliant provider instead, and keep SendGrid for the rest.
What teams ask before committing
01SendGrid or Resend?
Pick Resend for a new build with modest volume and a small team. Its setup asks less of you and its defaults are safer out of the box. Pick SendGrid for an existing integration or high volume, where its proven track record and detailed event data earn the extra setup cost. We run SendGrid across seven client systems and would still weigh Resend for a new product today.
02Is SendGrid production ready?
Yes, for transactional volume, once domain authentication and IP warm-up are done properly. We have run it across seven client systems without an outage caused by the platform. Every deliverability problem we have hit traced back to a setup step someone skipped, not a SendGrid failure.
03How long does IP warm-up actually take?
Roughly two to four weeks to reach full volume on a dedicated IP, sending gradually increasing amounts each day. Skip it and inbox providers read a sudden spike as spam behaviour. That is what happened to a batch of TrialTriage's appointment reminders before we slowed the ramp.
04Why did my email land in spam with no error?
The SendGrid API returns success once it accepts your message, not once an inbox accepts it. Only the event webhook shows what happens next. Skip wiring it up, and a bounce or spam report stays invisible until a user reports it.
05Can SendGrid handle regulated data like health records?
Not on its standard plans. On TrialTriage we route anything carrying patient health information through Paubox, a HIPAA-focused provider, and keep SendGrid for general appointment and status messages. Treat this as a routing decision per message type, not a single yes or no for the whole system.
