Bouncemail lezen: van foutmelding naar oorzaak

Begin bij het eerste cijfer, niet bij de tekst

De Engelse zin in een bouncemelding is bijna altijd het minst bruikbare deel ervan. Wat u eerst moet weten is of het bericht nog onderweg is of definitief is opgegeven, en dat staat in één cijfer. Een code die met een 4 begint is tijdelijk: uw mailserver houdt het bericht vast en biedt het vanzelf opnieuw aan, dagenlang. Een code die met een 5 begint is definitief.

Dat onderscheid bepaalt of u iets moet doen. Bij een 4 is de juiste handeling meestal niets. Bij een 5 moet er iets veranderen, want ongewijzigd opnieuw versturen levert dezelfde weigering op. Wat elke afzonderlijke code betekent staat in onze bounce-uitlegger; hieronder gaat het om de twee gevallen waar het in de praktijk het vaakst op uitdraait.

Twee meldingen die wij regelmatig zien

Gmail: "receiving mail at a rate that prevents additional messages"

De melding komt binnen als een definitieve bounce, met dsn=5.2.1 en status=bounced:

550-5.2.1 The user you are trying to contact is receiving mail at a rate
550-5.2.1 that prevents additional messages from being delivered. For more
550-5.2.1 information, go to
550 5.2.1  https://support.google.com/mail/?p=ReceivingRatePerm

Wat hier staat gaat niet over u. Het is een grens aan de ontvangende kant: die ene mailbox krijgt op dit moment zoveel post dat Gmail er niets meer bij laat. Uw SPF, uw DKIM, uw IP-adres en uw reputatie staan er los van, en er is geen instelling waarmee u het oplost. Google publiceert ook geen grens waarboven dit gebeurt — komt u ergens een concreet aantal berichten per uur tegen, dan is dat niet van Google afkomstig.

Het lastige is dat de code met een 5 begint terwijl de oorzaak tijdelijk is. Uw server geeft het dus op, terwijl hetzelfde bericht een uur later wel was aangekomen. Ziet u dit in golven bij één ontvanger, houd er dan rekening mee dat die persoon wordt volgelopen: iemand die op honderden nieuwsbrieven tegelijk wordt ingeschreven om een echte melding te verbergen, levert exact dit beeld op.

Yahoo: "temporarily deferred due to unexpected volume or user complaints"

Dezelfde dag, een andere ontvanger, en een heel ander soort melding:

421 4.7.0 [TSS04] Messages from 192.0.2.10 temporarily deferred due to
unexpected volume or user complaints; see
https://postmaster.yahooinc.com/error-codes

Hier begint de code met een 4, dus het bericht staat nog gewoon in de wachtrij. Yahoo zegt met "volume or user complaints" bewust niet welke van de twee het is: het is één reputatiesignaal en geen aparte teller. Het kenmerk tussen blokhaken verwijst naar hun interne regel, en Yahoo publiceert nergens wat een afzonderlijk nummer betekent — dezelfde zin hoort ook bij [TS01]. Wie u een exacte definitie van TSS04 geeft, heeft die niet van Yahoo.

Kleine praktische noot: de URL in de melding klopt niet meer. Yahoo's postmasteromgeving heet nu Sender Hub en postmaster.yahooinc.com stuurt u door naar senders.yahooinc.com.

Doorsturen is vaker de oorzaak dan uw instellingen

Beide meldingen hierboven gingen over doorgestuurde post, en dat is geen toeval. Het doorsturen van e-mail — een adres op uw eigen domein dat alles naar een Gmail- of Outlook-adres doorzet — is de meest onderschatte oorzaak van bezorgproblemen. Er gaan drie dingen tegelijk mis.

SPF klopt niet meer, en de reparatie kost u DMARC

Uw doorstuurserver staat niet in het SPF-record van de oorspronkelijke afzender, dus SPF faalt. De gangbare oplossing daarvoor heet SRS: uw server herschrijft het envelope-adres naar uw eigen domein, waardoor SPF weer slaagt. Dat werkt, maar er zit een prijs aan. Na die herschrijving lijnt SPF uit op úw domein en niet meer op het domein in het zichtbare afzenderadres, en DMARC eist juist die uitlijning. Bij doorgestuurde post hangt DMARC dus volledig op DKIM.

Goed om te weten: SRS is nooit een standaard geworden. Het voorstel uit 2003 is verlopen en het woord komt in de SPF-standaard zelf niet voor; wat er wél staat is dat een tussenpartij die het afzenderadres herschrijft ervoor moet zorgen dat SPF daarna slaagt.

DKIM overleeft doorsturen, maar niet als u aan het bericht komt

DKIM is de enige controle die doorsturen in principe doorstaat, want de handtekening zit op het bericht zelf. Maar hij breekt zodra dat bericht onderweg verandert, en dat gebeurt vaker dan u denkt. Een voettekst toevoegen, [SPAM] voor het onderwerp zetten, links herschrijven voor klikbescherming, of een virusscanner die de inhoud opnieuw codeert — elk van die vier is genoeg.

Een hardnekkig misverstand is dat de soepele variant van DKIM dit opvangt. Die tolereert alleen verschillen in spaties en hoofdletters in headernamen; toegevoegde tekst valt daar niet onder. Een disclaimer onder het bericht breekt de handtekening ook in de soepele variant.

De klachten komen bij u terecht

Dit is het punt dat het meest onderschat wordt. Markeert de eindgebruiker doorgestuurde rommel als spam, dan telt die klacht tegen úw server — hij is immers de partij die het bericht aanbood. Google zegt dat met zoveel woorden: worden doorgestuurde berichten van uw domein als spam gemarkeerd, dan is de kans groter dat toekomstige berichten van uw domein dat ook worden. Met SRS wordt dat effect zelfs sterker, want dan wijst het envelope-adres nadrukkelijk naar u.

De remedie die Google hier aanbeveelt is eenvoudig en wordt zelden opgevolgd: filter spam voordat u doorstuurt, niet erna. En overweeg of doorsturen wel de juiste oplossing is. Laat de ontvangende kant de post ophalen via IMAP of POP, en er is geen doorstuurserver meer die reputatie en bounces erft.

Waarom u dit nu ineens ziet

Veel beheerders krijgen sinds kort bounces op een inrichting die jarenlang werkte. Dat komt niet doordat de eisen zijn aangescherpt, maar doordat de handhaving dat is. De inhoudelijke eisen van Google en Yahoo staan sinds begin 2024 vast — SPF of DKIM voor iedereen, en voor wie veel verstuurt allebei plus een DMARC-record, uitlijning en een afmeldlink met één klik. Wat daarna veranderde is het gevolg van niet-voldoen: eerst belandde die post in de spammap, nu wordt hij tijdens het SMTP-gesprek geweigerd. Google heeft die aanscherping voor november 2025 aangekondigd.

Microsoft is in mei 2025 aangehaakt met dezelfde eis voor outlook.com, hotmail.com en live.com: vanaf vijfduizend berichten per dag vanaf één domein moeten SPF, DKIM én DMARC alle drie in orde zijn, waarbij p=none volstaat. Microsoft plaatst niet-voldoende post eerst in de ongewenste map en weigert hem daarna met code 5.7.515. Wanneer weigeren de standaard wordt, heeft Microsoft niet aangekondigd.

Twee dingen die vaak verkeerd worden overgenomen. De drempel van vijfduizend berichten per dag is van Google en van Microsoft; Yahoo hanteert bewust géén getal. En de eisen van Google gelden alleen voor persoonlijke Gmail-adressen, niet voor zakelijke domeinen die op Google Workspace draaien — dat verklaart waarom uw post naar een zakelijke klant wel aankomt en naar diens privéadres niet.

Als een Nederlandse of Belgische provider weigert

Hier wordt het ongemakkelijk, en dit staat in vrijwel geen enkel artikel over dit onderwerp: de grote Nederlandse en Belgische providers hebben geen postmasterpagina. Waar Google, Microsoft en Yahoo alle drie een omgeving bieden waarin u ziet hoe zij naar u kijken, is er bij KPN en Ziggo niets van dien aard. Een blokkade meldt u er per e-mail aan het abuse-adres, en dat is het.

De meldingen zijn navenant. KPN weigert met een kale 550 5.7.1 Mail rejected, zonder reden en zonder verwijzing — u weet dus niet eens waaraan het ligt. Ziggo's eigen klantenservicepagina voor geblokkeerde afzenders adviseert een virusscan, het wijzigen van wachtwoorden en 24 uur wachten. Van de Benelux-providers heeft alleen Proximus een zelfbedieningsformulier om een blokkade te laten opheffen.

Ter vergelijking: GMX en WEB.DE zetten in élke weigering een unieke link mee naar een pagina die precies uitlegt waarom dít bericht werd geweigerd, en Orange publiceert een lijst met ongeveer twintig eigen foutcodes inclusief oplossing. Dat is geen detail. Het bepaalt of u een probleem kunt oplossen of alleen kunt afwachten, en het is een van de redenen dat wij hier zelf naar het log kijken in plaats van u naar een formulier te sturen.

Blocklists: welke ertoe doen en welke niet

Staat er in de weigering een verwijzing naar een blocklist, dan is dat het spoor. Drie lijsten doen er in de praktijk toe. Spamhaus is de belangrijkste en wordt onder meer door Yahoo rechtstreeks geraadpleegd; controleren en verwijderen gaat via check.spamhaus.org. Barracuda heeft een eigen verwijderformulier waarbij een echte toelichting vereist is. SpamCop lost zichzelf op: noteringen vervallen automatisch zodra de meldingen stoppen.

Verwijdering is bij alle drie gratis. Dat is het vermelden waard, want er bestaat een markt van partijen die u geld vragen voor een delisting die u zelf kosteloos aanvraagt.

Twee dingen om níet te doen. Raak niet in paniek van een notering bij UCEPROTECT: die lijst blokkeert op niveau twee een heel netwerkblok en op niveau drie een compleet netwerk om het gedrag van één ander, biedt tegen betaling directe verwijdering aan, en wordt door Google, Microsoft en Yahoo niet geraadpleegd. Een notering daar vervalt vanzelf zodra het werkelijke misbruik stopt. En reageer niet op een verwijzing naar SORBS: die dienst is in juni 2024 gestopt en het domein bestaat niet meer, dus een server die daar nog op weigert is zelf verkeerd ingesteld. Er valt niets te laten verwijderen.

Een laatste valkuil die vaak voor een blocklist wordt aangezien: een melding als "blocked using zen.spamhaus.org; Error: open resolver" betekent niet dat ú op een lijst staat. Spamhaus weigert vragen die via publieke DNS-diensten binnenkomen, en de ontvangende server behandelt dat foutantwoord ten onrechte als een notering. Dat is een probleem aan de ontvangende kant.

De volgorde waarin u het aanpakt

1. Kijk naar het eerste cijfer. Begint de code met een 4, doe dan niets en laat uw server zijn werk doen.
2. Kijk of er is doorgestuurd. Staat er een orig_to dat afwijkt, of een adres dat met SRS0= begint, dan zoekt u de oorzaak daar en niet in uw DNS.
3. Lees welke partij weigerde en zoek de code op bij díe partij. Dezelfde code betekent bij Google iets anders dan in de standaard.
4. Gaat het over authenticatie, begin dan bij DKIM. Die overleeft doorsturen en SPF niet.
5. Controleer daarna uw SPF-record, en dan vooral het aantal lookups: boven de tien krijgt niets meer een pass, ook uw eigen mailserver niet.
6. Pas daarna kijkt u naar blocklists en reputatie. Dat is bijna nooit de eerste oorzaak, maar wel de traagste om op te lossen.

Voor stap 3 gebruikt u de bounce-uitlegger, voor stap 5 de SPF-controleur. Beide zijn gratis en zonder account te gebruiken.