Bouncepercentage e-mail: meten, normen en oplossingen

Je bouncepercentage e-mail is het aandeel berichten dat de ontvangende server heeft geweigerd, gedeeld door het aantal berichten dat je hebt verstuurd. Houd harde bounces op een gezonde lijst onder 1%, zie 2% als het punt waarop je onderzoekt, en behandel 5% als incident. De meeste teams lezen een gemiddeld getal van een dashboard af en missen dat de noemer, het bouncetype en het tijdvenster elk het antwoord veranderen.

De rest van dit stuk gaat erover het getal eerst goed te meten en daarna te beslissen wat je ermee doet.

De formule is simpel. De noemer is waar teams het oneens worden.

Het bouncepercentage is het aantal gebounceerde berichten gedeeld door het aantal verstuurde berichten, maal 100. Sommige ESP's delen door het aantal afgeleverde berichten. Dat geeft een hoger getal, omdat afgeleverde berichten de bounces al uitsluiten. Controleer welke noemer jouw provider gebruikt voordat je het getal met een norm vergelijkt.

Amazon SES berekent zijn bouncepercentage bijvoorbeeld alleen op basis van harde bounces, afgezet tegen wat je via het account hebt verstuurd. Dat detail telt, want een dashboard dat zachte en harde bounces door elkaar toont, geeft een hoger getal dan het getal waarop je provider je beoordeelt.

Kies één definitie en schrijf die op naast de metriek, desnoods in de titel van het dashboard. Wij gebruiken harde bounces gedeeld door verstuurd, per verzenddomein, per 24 uur en per 7 dagen. Als twee mensen in je team voor dezelfde week verschillende getallen noemen, vergelijk je als eerste de noemer.

Harde, zachte en blokkade-bounces zijn drie verschillende signalen

Een harde bounce is een permanente fout. Het adres bestaat niet, het domein wordt niet opgelost of de mailbox is opgeheven. SMTP meldt die met een enhanced statuscode 5.x.x, gedefinieerd in RFC 3463.

Een zachte bounce is een tijdelijke fout: een volle mailbox, een server die even offline is of een bericht dat te groot is. Die komen terug met een 4.x.x-code, en een nette verzender probeert ze opnieuw. Voor de volledige indeling van de SMTP-codes verwijzen we naar onze eerdere gids over zachte versus harde bounces.

De derde categorie is de categorie die dashboards verbergen. Een blokkade is een 5.x.x-afwijzing die niets over het adres zegt, maar alles over jou: een IP-adres op een blokkadelijst, een mislukte authenticatiecontrole of een filter op inhoud of reputatie. Als je een blokkade als harde bounce telt, lijkt je lijst vuil terwijl het echte probleem in je verzendopzet zit.

Sla elk rapport over dat één regel "bounces" toont. Splits het in drie reeksen, anders maak je een lijst schoon die nooit het probleem was.

Wat is een goed bouncepercentage in 2026?

Er bestaat geen gepubliceerd getal, en dat is goed om te weten voordat je er één citeert. Gmail en Yahoo publiceren drempels voor spamklachten, niet voor bounces. Google vraagt bulkverzenders om het spampercentage in Postmaster Tools onder 0.10% te houden en nooit 0.30% te bereiken, volgens de FAQ over afzenderrichtlijnen.

Voor bounces komen de werkgetallen van ESP's en uit de praktijk. Dit zijn de drempels die wij als alarmniveaus gebruiken, geen garanties van een mailboxprovider.

Harde bounce-percentage per domein over 24 uur, en hoe wij ermee omgaan:

• Onder 0.5%: normaal voor een actieve, geverifieerde lijst.

• 0.5% tot 1%: in de gaten houden, en de bronnen van nieuwe adressen controleren.

• 1% tot 2%: onderzoeken, en het segment met het hoogste percentage pauzeren.

• 2% tot 5%: bulkverzending vanuit die stroom stoppen en de import of het formulier zoeken dat erachter zit.

• Boven 5%: incident. Amazon SES zet accounts op dit niveau onder beoordeling.

De laatste regel is een gedocumenteerde grens. In de documentatie van zijn reputatiedashboard stelt Amazon SES dat een account met een bouncepercentage van 5% of hoger onder beoordeling wordt gezet, en dat verzenden kan worden gepauzeerd als het percentage boven 10% blijft. Andere providers hanteren andere getallen en formuleringen, dus lees je eigen contract.

Segmenteer eerst: een gemiddeld getal verbergt de stroom die faalt

Een accountbreed percentage van 0.8% kan een transactionele stroom op 0.1% bevatten, naast een re-engagement-import op 6%. Het gemiddelde ziet er acceptabel uit, en de tweede stroom beschadigt stilletjes het verzenddomein.

Bereken het percentage per stroom, per bron en per ontvangend domein. Vier snedes vangen de meeste problemen op:

• Per stroom. Transactionele, lifecycle- en bulkcampagnes mogen nooit één getal delen.

• Per aanmeldbron. Formulieren, API-aanmeldingen, CSV-imports en partnerlijsten leveren heel verschillende adreskwaliteit.

• Per ontvangend domein. Een piek bij één provider wijst meestal op een afwijzingsbeleid, niet op een vuile lijst.

• Per leeftijd van het adres. Adressen die meer dan 12 maanden geleden zijn verzameld, bouncen vaker dan verse adressen.

Dit is geen rapportagedetail. Het is het verschil tussen een validatiebug in een formulier in een uur oplossen, en in paniek een gezonde lijst leegmaken.

Een vijfde snede die je kunt toevoegen zodra de andere er staan: per verzend-IP of per domein. Als je een apart IP gebruikt voor transactionele mail en een gedeelde pool voor campagnes, wijst een piek op een van beide waar je moet zoeken voordat je ook maar één logregel opent.

Bounce-events van je provider lezen zonder ze kwijt te raken

Elke serieuze ESP stelt bounces beschikbaar als events: via een webhook, een meldingsonderwerp of een events-API. Behandel die feed als bron van waarheid en schrijf hem weg naar je eigen opslag. Dashboards aggregeren, en daarbij verlies je de details die je later nodig hebt.

Bewaar voor elk event deze velden: het message-id, de ontvanger, het bouncetype, de enhanced statuscode, de diagnostische tekst en het tijdstip. Met die zes kun je bijna elke vraag beantwoorden die in een postmortem opduikt.

{
  "event": "bounce",
  "message_id": "msg_01H9",
  "recipient": "user@example.com",
  "bounce_type": "permanent",
  "status": "5.1.1",
  "diagnostic": "550 5.1.1 user unknown",
  "stream": "lifecycle",
  "ts": "2026-11-02T09:14:03Z"
}

Maak de handler idempotent en sleutel hem op het event-id van de provider plus het message-id. Providers herhalen webhooks. Een dubbel harde-bounce-event dat een teller twee keer ophoogt, vervormt je percentage en kan een adres onderdrukken dat eigenlijk prima is.

Postmark en Resend splitsen beide de bouncetypes in hun events en laten je ze per message stream opvragen. Daardoor is de splitsing per stroom hierboven goedkoop te bouwen.

De onderdrukkingsregel doet het meeste werk

De hefboom met het grootste effect is automatische onderdrukking. Na één harde bounce stop je met mailen naar dat adres, permanent, in de applicatielaag en niet alleen op de lijst van de provider.

De meeste ESP's onderdrukken harde bounces voor je. Het gat ontstaat wanneer je van provider wisselt, twee providers naast elkaar draait of verstuurt vanuit een systeem dat de onderdrukkingslijst nooit leest. Een eigen tabel met een genormaliseerd adres dicht dat gat.

Voor zachte bounces gebruik je een teller in plaats van een enkel event. Onze standaard is onderdrukken na drie opeenvolgende zachte bounces over minstens zeven dagen. Een mailbox die een week vol zit, is voor lifecycle-doeleinden in de praktijk verdwenen.

Verwijder gebounceerde adressen niet uit je gebruikerstabel. Markeer ze met de statuscode en de datum. Een verwijderde rij kan niet laten zien dat hetzelfde adres vorig kwartaal twee keer is gebounced. Je hebt die registratie nodig om te voorkomen dat je hetzelfde adres uit de volgende CSV opnieuw importeert, en dat is de meest voorkomende manier waarop een opgeschoonde lijst weer vervuild raakt.

Waarom het percentage ineens springt: de gebruikelijke oorzaken, op volgorde

Als het percentage beweegt, zoek de oorzaak in deze volgorde. De eerste drie verklaren de meeste pieken.

1. Een nieuwe import. Een CSV van een evenement, een partner of een oude CRM-export. Controleer eerst het bouncepercentage per bron.

2. Een aanmeldformulier zonder validatie. Typefouten zoals gmial.com en wegwerpdomeinen. Een syntax- en MX-controle bij het versturen verwijdert de meeste, en een bevestigingsmail vangt de rest op voordat ze als verzending in een lifecycle-flow meetellen.

3. Een wijziging in het verzenden. Een nieuw IP, een nieuw domein, of een warm-up die te snel opliep, wat eerder in blokkades dan in harde bounces uitmondt.

4. Een authenticatiefout. SPF-, DKIM- of DMARC-afstemming die faalt na een DNS-wijziging.

5. Een afwijzingsbeleid aan de providerkant. Een ontvangend domein heeft zijn filters aangescherpt. Je percentage stijgt dan alleen bij dat domein.

De diagnose is de verdeling van de statuscodes, gegroepeerd per stroom en per ontvangend domein, over hetzelfde venster als de piek. Een stijging van 5.1.1 (user unknown) wijst op de lijst. Een stijging van 5.7.x wijst op beleid, authenticatie of reputatie. Die vragen om tegengestelde oplossingen, daarom sla je de code op.

Wat wij zouden alarmeren

Alarmeren op een daggemiddelde is te traag. Een slechte import kan binnen een uur 40.000 berichten versturen. Alarmeer daarom op een rollend venster:

• Harde bounces boven 1% over de laatste 1.000 verzendingen in een stroom.

• Een enkel ontvangend domein boven 5% over minstens 200 verzendingen in een uur.

• Een aantal 5.7.x-blokkades dat duidelijk boven je normale niveau uitkomt.

Koppel de eerste twee aan een pauze van de betreffende stroom, niet aan een melding voor een mens. Een mens kan achteraf onderzoeken. De pauze beschermt je reputatie in de eerstvolgende tien minuten.

Exporteer het percentage naar de monitoring die je al gebruikt, of dat nu Grafana, Datadog of een eigen oplossing is. Houd het streamlabel bij de reeks, zodat de splitsing de export overleeft.

Voor rapportage naar het management gebruik je het harde bouncepercentage per stroom over een venster van 7 dagen, plus het aantal blokkades. Laat zachte bounces in de engineering-weergave staan, waar ze nuttig zijn, en haal ze uit de weergave voor het management, waar ze verwarring veroorzaken. Rapporteer nooit alleen het geblende accountgetal, want dat beweegt om redenen die niemand in de vergaderruimte kan verklaren.

Als iemand één getal vraagt, geef dan het harde bouncepercentage van de transactionele stroom. Daar kost een fout je een wachtwoordreset of een factuur, en het is de zuiverste maatstaf voor de vraag of je infrastructuur gezond is.

De volgende concrete stap is klein: haal de bounce-events van de afgelopen 30 dagen op, groepeer ze op stroom en statuscode, en kijk welke rij je niet had verwacht.