Wat is het verschil, in één zin?
SMTP is het open protocol waarmee je software mail aan een server doorgeeft; een e-mail-API is een HTTPS-interface van een specifieke provider die hetzelfde werk doet, met gestructureerde payloads en feedback over events. Het protocol waarmee je aanlevert, bepaalt niet of je in de inbox belandt: authenticatie en domeinreputatie doen dat, en SPF, DKIM en DMARC gelden voor beide routes op dezelfde manier. Kies dus op basis van de integratie: overdraagbaarheid, foutafhandeling, tooling. Voor alles wat er gebeurt nadat je provider het bericht heeft geaccepteerd, is deliverability van e-mail voor start-ups de gids.
Hoe werkt versturen via SMTP?
Je applicatie opent een verbinding met de server van je provider, de SMTP-relay (voor aanlevering meestal poort 587 met authenticatie, zoals vastgelegd in RFC 6409), en geeft het kant-en-klare bericht door. Het transportprotocol zelf is RFC 5321, in zijn huidige vorm gestandaardiseerd in 2008 en al veel langer in gebruik, en daarom spreekt alles het: elk framework, elk CMS, elk forum, elke monitoringtool en elk tientallen jaren oud script kan zo versturen met niet meer dan een host, een poort en inloggegevens. Dat is het stille voordeel van SMTP: migreren is een kwestie van andere inloggegevens, dus van e-mailplatform wisselen betekent nooit dat je de verzendcode moet herschrijven. Het past ook vanzelf bij stacks die je zelf host, waar SMTP-ondersteuning standaard is ingebouwd.
Hoe werkt versturen via een e-mail-API?
Je code roept het HTTPS-endpoint van de provider aan met een JSON-payload: ontvanger, inhoud of een verwijzing naar een template, tags, metadata en vaak een idempotency key om dubbele verzendingen te voorkomen. Het antwoord is synchroon: succes met een bericht-ID, of een fout die je code kan opvangen en opnieuw kan proberen. De documentatie van Postmark maakt het contrast expliciet: de REST API geeft meteen succes of een fout terug, terwijl het SMTP-endpoint alle berichten accepteert en eventuele fouten als bounces registreert, die je nog steeds via de bounce-webhooks kunt ophalen. Na acceptatie sturen webhooks bounces, klachten en opens terug naar je app, en dat maakt automatische suppressie mogelijk. De SDK’s van providers verpakken dit allemaal in een paar regels; in ruil daarvoor is de integratie specifiek voor die provider.
SMTP vs. API: naast elkaar
De hele beslissing komt neer op één afweging: SMTP levert overdraagbaarheid op, de API feedback en tooling. Zo pakt dat regel voor regel uit.
| SMTP | E-mail-API | |
|---|---|---|
| Wat het is | Open protocol (RFC 5321), overal hetzelfde | Productinterface van een specifieke provider, via HTTPS |
| Integratiewerk | Bijna nul als de software al SMTP spreekt: host, poort, inloggegevens | Code schrijven voor het endpoint of de SDK van de provider |
| Overdraagbaarheid | Hoog: van provider wisselen is een kwestie van andere inloggegevens | Laag: elke provider heeft een eigen formaat; wisselen betekent de integratie herschrijven |
| Foutafhandeling | Geaccepteerd bij aanlevering; sommige fouten duiken later op als asynchrone bounces | Synchrone fouten die je kunt opvangen en opnieuw kunt proberen, plus asynchrone events |
| Feedback over events | Niets in het protocol: de bounce-webhooks van de provider dekken ook mail die via SMTP is aangeleverd, maar die koppel je apart | Webhooks sturen bounces, klachten en opens naar je app |
| Templates en analyse | Niets in het protocol: je verstuurt een kant-en-klaar bericht | Verwijzingen naar templates, tags en metadata per bericht |
| Geschikt om zelf te hosten | Vanzelfsprekend: software die je zelf host, spreekt standaard SMTP | Nog een leveranciersspecifieke afhankelijkheid in je stack |
Wanneer is SMTP de juiste keuze?
- Software die het al spreekt: een CMS, forum, helpdesk of oudere app verstuurt via je provider met niets meer dan nieuwe inloggegevens.
- Maximale overdraagbaarheid: wil je van provider kunnen wisselen zonder code aan te raken, dan is SMTP de neutrale interface.
- Stacks die je zelf host: SMTP-ondersteuning zit ingebouwd in vrijwel alles wat je op je eigen infrastructuur zou draaien, zonder SDK.
- Operationele mail met een laag volume: cronmeldingen en interne notificaties rechtvaardigen zelden een eigen API-integratie.
Wanneer is de API de juiste keuze?
Productmail op schaal. Als e-mail in je applicatie is ingebouwd (onboarding, betaalbewijzen, lifecycleflows), verdienen synchrone fouten, verwijzingen naar templates en webhooks voor events hun integratiekosten terug, en kan een suppressielijst zichzelf bijwerken zodra een adres bouncet of een klacht oplevert. Wat de API je niet oplevert, is reputatie: die zit op je verzenddomein, niet op je aanleverroute, dus een domein opwarmen en authenticatie gelden op dezelfde manier, hoe je ook aanlevert.
Waarom ondersteunt fromHello allebei?
Omdat de keuze een integratiebeslissing is en geen kwestie van deliverability, heeft fromHello adapters voor allebei: HTTP-API’s (Resend, Postmark, SendGrid), elke SMTP-server en mailboxen in Microsoft 365. Je stelt per werkruimte een standaard in en kunt een template aan een eigen provider koppelen. In fromHello Cloud, in early access, komen de abonnementen vanaf Team met ingerichte e-mailverzending; op Core of als je zelf host, breng je de provider zelf mee. Limieten liggen in beide gevallen bij de provider: Resend bijvoorbeeld documenteert dezelfde rate limit voor zijn SMTP-endpoint als voor zijn API. En suppressie en toestemming worden door het platform afgedwongen, ongeacht de aanleverroute: een onderdrukt adres blijft onderdrukt, of het bericht nu via HTTPS of via poort 587 vertrekt.