The SendGrid free tier changed: what to do now

For a decade, "use the SendGrid free tier" was the reflex answer for any side project that needed to send mail. That reflex is out of date, and a lot of tutorials still repeat it. If you are here because your free account stopped behaving the way an old blog post promised, this is what to check and what to do next.

26 June 2026 · 5 min read

Check what your account actually has#

Do not trust any number you read in an article, including this one. Free tiers change, they change per region, and they change for accounts created before and after a given date. Open your own billing page and read the current allowance and the current price above it.

The three things worth writing down:

• Your monthly send allowance and what happens when you exceed it: hard stop, or overage billing.
• Whether the plan you are on still exists for new signups, because grandfathered plans are usually the first thing removed.
• Whether dedicated IP, suppression management, and event webhooks are included or gated. Losing the event webhook is worse than losing volume, because you stop hearing about bounces.

Check the current pricing page for anything you are unsure of. Anyone quoting you a specific figure for a competitor's free tier in a blog post is quoting something they have not verified today.

Decide what you actually need#

Most people reaching for a free tier are in one of three situations, and they have different answers.

That last row is the one that catches people. Free transactional tiers are not a place to send a newsletter from, and doing it is the fastest route to an account review. The reasoning is in transactional email versus marketing email.

What to move to#

The honest framing: at side project volumes, every provider in this category is roughly free or roughly the price of a coffee, so pick on setup time and on whether you can debug a delivery problem, not on the headline number.

• [Amazon SES](/vs/amazon-ses) is the cheapest at volume and the most work. You get sending and almost nothing else: no templates, minimal logs, and a sandbox you must apply out of before you can mail arbitrary addresses. Good if you have ops capacity, poor as a first provider.
• [Postmark](/vs/postmark) is the deliverability-first option and refuses bulk marketing mail, which is exactly why its transactional placement is strong.
• [Mailgun](/vs/mailgun) is worth a look if you also need inbound routing.
• [Brevo](/vs/brevo) makes sense if the same team sends marketing mail and you want one vendor.
• [Resend](/vs/resend) and emails.sh are the modern API-first shape: one endpoint, an SDK, verification in a screen.

A fuller comparison, including when to stay where you are, is in Resend alternatives, compared honestly.

Migrating without a deliverability dip#

The mistake is treating this as a code change. The code is the small part.

1. Centralise the send first. If you have fetch calls or transport objects in six files, fix that before you change providers. One function, one place to swap.
2. Add the new DKIM records and keep the old ones. Both providers stay authenticated while you run in parallel. Removing the old records early breaks mail still in flight.
3. Update SPF to include both, temporarily. Watch the include limit: SPF resolution is capped at ten DNS lookups and adding a second provider is a common way to blow past it. Check yours with the SPF lookup checker.
4. Export the suppression list and import it. Addresses that hard bounced elsewhere will hard bounce here, and each one damages the reputation of the new sending setup. See bounces, complaints, and suppression lists.
5. Reconnect webhooks before the first real send. Payload shapes differ between providers, so this is real work and it is not optional.
6. Ramp, do not switch. Move one message type at a time, watch the delivery events, then move the next. The warmup calculator will give you a schedule if you send enough for it to matter.

The send call, side by side#

import sgMail from '@sendgrid/mail';

sgMail.setApiKey(process.env.SENDGRID_API_KEY!);

await sgMail.send({
  to: 'someone@example.com',
  from: 'hello@acme.com',
  subject: 'Your receipt',
  html: '<p>Thanks for your order.</p>'
});

import { Emailssh } from '@emails.sh/sdk';

const mail = new Emailssh(process.env.EMAILSSH_API_KEY!);

await mail.send({
  from: 'Acme <hello@acme.com>',
  to: ['someone@example.com'],
  subject: 'Your receipt',
  html: '<p>Thanks for your order.</p>',
  text: 'Thanks for your order.'
});

Or without an SDK at all, which is the version to paste into a language that does not have one.

curl -X POST https://emails.sh/v1/emails \
  -H "Authorization: Bearer $EMAILSSH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Acme <hello@acme.com>",
    "to": ["someone@example.com"],
    "subject": "Your receipt",
    "html": "<p>Thanks for your order.</p>",
    "text": "Thanks for your order."
  }'

If you run this for clients#

Agencies feel a free tier change hardest, because it happens across every client project at once and each one has its own account, its own domain, and its own DNS access. Consolidating onto one workspace with per-client sending domains and per-client API keys turns a dozen migrations into one. That case is set out on the agencies page.

Questions#

Is the SendGrid free tier gone?

Check your own billing page rather than an article. Free allowances in this category change regularly and differ by account age and region. What is reliably true is that free transactional tiers have shrunk industry-wide and are no longer the automatic answer for a new project.

What is the cheapest way to send transactional email?

Amazon SES, by a wide margin at volume, if you are willing to build logs, templates, suppression handling, and bounce processing yourself. If you count your own time, an API-first provider is usually cheaper below a few hundred thousand messages a month.

Will migrating hurt my deliverability?

Only if you switch everything at once. Reputation is attached to the sending infrastructure as well as your domain, so a sudden move of all volume to a new source looks anomalous. Ramp over a week or two and keep both providers authenticated during the overlap.

Can I send a newsletter from a transactional provider's free tier?

No. Transactional providers separate the two deliberately, and bulk campaigns on a transactional plan lead to an account review or a suspension. Use a marketing platform for campaigns and keep the transactional stream clean.