SMTP of e-mail-API: wat moet je app gebruiken?

Vroeg of laat moet elk product e-mail versturen, en de eerste vraag is hoe je code met het mailsysteem praat. Er zijn twee antwoorden: rechtstreeks SMTP spreken, of een e-mail-API aanroepen via HTTPS.

Beide werken. Ze stellen alleen heel verschillende eisen aan je applicatie, en de juiste keuze hangt af van waar je code draait en hoeveel van de mailinfrastructuur je zelf wilt beheren.

Waar SMTP goed in is

SMTP (Simple Mail Transfer Protocol) is sinds het begin van de jaren tachtig de manier waarop mailservers e-mail uitwisselen. Elke mailboxprovider ondersteunt het, en bijna elk framework heeft een ingebouwde SMTP-mailer: Nodemailer, send_mail van Django, Laravel Mail, Action Mailer van Rails.

Sterke punten:

• Universeel. Elk e-mailaccount en elke programmeertaal kan ermee overweg.
• Geen vendor lock-in. Wissel van provider door een hostnaam en een wachtwoord te wijzigen.
• Je eigen domein en reputatie. Mail gaat de deur uit via een server die je beheert of huurt, vanaf adressen op je domein.

Waar SMTP wringt in een app

SMTP is een spraakzaam protocol dat een sessie bijhoudt. Om één bericht te versturen, opent je app een TCP-verbinding, begroet de server, schakelt over op TLS, authenticeert zich en doorloopt daarna een reeks commando’s en antwoorden voor de afzender, de ontvanger en de data. Elke stap is een netwerk-roundtrip.

In de praktijk leidt dat tot:

• Trage verzoeken. Een handshake met een server ver weg kan honderden milliseconden duren voordat het bericht zelfs maar begint.
• Geblokkeerde poorten. Veel cloudplatforms en serverless runtimes beperken uitgaand verkeer op poort 25, 465 en 587 om spam tegen te gaan. HTTPS op poort 443 wordt bijna nooit geblokkeerd.
• Overal inloggegevens. Elke service die mail verstuurt, heeft het wachtwoord van de mailbox nodig. Dat wachtwoord wijzigen betekent ze allemaal opnieuw deployen.
• Weinig inzicht. Als er iets misgaat, staat de fout in de logs van één service, als hij al gelogd is.

Wat een e-mail-API verandert

Een e-mail-API verpakt het versturen in één HTTPS-verzoek met een JSON-body. Je code doet één POST en krijgt een statuscode terug. De API-service beheert de SMTP-verbinding en de inloggegevens.

Sterke punten:

• Eén snel verzoek via poort 443, vanaf elke plek: containers, serverless functions, edge runtimes, CI-jobs.
• Sleutels in plaats van wachtwoorden. Elke service krijgt een eigen API-sleutel met beperkte rechten, en je kunt er één intrekken of roteren zonder de andere aan te raken.
• Centraal inzicht. API-aanroepen en bezorgresultaten worden op één plek bijgehouden.
• Gewone HTTP-fouten. Een 401 of 429 is veel makkelijker af te handelen dan een SMTP-antwoordcode die ergens in een stacktrace verstopt zit.

Keerzijde: bij de meeste e-mail-API’s gaat mail de deur uit via hun servers. Je neemt dus hun configuratie voor het verzenddomein en hun IP-reputatie over, en later overstappen betekent alles ergens anders opnieuw verifiëren.

Inbixio: een API vóór je SMTP-server

Inbixio is gebouwd rond een eenvoudig idee: behoud het waardevolle deel van SMTP, je eigen mailserver en afzenderidentiteit, en vervang het deel dat in applicaties wringt.

1. Je koppelt je SMTP-server één keer in het dashboard: host, poort, gebruikersnaam en wachtwoord.
2. Je services roepen POST /api/send-email/ aan met een Inbixio-API-sleutel.
3. Inbixio logt via TLS in op je SMTP-server en levert het bericht af vanaf jouw adres.
4. Je dashboard toont het aantal verzonden e-mails, het percentage mislukte bezorgingen en de bezorglatency, plus een log van elke API-aanroep.

curl -X POST https://backend.inbixio.com/api/send-email/ \
  -H "X-API-Key: $INBIXIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to_email":"user@example.com","subject":"Welcome!","message":"<h1>Hello</h1>"}'

Wat je daarmee krijgt:

• Je SMTP-wachtwoord staat op één plek. Je services zien alleen API-sleutels.
• Sleutels kunnen worden vastgezet op één specifieke server, zodat de factuurservice verstuurt vanaf billing@ en de authenticatieservice vanaf security@.
• De rechten van elke sleutel zijn expliciet, en een sleutel kan worden vernieuwd of verwijderd zonder de mailserver aan te raken.
• Je behoudt je afzenderdomein, je provider en je reputatie. Stap je over naar een andere mailprovider, dan pas je één serverinvoer aan en verandert er niets aan je code.

Naast elkaar

Wat moet je dan gebruiken?

• Gebruik rechtstreeks SMTP voor één kleine app op een server waar uitgaande SMTP is toegestaan en waar je er geen bezwaar tegen hebt om daar inloggegevens te beheren.
• Gebruik een e-mail-API als je meerdere services draait, deployt naar platforms die SMTP-poorten blokkeren, centrale logs wilt, of wilt ophouden met het rondsturen van mailboxwachtwoorden.
• Gebruik Inbixio als je die voordelen van een API wilt, maar mail ook via je eigen mailserver en domein wilt blijven versturen.

Klaar om het te proberen? Met de quickstart van vijf minuten ga je van aanmelding naar een afgeleverde e-mail.