European SendGrid alternative

Residency as a configuration versus residency as an architecture

This is the whole comparison, so it’s worth being precise rather than rhetorical. Twilio’s Data Residency for Email stores recipient PII, message content and event data in EU data centres, and the core functionality is included in its standard plans. To use it you create an EU-assigned subuser, send against api.eu.sendgrid.com instead of the default host, and have a dedicated EU IP — included by default on Pro, Premier and Custom accounts, procured separately otherwise. Get the routing wrong on one service, one cron job, one forgotten staging environment, and that traffic takes the global path instead, with nothing in your code looking obviously broken.

eusend has one endpoint and one set of data centres. There is no non-EU path to accidentally send down, no subuser to misconfigure, and no plan on which residency turns off — the free tier and the largest paid tier run on identical infrastructure. The guarantee is structural rather than contractual, which mostly means there is less of it to audit.

The part a region setting cannot reach

Twilio is a US company. Under the US CLOUD Act, a US-incorporated provider can be compelled to produce data it controls regardless of which country the disk is in — that is the specific reason “our data is in Frankfurt” and “our processor is outside the reach of US process” are different sentences.

How much that matters depends entirely on what you send. For marketing blasts to an opted-in list, probably not much. For password resets, medical appointment reminders, or anything where the recipient list is itself the sensitive fact, European teams increasingly decide the cleanest answer is a processor that no US court has jurisdiction over. eusend is a Norwegian company — inside the EEA, under the GDPR, with no US parent in the chain.

Transactional only, which changes the neighbourhood

SendGrid is two products sharing a reputation: a transactional API and a marketing campaigns platform. Like SendGrid, most eusend mail leaves through a shared pool of warmed IPs — that is what gives a new account decent deliverability on day one — so the honest difference isn’t shared versus dedicated. It’s who else is in the pool, and how fast a bad sender is removed from it.

• Thresholds that act on their own. A sustained bounce rate above 4% or complaint rate above 0.08% over a rolling seven-day window suspends sending automatically — no ticket, no human in the loop, the same at 3am as at noon.
• Untrusted traffic is separated at the egress. New and free-tier accounts send through isolated addresses rather than the warmed shared pool, so a sender who hasn’t earned trust can’t spend reputation that isn’t theirs.
• DKIM before anything leaves. A domain cannot send until it is verified, which removes the single largest category of reputation damage before it happens.

The deliverability page sets out the rest in engineering terms. We run our own MTA rather than reselling someone else’s sending service, so when delivery goes wrong the SMTP conversation with the receiving server is something we can read, not something we open a support ticket about.

What the migration actually looks like

Of the major providers, SendGrid is the closest to a find-and-replace: the send call already uses from, to, subject and html as top-level fields. The client becomes an instance instead of a global singleton, and errors come back as { data, error } rather than thrown.

The one structural change worth seeing up front is multi-recipient sending — personalizations becomes a batch of fully-formed messages, up to 100 per request:

// SendGrid: one request, personalizations array
await sgMail.send({
  from: 'Acme <hello@acme.com>',
  personalizations: [
    { to: 'a@example.com', dynamicTemplateData: { name: 'Ada' } },
    { to: 'b@example.com', dynamicTemplateData: { name: 'Blaise' } },
  ],
  templateId: 'd-xxxxxxxx',
})

// eusend: one request, one fully-formed message per recipient
await eusend.batch.send([
  { from: 'Acme <hello@acme.com>', to: 'a@example.com', subject: 'Hi Ada', html: adaHtml },
  { from: 'Acme <hello@acme.com>', to: 'b@example.com', subject: 'Hi Blaise', html: blaiseHtml },
])

• SMTP is a host swap. SendGrid’s literal username plus API-key-as-password pattern carries over — point at smtp.eusend.dev, change the username from apikey to eusend, and use port 465 with implicit TLS.
• Webhook events map one to one. processed, delivered, bounce, spamreport, open and click all have direct equivalents. Signing moves from SendGrid’s ECDSA scheme to HMAC-SHA256.
• Marketing Campaigns doesn’t come with you yet. Transactional sending is open today and opt-in broadcasts are live, but if you run serious campaign volume on SendGrid, plan that half separately.

The field-by-field version, including the trackingSettings and attachment mappings, is in the SendGrid migration guide.

What will take longer than the code

• DNS and reputation are per-domain. You publish a new DKIM record and adjust SPF, and a new sending path starts with a conservative daily ceiling that lifts as you send cleanly. At SendGrid volumes, move traffic over gradually — the warm-up guide has the schedule.
• Export your suppression list first. We suppress hard bounces and complaints automatically from your first send, but we cannot see SendGrid’s history. Import the CSV before you switch, or re-learn every bad address on a fresh IP.

Common questions