Twilio SendGrid Email API

How an application sends mail: a REST API and an SMTP relay with their limits stated, official SDKs and drivers for named languages and frameworks (PHP and Laravel, Node, Python, Ruby and Rails, Java, Go, .NET), stored templates with variables and versions, batch sending, attachments, idempotency keys, scheduled sending, a test or sandbox mode that does not deliver, inbound email parsed into a webhook, and the quality of the API reference and guides.

0 — Not a sending service; an application cannot send email through it by API or SMTP.

3 — An API or SMTP credentials to send a message; SDKs, templates, limits and a test mode are basic or not described.

5 — A documented REST API and SMTP relay, official SDKs for several named languages, stored templates with variables, attachments and batch sending, rate limits stated, a sandbox or test mode, and quick-start guides for named frameworks.

8 — An API reference with every endpoint and error code, idempotency keys, scheduled sending, template versions and a template language documented, inbound email parsed to a webhook, an OpenAPI specification or official CLI, framework drivers maintained by the vendor, and a migration guide from named competitors.

10 — An API a team builds its product on: versioning and deprecation policy published, backward compatibility stated, full parity between API and SMTP features, local or staging test tooling that mirrors production, and every limit, timeout and retry behaviour documented.

What the vendor does so the mail reaches the inbox: guided SPF, DKIM and DMARC set-up with a custom return path and tracking domain, shared IP pools and how senders on them are vetted and policed, dedicated IPs with automatic warm-up, transactional and bulk mail kept on separate streams or IP pools, bounces, complaints and unsubscribes turned into suppressions automatically, feedback loops with mailbox providers, blocklist and DMARC monitoring, compliance with the Gmail and Yahoo bulk-sender rules, and published delivery times or inbox placement with their method.

0 — No sender authentication and no bounce handling; mail goes out from shared addresses with no reputation management at all.

3 — SPF and DKIM can be set up and bounces are recorded; IP policy, stream separation and suppressions are basic or not described.

5 — Guided SPF, DKIM and DMARC set-up with a custom return path, shared IPs with a stated sender vetting policy, dedicated IPs available, automatic suppression of hard bounces and complaints, transactional and marketing mail separated by stream or IP pool, and deliverability guidance in the documentation.

8 — Dedicated IPs with automatic warm-up and pool management, a stated acceptable-use and vetting process for shared pools, feedback loops and blocklist monitoring, DMARC reports, BIMI or custom tracking domains, compliance with the Gmail and Yahoo sender requirements stated, delivery times published, and access to deliverability experts.

10 — Deliverability that can be verified: delivery time and bounce rates per mailbox provider published continuously with their method, inbox placement testing included, pool reputation shown to the customer, and a documented escalation path with mailbox providers.

What the team can see about each message once the application has handed it over: a message log searchable by recipient, subject, tag or message ID, the full event history (processed, delivered, deferred, bounced with the remote server's answer, opened, clicked, complained), how long logs and message content are kept, event webhooks with retries and a signature, an events API, dashboards and statistics per stream, tag or domain, alerts on bounce or complaint spikes, and access for a support team without developer rights.

0 — Nothing can be seen after sending; no logs, no events and no webhooks.

3 — Totals of sent and bounced messages; per-message logs, webhooks and retention are basic or not described.

5 — A searchable message log with per-message event history and the bounce reason, log retention stated, event webhooks for delivery, bounce, open, click and complaint, statistics per tag or domain, and an API to fetch events.

8 — Webhooks signed and retried with their schedule documented, the raw SMTP response and the rendered message viewable per send, log retention configurable or extended by plan, alerts on bounce, complaint or delivery-time thresholds, export or streaming of events to a named log or data tool, and read-only roles for support staff.

10 — Full traceability: every message traceable from API call to the receiving server's final answer, events streamed in real time with ordering and delivery guarantees stated, long retention with search across the whole history, and observability features documented with their limits.

What is stored about each message and what the customer controls: whether message bodies are stored or only metadata, retention periods and the setting to shorten them, deletion of a recipient's data on request, open and click tracking that can be switched off per stream or message, TLS for delivery with an option to require it, encryption at rest, API keys with scopes and per-domain restrictions, IP allow-listing, two-factor authentication and SSO for the dashboard, an audit log, a vulnerability disclosure programme, and security certifications or audits with their scope. Where the data is processed and by whom is scored under sovereignty.

0 — Stores every message indefinitely with no controls, and the vendor states it uses message content for its own purposes.

3 — A privacy policy and a statement that data is encrypted; what is stored, retention and access controls are basic or not described.

5 — What is stored per message documented, retention periods stated, open and click tracking switchable, TLS used for delivery, API keys with restricted permissions, two-factor authentication for the dashboard, and a data processing agreement offered.

8 — Message content retention configurable down to none or metadata only, enforced TLS per domain or message, encryption at rest stated, scoped API keys and IP allow-listing, SSO (SAML) and roles, an audit log, deletion of recipient data by API, and ISO 27001 or SOC 2 stated with its scope.

10 — Data minimisation that can be verified: every stored field and its retention listed, content never stored unless the customer opts in, customer-managed encryption keys or equivalent, independent audits published with their scope, and every security control the customer has listed with its effect.

Whether the platform can be relied on and run by a team: a public status page with incident history, uptime SLA and service credits published, redundancy or failover across data centres described, queueing and retry of mail during outages, sub-accounts or servers per application, client or tenant, team members with roles, separate environments, support channels and response times per plan, named migration help, and integrations with platforms that send mail on the customer's behalf (WordPress, Shopify, Shopware, Supabase, Vercel and similar).

0 — No status page, no support channel and no way to separate users or applications.

3 — A support contact and a single account; status page, SLA, sub-accounts and roles are basic or not described.

5 — A public status page with incident history, an uptime SLA on at least one plan, sub-accounts or separate servers per application, team members with roles, support by email or chat with stated hours, and plugins or guides for several named platforms.

8 — An SLA with service credits published, redundancy across data centres or regions described, mail queued and retried during incidents, sub-accounts with their own keys, domains and limits manageable by API, granular roles, support response times per plan, and migration assistance offered.

10 — Reliability that can be verified: uptime history published for years, post-mortems for incidents, multi-region failover documented, an SLA covering delivery latency as well as API availability, and white-label or reseller tooling for agencies and platforms.

Who the contracting entity and the parent company are, where messages, logs and recipient data are processed and stored, whether an EU region can be chosen and what it covers, and who the subprocessors are (cloud hosting, sending infrastructure, logging, support and payment tools). Independently sourced by the sovereignty pipeline; every message carries personal data, so the whole sending chain counts, not only the dashboard.

0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and no data processing agreement offered.

3 — A privacy policy and a data processing agreement exist, but hosting location is unstated or non-EU and the subprocessors are not listed.

5 — An EU region available and an EU contracting entity or EU representative, but parts of the chain (sending infrastructure, logs, support, payment) run through non-EU providers without a stated safeguard, or the EU region does not cover logs and account data.

8 — EU processing of messages, logs and account data on named infrastructure, an EU contracting entity, subprocessors listed with their locations, a data processing agreement published, and security certifications (ISO 27001, SOC 2) stated.

10 — Sovereign end to end and evidenced: European ownership, entity, hosting, sending infrastructure and every subprocessor, data export and deletion documented, and certifications published with their scope rather than implied.

Whether a buyer can compute the real annual cost from public pages alone: price per tier by monthly message volume, the price per additional thousand messages, the free tier and its limits, what dedicated IPs, extra log retention, sub-accounts, SSO and support plans cost, minimum term, and whether unused volume carries over.

0 — No public prices at all; every customer is a sales call.

3 — A starting price or a free tier exists, but how cost scales with volume or which features cost extra is unclear.

5 — Tiers are public with their monthly volume and price, but at least one commonly needed piece (overage rate, dedicated IP, longer log retention, SSO, support plan) is unpriced or "on request".

8 — Every tier priced publicly with its volume and overage rate per thousand messages, dedicated IPs and add-ons priced, log retention per tier stated, minimum term and VAT treatment stated.

10 — Complete price computability: annual cost derivable for a given monthly volume, number of domains and sub-accounts and feature set, with every add-on, support and overage fee and the cancellation terms published.