Soft bounce vs hard bounce e-mail: SMTP codes verklaard

Soft bounce vs hard bounce e-mail verschil: het bepaalt alles

Soft bounce vs hard bounce e-mail: het verschil wordt bepaald door één SMTP digit. 4xx betekent "probeer straks opnieuw", 5xx betekent "dit adres bestaat niet meer". Stuur naar een volledige mailbox en je krijgt 4xx; stuur naar niet-bestaand en je krijgt 5xx; je suppressielijst moet in dezelfde minuut bijwerken. Deze classificatie verkeerd gebruiken erodeert domeinreputatie sneller dan de meeste andere operationele fouten.

SMTP-codes zijn de enige classificatie die telt

Elke e-mailbezorgingsfout rapporteert een driecijferige SMTP-responscode. Het eerste digit is waar je bounce processor op moet splitsen.

4xx-codes duiden op een voorbijgaande toestand: de ontvangende server accepteerde de verbinding, evalueerde het bericht en besloot dat het nu niet kan bezorgen. 5xx-codes duiden op een permanente toestand: de ontvangende server zegt je dat je dit adres helemaal moet stoppen proberen.

Die splitsingslogica is infrastructuur-niveau. Je applicatie hoeft de leesbare diagnostische tekst niet te lezen om te beslissen of je moet suppressen; het eerste digit maakt die keuze.

Het tweede en derde digit voegen specificiteit toe. Een 452 vertelt dat de mailbox vol is. Een 550 zegt dat het adres niet bestaat. Een 421 zegt dat de server tijdelijk niet beschikbaar is. De meeste bounce classifiers mappen deze sub-codes op interne event types, maar de 4/5 split blijft de primaire vertakking. Als je pipeline alle 4xx als herprobeerbaarheid behandelt en alle 5xx als eindstation, dek je ruwweg 95% van productiecases correct.

Wat veroorzaakt een soft bounce -- en hoe lang opnieuw proberen

De meest voorkomende 4xx scenario's die een productie-e-mailpipeline tegenkomt, grotendeels gerangschikt naar frequentie:

Volledige mailbox (452): Het quotum van de ontvanger is uitgeput. De meeste ESP's herproberen gedurende 24 tot 72 uur voordat ze omzetten in hard failure. Deze code is oververtegenwoordigd in consumer inboxen; B2B-adressen produceren het zelden geïsoleerd.

Greylisting (451): De ontvangende MTA stelt onbekende afzenders tijdelijk uit als antispamvoorzorgsmaatregel. Een herpoging 10 tot 30 minuten later slaagt meestal. Dit is een normaal onderdeel van de first-send handshake op een nieuw domein of IP, geen teken van lijstkwaliteitsproblemen op zich.

Server tijdelijk niet beschikbaar (421): De remote server is omlaag, rate-limiting of overbelast. Herprobeert met exponentiële backoff. De meeste servers herstellen binnen enkele uren; als dit dagen aanhoudt voor hetzelfde domein, kan het domein zelf problemen hebben.

Bericht te groot (552/554 soft variant): De e-mail overschrijdt de grootttelimiet van de server voor deze mailbox. Opnieuw proberen zonder payload verkleining mislukt altijd; route dit naar een aparte verwerkingswachtrij en waarschuw de afzender.

Standaard herprobeervensteren in productie: eerste herpoging na 5 minuten, dan 30 minuten, dan 2 uur, dan 6 uur, dan 24 uur. Na 5 dagen zonder succesvolle bezorging is de SMTP-conventie het genereren van een non-delivery report (NDR) en het terugsturen van het bericht naar de afzender. Of je ESP zich aan die 5-daags venster houdt of korter kiest, is de moeite waard in je configuratie te verifiëren.

Één metriek waard om te volgen: de verhouding van soft bounces die op eerste herpoging oplossen versus die meer dan drie pogingen vereisen. Een gezonde lijst zal de meeste 452 en 421-codes binnen twee herpogingen zien oplossen. Hoge persistentie over veel herpogingscycli is een signaal waard om op segmentniveau te onderzoeken.

De drie hard bounce-modi die je pipeline ziet

5xx-codes zijn niet monolitisch. De sub-codes vertellen je verschillende dingen over wat je na suppressie moet doen.

Niet-bestaand adres (550/551): Het domein is geldig maar het lokale gedeelte wijst niet naar een echte mailbox. Dit is de meest voorkomende hard bounce in consumgerichte producten: signup-typefouten, verlaten accounts, adressen die zes maanden geleden geldig waren en toen werden verwijderd. Suppresseer onmiddellijk. Er is geen hersteelpad.

Domein bestaat niet of accepteert geen mail (550/553/554): De MX-recordzoeking mislukte of het domein wijst actief alle inkomende e-mail af. Suppresseer op domeinniveau, niet alleen het adres. Alle andere contacten op dat domein zijn net zo onbereikbaar, en een domein-niveau query brengt ze sneller naar boven dan wachten tot elk afzonderlijk bounced.

Permanent geblokkeerd door beleid (550/5.7.1): De ontvangende server heeft een beleidsblok tegen je verzenddomein of IP. Dit is zeldzamer maar operationeel ernstiger omdat het een klasse adressen over een hele organisatie kan beïnvloeden. Controleer met je IP-reputatielogboeken voordat je beslist of je alleen het triggering-adres suppresseert of escalateert naar je deliverabilityteam.

Één nuance die bugs in productie veroorzaakt: sommige MTA's retourneren 4xx-codes voor wat effectief permanente omstandigheden zijn. Een domein dat is verlopen en gepark kan gedurende weken 450 retourneren in plaats van 550 terwijl de registrar langzaam de MX-record afbreekt. Je pipeline moet elk adres dat 4xx retourneert op vijf opeenvolgende pogingen over twee weken behandelen als kandidaat voor hard-bounce status, ongeacht het SMTP-voorvoegsel.

Wanneer soft bounces functioneel permanent worden

De schone categoriegrenzen tussen 4xx en 5xx houden niet onder productieomstandigheden. Drie patronen moeten dezelfde suppressielogica activeren als een hard bounce, zelfs wanneer de code in het 4xx bereik blijft.

Ten eerste: herhaalde volledige-mailbox bounces zonder voorafgaande engagement. Als een adres nooit geopend, nooit geklikt, en vijf keer in de afgelopen 30 dagen 452 gebouncet, is de mailbox bijna zeker verlaten. Doorgaan met bezorgingspogingen verhoogt je bouncerate zonder realistisch activatiekans. Behandel het als hard.

Ten tweede: aanhoudend greylisting zonder resolutie. Greylisting lost op herpoging op voor legitieme afzenders. Als hetzelfde adres consistent vertraging buiten 48 uur heeft, ben je ofwel op een blocklist ofwel stuurt naar een spamval. Geen van beide gevallen rechtvaardigt voortgezette pogingen; de herpogingscycli vergroten de reputatieschade.

Ten derde: 4xx-codes die alleen voor je verzenddomein voorkomen. Als andere afzenders hetzelfde adres succesvol bereiken maar je verzendingen constant worden uitgesteld, is het probleem afzenderreputatie, niet mailboxstatus. Agressiever opnieuw proberen maakt het erger.

De operationele regel om in code in te voegen: na drie soft bounces zonder resolutie, verplaats het adres naar een proefstatus suppressie. Stop met het verzenden van lifecycle-e-mails ernaar. Houd het geschikt voor kritieke transactionele e-mail (wachtwoord reset, factureringswaarschuwing) totdat je hebt bevestigd dat het werkelijk onbereikbaar is.

Suppressielogica: verwijderen vs parkeren vs opnieuw proberen

Niet elke bounce-gebeurtenis rechtvaardigt volledige verwijdering uit je contactopslag. De juiste oproep hangt af van het bouncetype en de voorafgaande engagementgeschiedenis van de contactpersoon.

5xx hard bounce (enige voorafgaande engagement) -- Onmiddellijke suppressie, geen herpogingen.

4xx, eerste voorval (actieve engagement) -- Herprobeert volgens schema, geen suppressie.

4xx, drie of meer voorvallen (geen voorafgaande engagement) -- Proefstatus suppressie.

4xx, vijf of meer voorvallen (enige engagement) -- Behandel als hard bounce.

4xx volledige mailbox alleen (hoog LTV of transactioneel) -- Herprobeert wekelijks voor 30 dagen.

Het onderscheid tussen "verwijderen" en "parkeren" is belangrijk in de praktijk. Een verwijderd adres valt volledig uit je contactopslag. Een geparkt adres blijft met een onderdrukte status: je kunt het nog steeds opvragen, het in een gezondheidsdashboard oppervlakken, en het opnieuw activeren als de contactpersoon zich opnieuw aanmeldt via een nieuw formulier. Voor waardevolle transactionele flows is parkeren het juiste gesprek. Voor koude outreach lijsten is verwijdering schoner.

Een operationeel punt waard om in code af te dwingen: welke actie je ook onderneemt, moet worden gelogd met de SMTP-code en timestamp als de onderdrukkingsreden. Onderdrukkingsgebeurtenissen zonder expliciete redenen zijn bijna onmogelijk later te controleren wanneer je wilt begrijpen waarom een cohort van adressen tussen twee campagnes donker ging.

Bouncerate-drempels die ISP-gedrag veranderen

Het figuur van 2% totale bouncerate dat in de industrie circuleert als benchmark is een vloer, geen doel. De daadwerkelijke drempels die tellen zijn gedetailleerder.

Gmail en Outlook rapporteren afzender-niveau spampercentage via Google Postmaster Tools en Microsoft SNDS respectievelijk. Die dashboards stellen je bouncerate niet rechtstreeks bloot, maar de twee signalen correleren strak. Een aanhoudende bouncerate boven 2% gaat bijna altijd vooraf aan een plaatsingsstijging zichtbaar in die tools, meestal met een vertraging van 3 tot 5 dagen.

Praktische drempels om per verzenddomein te monitoren:

• Onder 0,5%: Normaal bereik. Geen correctieve actie vereist.

• 0,5 tot 1,5%: Monitor dicht. Onderzoek bounceredenen per segment; meestal enkele cohorten met gedegradeerde datakwaliteit.

• 1,5 tot 2,5%: Pauzeer de campagne en onderzoek voordat je herstart. De meeste ESP's beginnen geautomatiseerde rate limiting in dit bereik.

• Boven 2,5%: Stop het verzenden. Schoon de getroffen segmenten voordat je opnieuw start. Op dit niveau hebben sommige ISP's al berichten gefilterd naar spam of verbindingen op de gateway uitgesteld.

Één operationeel detail dat wordt genegeerd: bouncepercentages worden berekend ten opzichte van verzochte bezorgingen, niet totale lijstgrootte. Als je zwaar segmenteert en alleen naar engaged abonnees verzendt, daalt je absolute bouncetelling maar het berekende percentage verandert mogelijk niet evenredig. Volg zowel absoluut aantal als percentage per verzending. Pieken in absoluut aantal zijn vaak het eerdere waarschuwingengsignaal, vooral na een import van een lijst of een re-engagementcampagne.

Bounce-signalen lezen in je deliverytrace

Bounce-gebeurtenissen moeten in je deliverytrace met dezelfde trouw worden weergegeven als opens en klikken. Zo niet, je observability-setup heeft een gat.

Minimaal moet elke bounce-gebeurtenis registreren: timestamp, SMTP-responscode, volledig diagnostisch bericht van de remote server, verzendende IP, ontvangende domein en contactid. Het ontvangende domein wordt vaak weggelaten en vaak nodig. Wanneer een domein 550 5.7.1 start terug te geven over meerdere contacten, wil je dat patroon op domeinniveau detecteren voordat het je reputatiescore scaadt over het hele verzenddomein.

Met die gegevens correct gemodelleerd, dekken drie weergaven de meeste bounce-monitoring behoeften: een dagelijkse bouncerate per verzenddomein, een soft-to-hard omzettingspercentage per cohort (hoeveel van vandaag's 4xx-events nog steeds over 10 dagen zullen bounceën), en een domein-niveau bounce-frequentietabel om organisatorische suppressies te vangen voordat ze samengesteld raken.

Het doel is geen nulbouncerate. Dat is niet bereikbaar op een lijst die groeit. Het doel is een bounce-verwerkingspipeline die nauwkeurig op de eerste SMTP-reactie classificeert, onderdrukt op de juiste drempel en de signalen oppervlakt die een systeemprobleem aangeven voordat het escaleert tot een leveringsincident.