Bounce vs. klacht: wat je deliverability echt schaadt

Het wezenlijke verschil

Bounces zijn technische fouten waarbij de ontvangende server de e-mail weigert. Klachten zijn acties van gebruikers waarbij de ontvanger je e-mail als spam markeert. Een hoog bouncepercentage wijst op slechte lijsthygiëne, klachten wijzen op een gebrek aan toestemming of relevantie. Klachten schaden je reputatie veel meer, omdat ze ISP's direct laten weten dat je content ongewenst is. Dat leidt sneller tot blacklisting en lagere bezorgpercentages over je hele IP-range.

Bounces begrijpen

Een bounce treedt op wanneer een e-mail niet in de mailbox van de ontvanger kan worden afgeleverd. Vanuit engineeringperspectief is dat een mislukte bezorgpoging. Bounces worden in twee soorten verdeeld: hard en soft.

Hard bounces

Een hard bounce is een permanente fout. Het e-mailadres bestaat niet, het domein is ongeldig of de ontvangende server heeft je IP permanent geblokkeerd. Je moet direct stoppen met verzenden naar deze adressen. Blijf je versturen naar adressen met een hard bounce, dan is dat voor ISP's een belangrijk signaal dat je een oude of gekochte lijst gebruikt, een kenmerk van ongevraagde bulkmail.

Veelvoorkomende SMTP-foutcodes voor hard bounces zijn:

• 550: Gebruiker onbekend
• 554: Transactie mislukt
• 550 5.1.1: Ongeldig bestemmingsmailboxadres

Soft bounces

Een soft bounce is een tijdelijke fout. De mailbox kan vol zijn, de server kan tijdelijk onbereikbaar zijn of het bericht is groter dan toegestaan. Dat zijn geen redenen om een contact meteen te verwijderen, maar herhaalde soft bounces moet je uiteindelijk als hard bounces behandelen.

Veelvoorkomende SMTP-foutcodes voor soft bounces zijn:

• 421: Service niet beschikbaar, transmissiekanaal wordt gesloten
• 450: Gevraagde mailactie niet uitgevoerd: mailbox niet beschikbaar
• 451: Gevraagde actie afgebroken: lokale verwerkingsfout

Klachten begrijpen

Een klacht ontstaat wanneer een gebruiker in zijn e-mailclient op "Spam melden" of "Markeren als ongewenst" klikt. Anders dan bij een bounce is de e-mail wel succesvol in de mailbox afgeleverd. Het probleem is hier niet technisch, maar gedragsmatig.

ISP's (internetproviders) zoals Gmail en Outlook houden de verhouding tussen klachten en het totale volume bij. Komt je klachtpercentage boven een zeer lage drempel (vaak al 0,1 procent), dan daalt je reputatie. Dat raakt niet alleen de campagne die je op dat moment verstuurt, maar elke e-mail die vanaf dat IP of domein wordt verzonden.

De deliverability-hiërarchie

Het is essentieel om drie verschillende begrippen uit elkaar te houden: acceptatie door de provider, bezorging en inboxplaatsing.

1. Acceptatie door de provider: de ontvangende server accepteert de verbinding en het bericht. Mislukt dit, dan heb je een bounce.
2. Bezorging: het bericht is succesvol in de mailopslag van de ontvanger geplaatst.
3. Inboxplaatsing: het bericht komt in de inbox terecht in plaats van in de spammap. Klachten hebben direct invloed op deze fase.

Heb je een hoog klachtpercentage, dan kunnen je e-mails nog steeds "afgeleverd" worden (geaccepteerd door de server), maar ze gaan bij alle gebruikers rechtstreeks naar de spammap, ongeacht of die specifieke gebruikers hebben geklaagd.

De reactie inrichten

Als engineer die verantwoordelijk is voor de incidentqueue kun je niet vertrouwen op handmatig opruimen. Je hebt een geautomatiseerde pipeline nodig om bezorgevents te verwerken.

De suppressielijst

Elke professionele verzendopzet heeft een suppressielijst nodig. Dat is een database met adressen die nooit meer gemaild mogen worden. Ontvang je via een webhook een bounce- of complaint-event, dan moet je systeem dat adres direct op de suppressielijst zetten.

Gebruik je SendHQ, dan worden deze suppressies op API-niveau afgehandeld. Zelfs als je applicatielogica probeert te versturen naar een adres op de suppressielijst, blokkeert het systeem dat voordat het bericht de deur uit gaat.

Webhooks afhandelen

Je webhookhandler ziet er ongeveer zo uit (conceptueel Node.js-voorbeeld):

app.post('/webhooks/email', async (req, res) => { const event = req.body; switch (event.type) { case 'bounce': if (event.detail.category === 'permanent') { await suppressionService.add(event.detail.email, 'hard_bounce'); } break; case 'complaint': await suppressionService.add(event.detail.email, 'spam_complaint'); break; case 'delivered': await trackingService.markAsDelivered(event.detail.messageId); break; } res.sendStatus(200); });

Het probleem met AI-agents: idempotentie en goedkeuring

Wanneer AI-agents de taak krijgen om e-mails te versturen, neemt het risico op deliverability-rampen toe. Een agent in een lus kan per ongeluk 1.000 identieke e-mails naar één gebruiker sturen en zo een stortvloed aan klachten veroorzaken.

Idempotentiesleutels

Gebruik altijd een idempotentiesleutel om dubbele verzendingen te voorkomen. Zo wordt de e-mail maar één keer verstuurd, ook als een agent een request opnieuw probeert na een timeout.

Human-in-the-loop (HITL)

Implementeer een goedkeuringsqueue voor agents die belangrijke communicatie versturen. De agent maakt het concept, maar een mens moet de uiteindelijke API-call starten. Zo voorkom je het scenario van "gehallucineerde spam", waarin een agent irrelevante content naar een grote lijst stuurt en je klachtpercentage omhoogschiet.

Afwegingen tussen infrastructuur en kosten

Bij de keuze voor een provider maak je vaak een afweging tussen gebruiksgemak en kosten. Bij opschalen zijn de prijsverschillen voor hoge volumes groot.

Volgens de prijspagina van Amazon SES kost SES a la carte 0.10 USD per 1.000 e-mails. Voor een volume van 50.000 e-mails is dat ongeveer 5 USD. Volgens de prijzen van Postmark kosten 50.000 e-mails daarentegen ongeveer 66 USD (15 USD basis voor 10.000 plus overschrijdingen tussen 1.20 en 1.80 USD per 1.000).

Andere opties zijn:

• Resend: het gratis niveau biedt 3.000 e-mails per maand (met een maximum van 100 per dag). Pro kost 20 USD per maand voor 50.000 e-mails, met overschrijdingen tegen 0.90 USD per 1.000 (prijzen van Resend).
• SendGrid: het gratis niveau is nu een proefperiode van 60 dagen; Essentials begint bij 19.95 USD per maand (prijzen van SendGrid).
• Mailgun: 15 USD per maand voor 10.000 e-mails, met overschrijdingen van 1.10 tot 1.80 USD per 1.000 (prijzen van Mailgun).

SES is goedkoper, maar het operationele werk van het beheren van je eigen suppressielijsten en reputatie is groter. SendHQ overbrugt dat verschil met transactioneel verzenden vanaf geverifieerde domeinen en ingebouwd suppressiebeheer, zonder de complexiteit van een kale AWS-configuratie.

Deliverability-checklist voor engineers

Volg deze technische checklist om zowel bounces als klachten tot een minimum te beperken:

• DNS-validatie: Zorg dat je SPF-, DKIM- en DMARC-records correct zijn. Gebruik de SendHQ DNS Checker om dit te verifiëren. Zie onze gids over DKIM, SPF en DMARC voor configuratiedetails.
• Double opt-in: Voeg nooit e-mailadressen toe aan een lijst zonder expliciete bevestiging. Dit is de enige manier om klachtpercentages vrijwel nul te houden.
• One-click unsubscribe: Implementeer de List-Unsubscribe-header. Het is beter dat een gebruiker zich afmeldt dan dat die je als spam markeert.
• Realtime-suppressie: Zorg dat je webhookhandler je database binnen 5 minuten bijwerkt.
• Monitoring: Stel meldingen in voor wanneer je bouncepercentage hoger wordt dan 2% of je klachtpercentage hoger wordt dan 0,1%.

Overzichtstabel: bounce vs. klacht

Kenmerk | Bounce | Klacht

Oorzaak | Technische fout (ongeldig e-mailadres, volle mailbox) | Actie van gebruiker (als spam gemarkeerd)

Signaal | Slechte lijsthygiëne / verouderde data | Irrelevante content / geen toestemming

Directe actie | Hard bounces direct verwijderen | Direct verwijderen

Impact op reputatie | Gemiddeld (tenzij zeer hoog) | Ernstig

Belangrijkste metric | Bouncepercentage | Klachtpercentage

Doel | Een schone lijst houden | Het vertrouwen van gebruikers behouden

Tot slot

Bounces zijn vervelend, maar klachten zijn een crisis. Een hoog bouncepercentage vertelt een ISP dat je slordig bent; een hoog klachtpercentage vertelt een ISP dat je kwaad in de zin hebt. Door je suppressielogica te automatiseren en strikte opt-inflows te implementeren, bescherm je je afzenderreputatie.

Zoekt je productteam een betrouwbare manier om transactionele e-mail en door agents gestuurde communicatie af te handelen? Bekijk dan SendHQ.