term · Amazon SES

Wat is Amazon SES en wat betekent het voor applicatiemail?

Amazon Simple Email Service, of Amazon SES, is AWS-infrastructuur voor het verzenden van e-mail via een API- of SMTP-interface en voor het ontvangen van e-mail. Voor een applicatieteam betekent kiezen voor SES dat je verantwoordelijk bent voor meer dan alleen de verzendaanroep: geverifieerde identiteiten, regionale configuratie, IAM-machtigingen, quotumafhandeling, berichtopbouw, eventinname, reactie op bounces en klachten, suppressie en operationele monitoring. SES-acceptatie betekent dat AWS bezorging zal proberen; het bewijst geen inboxplaatsing. Behandel SES als een transport- en feedbacklaag binnen een groter applicatie-e-mailsysteem.

Begrijp waar de dienst ophoudt

SES accepteert applicatie-e-mail via AWS-API's of een SMTP-endpoint en kan een MIME-bericht samenstellen uit gestructureerde velden of een door de afzender samengesteld bericht accepteren. Daarmee is het infrastructuur, geen complete productworkflow. Je applicatie bepaalt nog steeds wie mag verzenden, welke tenant een domein bezit, hoe templates en ontvangergegevens worden verwerkt, wanneer retries veilig zijn en wat gebruikers zien nadat een request slaagt. Een bruikbare architectuur scheidt drie statussen: de applicatie accepteerde een taak, SES accepteerde een bericht en een ontvangende mailserver accepteerde of weigerde het bericht. Deze statussen treden op verschillende momenten op en vereisen verschillende identifiers. Sla je eigen onveranderlijke taak-ID naast de SES-berichtidentifier op, zodat webhookretries en supportonderzoeken kunnen worden afgestemd zonder te gokken op onderwerpregels of ontvangergegevens.

Verifieer identiteiten voordat je verzendt

AWS definieert een geverifieerde identiteit als een domein of e-mailadres dat met SES wordt gebruikt. Voordat je verzendt, moet de identiteit in From, Source, Sender of Return-Path voldoen aan de verificatieregels van SES. Domeinverificatie is voor een applicatie meestal de duurzame keuze, omdat die adressen onder dat domein kan autoriseren en authenticatie op domeinniveau ondersteunt. Verificatie is geen eenmalig vinkje dat je naar elke deployment kunt kopiëren. De identiteitsstatus en de configuratie van Easy DKIM zijn regionaal, dus een domein dat in de ene AWS-regio is geverifieerd, is niet automatisch klaar in een andere. Bouw onboarding als een state machine: vraag de identiteit aan, toon de exacte DNS-records, poll de status bij de gezaghebbende provider en sta verzending in productie pas toe als de gekozen regio succes meldt. Laat bestaand SPF- en DMARC-beleid intact als de DNS wordt gedeeld met een andere afzender, en maak nooit voor het gemak een tweede SPF-record aan.

Maak de regio onderdeel van je e-mailconfiguratie

SES-resources en operationele limieten zijn regionaal. Geverifieerde identiteiten, sandboxstatus, dagquotum, maximale verzendsnelheid, Easy DKIM-configuratie, suppressie-instellingen en feedbackbestemmingen kunnen per regio verschillen. Een credential die geldig is in AWS maakt een identiteit niet overdraagbaar naar een ander SES-endpoint. Zet de regio in de configuratie naast het provideraccount en de identiteit, in plaats van hem te verstoppen in een algemene standaardwaarde van de omgeving. Bereid voor failover de secundaire regio voor vóór er een incident is: verifieer de identiteit, publiceer de DKIM-records, regel productietoegang en passende quota, configureer eventbestemmingen, test bericht-ID's en webhookverwerking, en zorg dat je begrijpt hoe suppressie werkt. Als je tijdens een storing alleen het endpoint omzet, kan het ene incident anders plaatsmaken voor verificatiefouten, throttling of ontbrekende feedback.

Kies bewust voor API of SMTP

AWS ondersteunt verzending in productie via de SES-API en de SMTP-interface. De API past bij applicaties die al AWS-authenticatie en SDK's gebruiken, en biedt bewerkingen voor zowel gestructureerde als ruwe berichten. SMTP past bij software die al SMTP spreekt, maar SMTP-credentials van SES zijn iets anders dan gewone AWS-toegangssleutels en blijven regionaal. De keuze neemt de noodzaak van wachtrijen, idempotentie, timeoutafhandeling en veilige retryregels niet weg. Als een verbinding wegvalt voordat je applicatie een respons ontvangt, kan de provider het bericht toch hebben geaccepteerd. Probeer een request van een gebruiker niet blind opnieuw met een nieuwe applicatie-identifier. Zet de job één keer in de wachtrij, bewaar de respons van de provider als die beschikbaar is en laat workers een stabiele job opnieuw proberen. Gebruik een bewerking voor ruwe berichten alleen als je exacte controle over MIME nodig hebt, en valideer headers en regellengtes voordat je het bericht aan SES overdraagt.

Behandel sandbox en quota als runtimebeperkingen

Nieuwe SES-account-regiocombinaties kunnen zich in de sandbox bevinden. AWS documenteert momenteel sandboxlimieten van 200 ontvangerbezorgingen per 24 uur en één e-mail per seconde, met verzending beperkt tot geverifieerde ontvangers behalve voor de mailboxsimulator. Productiequota verschillen per account, regio en goedgekeurde use case. Quota tellen ontvangers in plaats van API-requests, dus één request aan tien ontvangers verbruikt tien eenheden. Lees het werkelijke quotum voor elke actieve regio en ontwerp backpressure rond zowel het voortschrijdende dagelijkse tegoed als de verzendsnelheid. Een providerthrottle moet een taak in de wachtrij vertragen, geen dubbele verzendingen maken of verschijnen als een onverklaard succes. Vraag vóór de lancering productie-toegang en realistische limieten aan en voer vervolgens een loadtest uit met gecontroleerde ontvangers. Beschrijf de sandbox niet als gratis niveau en neem niet aan dat goedkeuring in één regio voor een andere geldt.

Bouw de bezorgstatus op uit events

Een geslaagde verzendbewerking in SES betekent dat het request is geaccepteerd en dat SES een bezorgpoging zal doen. Het betekent niet dat de ontvanger het bericht heeft geopend, het in de inbox heeft gezien of zelfs dat de ontvangende server het heeft geaccepteerd. Via event publishing kan SES sends, deliveries, bounces, complaints, rejections, rendering failures, delays, subscriptions, opens en clicks rapporteren naar geconfigureerde AWS-bestemmingen. Het operationeel belangrijke onderscheid is dat een delivery-event staat voor acceptatie door de mailserver van de ontvanger, terwijl bounce- en complaint-events een reactie volgens je beleid vereisen. Verwerk events idempotent, want bezorgsystemen kunnen notificaties opnieuw versturen. Bewaar de berichtidentifier van de provider en het tijdstip van het event, weiger misvormde webhookpayloads en maak statusovergangen waar mogelijk monotoon. Opens en clicks zijn optionele engagementsignalen met beperkingen op het gebied van privacy en clients; ze mogen niet opnieuw bepalen of de bezorging op transportniveau heeft plaatsgevonden.

Bounces, klachten en suppressie afhandelen

Door bekende slechte of onwillige ontvangers op de suppressielijst te zetten, bescherm je zowel gebruikers als het verzendaccount. AWS biedt suppressie op globaal niveau, accountniveau, configuratiesetniveau en sinds kort ook op tenantniveau, maar de exacte scope hangt af van configuratie en regio. Je applicatie heeft nog steeds een duidelijk ontvangersbeleid nodig. Adressen met een permanente bounce mogen geen routinematige retries meer krijgen, klachten moeten direct tot suppressie leiden, en voor verwijdering van de suppressielijst moet bewijs zijn dat het adres geldig is en de ontvanger de mail verwacht. Bepaal in een multi-tenantproduct vóór het onboarden van klanten of suppressie voor het hele account geldt of per tenant geïsoleerd is, want bij gedeelde suppressie kan de uitkomst van de ene tenant de verzending van een andere beïnvloeden. Houd ruwe adressen uit algemene analytics en logs. Operationele systemen hebben het adres mogelijk nodig om suppressie af te dwingen, maar dashboards en experimenten moeten geaggregeerde of gepseudonimiseerde metingen gebruiken.

Pas least privilege toe en isoleer tenants

IAM-policy's kunnen beperken welke SES-bewerkingen een principal mag aanroepen, en kunnen voor verzendacties From-, ontvanger- of Return-Path-adressen inperken. Sending authorization policies lossen een ander probleem op: daarmee kan een identiteitseigenaar het gebruik van een geverifieerde identiteit delegeren en dat los intrekken. Kies voor één applicatie een principal met alleen de verzend- en monitoringacties die de workload echt nodig heeft. Geef een webbrowser nooit AWS-credentials. Een multi-tenant e-mailproduct heeft ook autorisatie op applicatieniveau nodig, omdat één gedeeld SES-account je workspacemodel niet vanzelf begrijpt. Controleer of de geauthenticeerde tenant eigenaar is van een geverifieerd From-domein voordat je naar SES verstuurt, beperk API-sleutels en berichtrecords tot die tenant, en zorg dat identifiers van andere tenants geen data teruggeven. IAM bij de provider en autorisatie in de applicatie zijn complementaire controles, geen vervangers van elkaar.

Gebruik een checklist voor productiegereedheid

Leg vóór de lancering het AWS-account, de regio, de identity-ARN, de verificatiestatus, de DKIM-status, de sandboxstatus, het dagquotum, de maximale verzendsnelheid, de eventbestemming, de scope van suppressie en de eigenaar van de credentials vast. Test een normale bezorging, een bounce via de mailboxsimulator, een klachttest waar dat wordt ondersteund, een throttle-respons, een event-retry en een providertimeout na verzending. Controleer dat queueworkers een stabiele job niet dupliceren, dat een delivery-event het juiste bericht bijwerkt en dat een permanente bounce een volgende routinematige verzending voorkomt. Stel alarmen in voor geweigerde requests, throttling, fouten bij het verwerken van events, veranderingen in bounces en klachten, en resterende quotumruimte. Bekijk de configuratie opnieuw zodra er een nieuwe regio, een nieuw domein, tenanttype of berichtklasse bijkomt. Met deze checklist wordt SES van een verborgen afhankelijkheid een expliciet subsysteem met eigenaren en zichtbare faalscenario's.

Bepaal waar SendHQ past

Teams kunnen SES direct integreren als ze AWS-native controle willen en bereid zijn de applicatielaag eromheen zelf te bouwen. SendHQ biedt een smaller e-mailcontract per workspace, met geverifieerde verzenddomeinen, API-sleutels met beperkte scope, enkele en batchverzendingen, inboxen voor inkomende e-mail, toegang tot bezorgevents en suppressieworkflows. De openbare API vereist dat het From-domein bij de workspace hoort en geverifieerd is, en legt geaccepteerde berichten vast zodat je ze later kunt inspecteren. Die productlaag vervangt niet de regels van SES voor identiteit, quota en reputatie, of de filtering aan de kant van de ontvanger. Beoordeel de twee lagen afzonderlijk: de provider transporteert mail en rapporteert erover, terwijl de applicatielaag het eigenaarschap van tenants afdwingt, stabiele resources beschikbaar stelt en de operationele status toont. Noch SES direct noch SendHQ garandeert inboxplaatsing, dus beoordeel beide op controles, observability, eigenaarschap en hoe goed ze passen bij de workflow van je applicatie.

Veelgestelde vragen

Is Amazon SES een e-mail-API of een SMTP-server?

Het biedt zowel een HTTPS-API als een SMTP-interface. Kies op basis van de behoeften van je applicatie op het gebied van authenticatie en het samenstellen van berichten, en houd wachtrijen, stabiele job-ID's, eventverwerking en suppressie buiten de transportcall.

Moet ik een domein verifiëren om Amazon SES te gebruiken?

Je moet elke identiteit verifiëren die je gebruikt als From-, Source-, Sender- of Return-Path-adres. Een identiteit op basis van een e-mailadres kan in beperkte gevallen werken, maar domeinverificatie is over het algemeen praktischer voor adressen die de applicatie beheert en voor DKIM.

Betekent een succesrespons van SES dat de e-mail is afgeleverd?

Nee. Het betekent dat SES het request heeft geaccepteerd en een bezorgpoging zal doen. Een later delivery-event betekent dat de mailserver van de ontvanger het bericht heeft geaccepteerd, en geen van beide statussen bewijst dat het bericht in de inbox is beland.

Worden de quota van Amazon SES gedeeld tussen regio's?

Nee. Volgens de documentatie van AWS zijn verzendquota, sandboxstatus, geverifieerde identiteiten, DKIM-configuratie en suppressie-instellingen regionaal. Bereid elke regio die productieverkeer kan krijgen voor en test die, in plaats van tijdens een incident van endpoint te wisselen.

Wat moet een applicatie opslaan na verzending via SES?

Sla een stabiel job-ID van de applicatie op, de berichtidentifier van SES zodra het bericht is geaccepteerd, de provider en regio, de huidige status, tijdstempels en genormaliseerde bezorgevents. Houd berichtinhoud en ontvangergegevens uit brede logs en analytics.

Wanneer kan een team beter SendHQ gebruiken dan SES direct?

Gebruik SES direct als het team zelf eigenaar wil zijn van de AWS-integratie en alle controles eromheen. Overweeg SendHQ wanneer API-sleutels per workspace, controles op domeineigendom, inboxen voor inkomende e-mail, berichtresources, bezorgevents en suppressieworkflows nuttige bouwstenen zijn voor je applicatie.

Bronnen

Verder leren

Kosten van Amazon SES: een prijsmodel voor productteamsBreng de kosten van Amazon SES in kaart over ontvangers, data, prijsabonnementen, dedicated IP's, event-infrastructuur, quota en de engineeringlaag rond bezorging.