Uw melding uitleggen
Uw tekst blijft in deze pagina. Er gaat niets naar onze servers — open het netwerktabblad van uw browser en u ziet dat er niets wordt verstuurd. Dat is hier geen bijzaak: in een bouncemelding staan e-mailadressen en IP-adressen, en die willen wij niet hebben.
Alle codes op een rij
Het eerste cijfer is het belangrijkste. Een 4 betekent tijdelijk: uw server houdt het bericht vast en probeert het vanzelf opnieuw, meestal een dag of vijf lang. Een 5 betekent permanent: uw server geeft het op en stuurt het bericht als onbestelbaar terug. Het tweede cijfer zegt waar het over gaat — 1 en 2 over het adres en de mailbox, 3 en 4 over het systeem en het netwerk, 7 over beleid en beveiliging. Dat laatste is waar SPF, DKIM en DMARC thuishoren.
De ontvanger of het adres
5.1.1 — Dit adres bestaat niet
Alle ontvangers
De mailbox in het adres bestaat niet op het ontvangende systeem. Dit is de enige categorie waar de RFC ondubbelzinnig over is: deze fout is alleen bruikbaar als permanente fout. Een typefout, een medewerker die weg is, of een adres uit een verouderde lijst.
Wat u eraan doet: Controleer de spelling en haal het adres uit uw lijst. Blijven schrijven naar adressen waarvan u weet dat ze niet bestaan is het duidelijkste signaal van slechte lijsthygiëne dat u kunt afgeven.
Bron: RFC 3463
5.2.1 — De mailbox bestaat wel, maar neemt geen post aan
Alle ontvangers
De RFC omschrijft dit als een mailbox die is uitgeschakeld. Bijzonder aan deze code is dat de standaard er zelf bij zegt dat het permanent kan zijn — als de mailbox nooit meer terugkomt — of tijdelijk, als hij alleen even uitstaat. De code begint met een 5, dus uw server geeft het op, maar de oorzaak kan morgen verdwenen zijn.
Wat u eraan doet: Behandel het als permanent voor deze verzending, maar schrap het adres niet meteen als u weet dat het om een echt persoon gaat. Krijgt u dit van Gmail, kijk dan of er ook ReceivingRatePerm in de melding staat: dan is het iets heel anders.
Bron: RFC 3463
5.2.1 — Gmail knijpt de aflevering aan deze ontvanger af
Gmail en Google Workspace
Google gebruikt 5.2.1 voor twee heel verschillende dingen. Staat er DisabledUser in de melding, dan is het account uitgeschakeld. Staat er ReceivingRatePerm, dan krijgt de ontvanger op dit moment te veel post en laat Gmail er niets meer bij. Dat tweede geval is geen fout van u: het is een grens aan de ontvangende kant, en uw authenticatie, uw IP-adres en uw reputatie staan er los van. Het is wel een 5-code, dus uw server geeft het op terwijl de oorzaak tijdelijk is.
Wat u eraan doet: Kijk eerst welke van de twee varianten er staat. Bij ReceivingRatePerm valt er aan de verzendkant niets in te stellen; laat uw server het later opnieuw proberen in plaats van direct te bouncen. Bij DisabledUser is het adres dood en haalt u het weg.
4.2.2 — De mailbox van de ontvanger is vol
Alle ontvangers
Er is geen ruimte meer in het postvak. De RFC schrijft voor dat dit als tijdelijke fout wordt behandeld, ook al ziet u soms 5.2.2 — de ontvanger kan immers opruimen. Uw server blijft het dus een aantal dagen proberen.
Wat u eraan doet: Niets doen. Loopt het na dagen alsnog vast, dan krijgt u een definitieve melding en is contact langs een andere weg de enige weg.
Bron: RFC 3463
5.2.3 — Het bericht is groter dan de ontvanger toestaat
Alle ontvangers
Niet de mailbox is vol, maar dit ene bericht overschrijdt de maximale berichtgrootte van het ontvangende systeem. Die grens verschilt per partij en staat los van wat úw server toestaat, dus een bijlage die intern prima rondgaat kan extern stuklopen.
Wat u eraan doet: Verstuur grote bestanden niet als bijlage maar als downloadlink. Dat lost meteen het probleem op dat een bijlage bij elke ontvanger apart wordt opgeslagen.
Bron: RFC 3463
5.1.10 — Dit domein ontvangt bewust geen post
Alle ontvangers
Het domein publiceert een null MX: een MX-record dat expliciet zegt dat er geen post wordt aangenomen. Dat is geen storing maar een keuze, vastgelegd in RFC 7505, en de juiste manier voor een organisatie om te melden dat een domein alleen voor de website bestaat.
Wat u eraan doet: Zoek het juiste domein op. Het heeft geen zin dit opnieuw te proberen; er is geen mailserver om mee te praten.
Bron: RFC 7505
Snelheid, volume en capaciteit
4.7.0 — Tijdelijk geweigerd om beleidsredenen
Alle ontvangers
De 7 staat voor beleid en beveiliging, de 4 voor tijdelijk. De ontvanger wil uw post nu niet, maar sluit later niet uit. Wat de reden is, staat niet in de code — daarvoor moet u de zin ernaast lezen. Dit is de code waarmee grote partijen afknijpen op reputatie.
Wat u eraan doet: Laat uw server zijn werk doen; hij probeert het vanzelf opnieuw met oplopende tussenpozen. Handmatig forceren helpt niet en maakt het patroon verdachter. Komt het steeds terug, dan is de tekst in de melding uw enige aanknopingspunt.
4.7.0 — Yahoo houdt uw post tijdelijk tegen
Yahoo en AOL
Yahoo gebruikt 4.7.0 met een eigen kenmerk tussen blokhaken, zoals [TSS04] of [TS01]. Dat kenmerk verwijst naar hun interne regel en niet naar een gepubliceerde definitie: Yahoo legt zijn codes per nummer nergens uit en gebruikt dezelfde zin bij verschillende nummers. De reden is altijd dezelfde combinatie van volume en klachten. Het woord "deferred" dat u in een Postfix-log ziet komt overigens van Postfix zelf, niet van Yahoo.
Wat u eraan doet: Zie de uitleg bij het kenmerk zelf. Kort samengevat: bulkmail naar Yahoo en AOL pauzeren, de wachtrij met rust laten, en uitzoeken waar het volume vandaan komt.
4.7.28 — Gmail knijpt af op uw reputatie
Gmail en Google Workspace
Google beperkt tijdelijk hoeveel post het van u aanneemt. De zin ernaast verraadt waaróp wordt afgeknepen, en dat is het hele verhaal: op uw IP-adres, op het hele netblok waarin dat adres ligt, op uw DKIM-domein, op uw SPF-domein, op een webadres dat in uw bericht staat, of op het hergebruiken van dezelfde Message-ID. De netblok-variant is vervelend, want dan is een buur op hetzelfde blok de oorzaak. De Message-ID-variant treft vooral doorstuurservers en slecht ingestelde mailinglijsten.
Wat u eraan doet: Lees welke variant er staat en pak díe aan. Bij het netblok is uw hoster aan zet. Bij een webadres in de tekst: controleer of u een gedeelde linkverkorter gebruikt die door anderen is besmet. Bij Message-ID: zorg dat elk bericht een eigen unieke Message-ID krijgt.
4.7.500 — Microsoft houdt u even aan de kant omdat u nieuw bent
Outlook.com en Microsoft 365
De melding luidt meestal "Server busy, please try again later", maar dat is niet wat er gebeurt. Microsoft legt zelf uit dat deze code komt wanneer een verzendend IP-adres zijn patroon verandert en ineens veel meer post stuurt dan voorheen. Het is een proefperiode voor nieuwe of veranderde verzenders, en Microsoft noemt het zelf greylisting.
Wat u eraan doet: Niets bijzonders, en vooral niet harder gaan versturen. Microsoft schrijft dat de fout vanzelf verdwijnt zodra u over een paar dagen een verzendgeschiedenis heeft opgebouwd. Verstuur in die periode gelijkmatig in plaats van in pieken.
4.7.650 — Outlook.com knijpt af op de reputatie van uw IP-adres
Outlook.com en Microsoft 365
Uw verzendende IP-adres wordt tijdelijk beperkt wegens zijn reputatie. Microsoft documenteert deze code niet per nummer; wat u ziet is de melding van hun filter, meestal met een kenmerk als (S775) erachter. In februari 2026 erkende Microsoft op zijn eigen aanmeldformulier een storing waarbij IP-adressen op grote schaal werden afgeknepen; een bericht dat die is opgelost is er niet.
Wat u eraan doet: Dien een melding in bij Outlook.com via olcsupport.office.com en meld u aan voor SNDS, zodat u ziet hoe Microsoft naar uw IP-adres kijkt. Blijf ondertussen gelijkmatig versturen; de post staat in uw wachtrij en gaat er vanzelf uit als de beperking wordt opgeheven.
4.4.1 — Geen antwoord van de ontvangende server
Alle ontvangers
Uw server heeft verbinding proberen te maken en kreeg niets terug. De ontvangende server ligt eruit, staat achter een firewall die niet reageert, of de route ernaartoe is kapot. Dit zegt niets over uw post of uw reputatie.
Wat u eraan doet: Afwachten. Duurt het langer dan een werkdag, dan is het de moeite waard de ontvangende partij langs een andere weg te laten weten dat hun mailserver niet bereikbaar is.
Bron: RFC 3463
4.4.7 — De bezorgtijd is verstreken
Alle ontvangers
Uw server heeft het dagenlang geprobeerd en geeft het nu op. Dit is de code die u krijgt als een tijdelijke fout blijft aanhouden: elke poging faalde met een 4-code, en na de ingestelde wachttijd — bij een standaard Postfix vijf dagen — komt het bericht alsnog als onbestelbaar terug. Dezelfde code komt ook als 5.4.7 voor.
Wat u eraan doet: Zoek in uw log op de oorspronkelijke reden waarom het bericht bleef hangen; die staat in de eerdere regels en is het echte probleem. De verstreken bezorgtijd is het gevolg.
Bron: RFC 3463
4.3.2 — Het ontvangende systeem neemt nu geen post aan
Alle ontvangers
De ontvangende server draait wel, maar accepteert op dit moment geen nieuwe post — onderhoud, overbelasting, of een volle schijf. Tijdelijk van aard.
Wat u eraan doet: Niets. Uw server probeert het vanzelf opnieuw.
Bron: RFC 3463
SPF, DKIM en DMARC
5.7.1 — Geweigerd op beleid van de ontvanger
Alle ontvangers
De verzamelcode voor "wij willen dit niet". Het kan gaan om een DMARC-afwijzing — de DMARC-standaard zelf geeft "550 5.7.1 Email rejected per DMARC policy" als voorbeeld — maar net zo goed om een filterregel van de ontvangende beheerder, een geblokkeerd bijlagetype of een blocklist. De code alleen zegt te weinig; de zin ernaast is bepalend.
Wat u eraan doet: Lees de tekst achter de code. Staat het woord DMARC erin, dan lijnt uw post niet uit met uw domein en begint u bij SPF en DKIM. Staat er een blocklist in, dan is dat het spoor. Staat er iets over beleid van de organisatie, dan kan alleen de beheerder van de ontvanger het oplossen.
Bron: RFC 9989 (DMARC)
5.7.23 — De SPF-controle is mislukt
Alle ontvangers
Het verzendende IP-adres mag volgens het SPF-record van uw domein geen post namens u versturen, en de ontvanger heeft besloten daarop te weigeren. Dit is de code die RFC 7372 hiervoor invoerde, in plaats van het algemenere 5.7.1.
Wat u eraan doet: Controleer of de server die deze post verstuurt in uw SPF-record staat. Is er een dienst bijgekomen — een boekhoudpakket, een nieuwsbrieftool, een webformulier — dan is dat meestal de oorzaak. Wordt de post doorgestuurd, dan is SPF de verkeerde plek om te zoeken.
Bron: RFC 7372
5.7.24 — Uw SPF-record zelf is stuk
Alle ontvangers
Niet "dit IP-adres mag niet", maar "wij konden uw SPF-record niet verwerken". De bekendste oorzaak is het lookupbudget: SPF staat tien DNS-opzoekingen toe, geteld over de hele keten van includes, en daarboven geeft SPF permerror. Dan krijgt niets meer een pass, ook uw eigen mailserver niet. De fout treedt op bij het versturen, niet bij het publiceren, dus u ziet hem niet aan het record zelf. Ook twee SPF-records op één domein geeft deze fout.
Wat u eraan doet: Tel de lookups van uw hele include-keten, niet het aantal includes in uw record — één include kan er drie kosten. Schrap diensten die u niet meer gebruikt en haal overbodige mx- en ptr-mechanismen weg. Onze SPF-controleur resolvet de keten en geeft het echte getal.
Bron: RFC 7208 (SPF)
5.7.25 — Het verzendende IP-adres heeft geen kloppende reverse DNS
Alle ontvangers
De ontvanger heeft opgezocht welke naam bij uw IP-adres hoort en kreeg geen antwoord, of een naam die niet naar hetzelfde IP-adres terugwijst. Beide richtingen moeten kloppen, en daar gaat het meestal mis: de PTR is wel gezet, maar de A- of AAAA-record van die naam wijst ergens anders heen. Google en Microsoft eisen dit allebei.
Wat u eraan doet: Vraag uw hoster of netwerkbeheerder om een PTR-record op het verzendende IP-adres, en zorg dat de naam die daar staat via een A- of AAAA-record terugwijst naar precies dat adres. Dit kunt u niet zelf in uw DNS regelen: de PTR hoort bij de eigenaar van het IP-blok.
Bron: RFC 7372
5.7.26 — Meerdere authenticatiecontroles zijn mislukt
Alle ontvangers
Zowel SPF als DKIM kwam er niet doorheen. RFC 7372 schrijft voor dat een ontvanger in dat geval déze code teruggeeft en niet die van de eerste de beste mislukte controle. In de praktijk is dit dus de code van een DMARC-afwijzing: DMARC faalt precies wanneer geen van beide uitlijnt met uw From-domein.
Wat u eraan doet: Begin bij DKIM, want die overleeft doorsturen en SPF niet. Controleer daarna of uw SPF-record de verzendende server dekt, en of het domein in het zichtbare afzenderadres hetzelfde is als het domein dat ondertekent.
Bron: RFC 7372
5.7.26 — Gmail accepteert uw post niet als niet-geauthenticeerd
Gmail en Google Workspace
Google gebruikt deze code voor drie verschillende situaties, en dat onderscheid bepaalt wat u moet doen. Staat er "the sender is unauthenticated", dan ontbreken SPF én DKIM allebei. Staat er iets over "a hard fail policy (-all)", dan publiceert u -all terwijl het verzendende IP-adres niet in uw SPF-record staat — dit is de klassieke doorstuurbreker. Staat er "not accepted due to domain's DMARC policy", dan publiceert het From-domein p=reject of p=quarantine en lijnt er niets uit.
Wat u eraan doet: Lees welke van de drie zinnen er staat. Bij de eerste: zet minstens SPF of DKIM aan, en als u bulk verstuurt allebei. Bij de tweede: vul uw SPF-record aan of ga na of de post wordt doorgestuurd. Bij de derde: zorg dat DKIM heel blijft en dat het ondertekenende domein bij uw From-adres past.
5.7.27 — De afzender publiceert een null MX
Alle ontvangers
Volgens RFC 7505 betekent deze code dat het domein in het afzenderadres bewust geen post ontvangt, en dat de ontvanger daarom weigert — hij zou een onbestelbaarmelding nergens naartoe kunnen sturen.
Wat u eraan doet: Verstuur post vanaf een domein dat ook post kan ontvangen. Een afzenderadres waarop niet geantwoord kan worden is sowieso een slecht idee.
Bron: RFC 7505
5.7.27 — Gmail zegt hiermee dat SPF niet slaagde
Gmail en Google Workspace
Let op: Google gebruikt deze code anders dan de standaard. In de officiële registratie betekent 5.7.27 dat de afzender een null MX heeft, maar in Google's eigen codelijst staat hij voor een mislukte SPF-controle bij bulkverzenders. Wie op codenummers filtert, komt hier dus bedrogen uit. Google doet dit vaker: ook 5.7.30, 5.7.32 en 5.7.40 hebben bij hen een eigen betekenis.
Wat u eraan doet: Behandel dit als een SPF-probleem: staat de verzendende server in uw SPF-record, en klopt dat record nog? Ga niet op zoek naar een null MX.
5.7.30 — Gmail zegt hiermee dat DKIM niet slaagde
Gmail en Google Workspace
Ook hier wijkt Google af van de registratie, waarin 5.7.30 over een TLS-eis gaat. In Google's codelijst staat de code voor post die de DKIM-controle niet haalde. Bij doorgestuurde post is de oorzaak bijna altijd dat het bericht onderweg is gewijzigd.
Wat u eraan doet: Controleer of de DKIM-sleutel in uw DNS overeenkomt met de sleutel waarmee wordt ondertekend, en of er onderweg iets aan het bericht verandert: een voettekst, een aangepast onderwerp of een scanner die de inhoud opnieuw codeert breekt de handtekening.
5.7.40 — Uw domein heeft geen bruikbaar DMARC-record
Gmail en Google Workspace
Google eist van verzenders van grote hoeveelheden post dat het verzendende domein een DMARC-record heeft. Er staat er geen, of er staat er wel een maar zonder beleid. De eis is niet zwaar: p=none volstaat om eraan te voldoen.
Wat u eraan doet: Zet een DMARC-record neer op _dmarc bij uw domein, om te beginnen met p=none en een rua-adres zodat u rapporten krijgt. Verscherp pas naar quarantine of reject als uit die rapporten blijkt dat al uw echte post uitlijnt.
5.7.509 — Microsoft weigert op uw DMARC-beleid
Outlook.com en Microsoft 365
De onbestelbaarmelding zegt letterlijk dat het verzendende domein niet door de DMARC-controle komt terwijl dat domein p=reject publiceert. Microsoft doet dus precies wat u zelf heeft gevraagd. Dit is een eigen code van Microsoft die niet in de officiële registratie staat.
Wat u eraan doet: Dit is bijna altijd een verzender van uzelf die u vergeten was: een boekhoudpakket, een CRM of een webformulier dat namens uw domein verstuurt zonder te ondertekenen. Zet uw beleid niet terug naar none, maar zoek de verzender op in uw DMARC-rapporten en richt DKIM voor die dienst in.
4.7.26 — Microsoft eist authenticatie bij verzenden over IPv6
Outlook.com en Microsoft 365
Microsoft stelt aan post over IPv6 strengere eisen dan aan post over IPv4: het bericht moet door SPF óf DKIM komen, anders wordt het uitgesteld. De bijbehorende variant 4.7.25 gaat over het ontbreken van een reverse DNS-record op het IPv6-adres.
Wat u eraan doet: Richt SPF en DKIM in voor de verzendende server, en zorg dat het IPv6-adres een PTR-record heeft. Kan dat niet op korte termijn, dan is post over IPv4 versturen een werkbare tussenoplossing.
5.7.515 — Outlook.com eist SPF, DKIM én DMARC van u
Outlook.com en Microsoft 365
Sinds 5 mei 2025 stelt Microsoft dezelfde eis als Google en Yahoo, maar dan voor outlook.com, hotmail.com en live.com: verstuurt u vanaf één domein vijfduizend berichten of meer per dag naar die adressen, dan moeten SPF, DKIM én DMARC alle drie in orde zijn. Voor DMARC volstaat p=none. Microsoft plaatst niet-voldoende post eerst in de ongewenste map en weigert hem daarna met deze code; wanneer weigeren de standaard wordt, heeft Microsoft niet aangekondigd. Let op: dit geldt alleen voor consumentenadressen, niet voor zakelijke Microsoft 365-domeinen. En een plek op de lijst met veilige afzenders van de ontvanger helpt hier niet — Microsoft zegt uitdrukkelijk die niet te honoreren.
Wat u eraan doet: Richt alle drie in en let vooral op uitlijning: het domein in uw zichtbare afzenderadres moet passen bij het domein dat SPF of DKIM oplevert. Krijgt u deze code terwijl uw authenticatie klopt, kijk dan of de post onderweg wordt doorgestuurd — Microsoft beoordeelt bij de laatste stap, en juist daar breekt doorsturen de controle.
5.7.506 — Uw server stelt zich verkeerd voor
Outlook.com en Microsoft 365
Microsoft noemt dit "Bad HELO": uw mailserver stelt zich bij het begin van het gesprek voor met de naam van de server die hij bélt, in plaats van met zijn eigen volledige naam. Microsoft staat dat niet toe en noemt het kenmerkend gedrag voor spambots. Het is een configuratiefout die verder niets met uw reputatie te maken heeft.
Wat u eraan doet: Zet in uw mailserver de HELO- of EHLO-naam op de eigen volledige domeinnaam van die server, en zorg dat die naam ook als reverse DNS op het verzendende IP-adres staat.
5.7.29 — De ARC-keten kwam er niet doorheen
Alle ontvangers
ARC legt vast wat het authenticatieresultaat was vóórdat een tussenpartij het bericht doorgaf. Deze code betekent dat die keten niet klopte. Belangrijker dan de code is de context: ARC is een experiment gebleven, wordt in de praktijk alleen gehonoreerd op basis van handmatige vertrouwenslijsten, en de IETF-werkgroep werkt sinds april 2026 aan een voorstel om het als Historic te classificeren.
Wat u eraan doet: Bouw geen bezorgstrategie op ARC. Zorg dat DKIM heel blijft; dat is wat doorsturen wél overleeft.
Reputatie en blocklists
5.7.28 — Gmail weigert u permanent op reputatie
Gmail en Google Workspace
De permanente tegenhanger van het tijdelijke afknijpen: Google ziet een ongewone hoeveelheid ongevraagde post vanaf uw IP-adres en neemt niets meer aan. Dit komt zelden uit de lucht vallen — er zijn vrijwel altijd eerst tijdelijke meldingen geweest.
Wat u eraan doet: Zoek uit wat er vanaf uw adres wordt verstuurd dat u niet kent. Een gekaapt mailaccount of een lek contactformulier op een website zijn de twee gebruikelijke oorzaken. Los dat op voordat u aan herstel begint; zolang de bron loopt, komt u er niet vanaf.
5.7.511 — Microsoft heeft uw IP-adres geblokkeerd
Outlook.com en Microsoft 365
Niet uw account maar het verzendende IP-adres staat op Microsofts blokkeerlijst. Belangrijk detail: dit is de enige Microsoft-blokkade die u níet via het gewone delistportaal kunt opheffen. Microsoft zegt dat met zoveel woorden.
Wat u eraan doet: Stuur de volledige onbestelbaarmelding, inclusief de code en het IP-adres, naar delist@microsoft.com. Microsoft zegt binnen 48 uur te reageren. Los eerst op wat de blokkade veroorzaakte, want anders komt u er direct weer op.
5.7.708 — Microsoft neemt geen post aan van dit IP-adres
Outlook.com en Microsoft 365
Let op de richting: deze code gaat over post die vanúit een Microsoft 365-omgeving wordt verstuurd, niet over post die u naar Microsoft stuurt. Microsoft heeft de verzendmogelijkheid van die omgeving beperkt omdat het uitgaande verkeer als verdacht wordt gezien. Het treft opvallend vaak nieuwe omgevingen, bijvoorbeeld tijdens een proefperiode, waar de reputatie nog door niemand is opgebouwd.
Wat u eraan doet: Ga eerst na of er misbruik in het spel is: een gekaapt account of een server die als open relay wordt gebruikt is de gebruikelijke oorzaak, en zolang die loopt heeft aanmelden geen zin. Is dat uitgesloten en zit u in een proefperiode, dan verwijst Microsoft naar hun ondersteuning voor een uitzondering totdat er licenties zijn toegekend.
5.3.2 — Het systeem neemt geen post van u aan
Alle ontvangers
Het ontvangende systeem weigert de verbinding voor uw post. In de praktijk ziet u deze code vooral bij systemen die op basis van een blocklist of een eigen regel besloten hebben niet met u te praten.
Wat u eraan doet: Controleer of uw verzendende IP-adres op een blocklist staat. Spamhaus, Barracuda en SpamCop zijn de lijsten die er in de praktijk toe doen; verwijdering is bij alle drie gratis.
Bron: RFC 3463
Kenmerken die providers erbij zetten
Naast de statuscode zet een provider vaak een eigen kenmerk in de melding. Dat kenmerk is
meestal preciezer dan de code zelf: 5.2.1 zegt alleen iets over de mailbox,
ReceivingRatePerm zegt wat er werkelijk aan de hand is.
ReceivingRatePerm — De ontvanger krijgt op dit moment te veel post
Gmail en Google Workspace
Dit is een limiet aan de kant van de ontvanger, niet aan die van u. De mailbox waar u naartoe schrijft krijgt zoveel post binnen dat Gmail verdere aflevering afknijpt. Uw eigen instellingen kunnen volledig in orde zijn. Google publiceert geen grens waarboven dit gebeurt, dus elk getal dat u erover leest komt niet van Google. Ziet u dit in golven bij één ontvanger, houd er dan rekening mee dat die persoon wordt volgelopen: een aanvaller die iemand op honderden nieuwsbrieven inschrijft om een echte melding te verbergen, levert precies dit beeld op.
Wat u eraan doet: Aan de verzendkant valt de limiet niet op te heffen; er is geen formulier en geen quotumverhoging. Wat wel helpt: laat uw mailserver deze melding als tijdelijk behandelen en het later opnieuw proberen in plaats van meteen een bounce te sturen, en spreid het volume naar dat ene adres. Is het dringend, bereik de ontvanger dan een andere keer of langs een andere weg — dat is ook wat Google zelf adviseert.
TSS04 — Yahoo stelt uw post tijdelijk uit
Yahoo en AOL
Yahoo houdt uw post even tegen wegens "unexpected volume or user complaints". Die twee worden bewust op één hoop gegooid: het is één reputatiesignaal en geen aparte teller, dus u kunt uit de melding niet afleiden of het aan uw volume of aan klachten ligt. Yahoo publiceert geen betekenis per codenummer — dezelfde zin hoort ook bij [TS01]. Wie u een exacte definitie van TSS04 geeft, heeft die niet van Yahoo. Let op dat dit een 4-code is: de post staat nog in uw wachtrij en wordt vanzelf opnieuw aangeboden.
Wat u eraan doet: Pauzeer bulk- en nieuwsbriefmail naar Yahoo- en AOL-adressen en laat gewone post gewoon lopen. Ga niet handmatig de wachtrij forceren: dat maakt het patroon juist verdachter. Zoek ondertussen uit waar het volume vandaan komt — bij een gedeelde server kan één gekaapt account het hele IP-adres raken. Meld u aan voor Yahoo's Complaint Feedback Loop, dan ziet u wie er klaagt; dat vereist wel dat u DKIM ondertekent.
BL21 — Yahoo weigert u omdat u bij Spamhaus staat
Yahoo en AOL
Yahoo raadpleegt Spamhaus rechtstreeks en zegt dat ook met zoveel woorden. Uw verzendende IP-adres staat op de Spamhaus-blocklist, en zolang dat zo is weigert Yahoo de verbinding. Dit is dus geen oordeel van Yahoo over uw post maar een doorgegeven oordeel.
Wat u eraan doet: Zoek het IP-adres op via check.spamhaus.org. Los eerst de oorzaak op — meestal een gekaapt account of een besmette machine — en vraag daarna pas verwijdering aan. Verwijdering is altijd gratis; partijen die u geld vragen voor een Spamhaus-delisting verkopen u lucht.
BL23 — Yahoo weigert u omdat u op de Spamhaus XBL staat
Yahoo en AOL
De XBL is de lijst van machines die tekenen van besmetting vertonen: malware, een misbruikte proxy, of post die met gestolen inloggegevens wordt verstuurd. Anders dan een gewone spamnotering zegt dit dat er waarschijnlijk iets mis is met de machine zelf.
Wat u eraan doet: Behandel dit als een beveiligingsincident en niet als een bezorgprobleem. Zoek de bron op de server, sluit die af, wijzig de betrokken wachtwoorden, en vraag daarna verwijdering aan via check.spamhaus.org. De XBL-notering vervalt vanzelf zodra het gedrag stopt.
S3150 — Outlook.com blokkeert het netwerk waar uw server in staat
Outlook.com en Microsoft 365
De melding zegt letterlijk dat "part of their network" op de blokkeerlijst staat. Dat is precies het probleem: de blokkade zit vaak niet op uw eigen adres maar op het blok eromheen, en dan is een buur de oorzaak. Microsoft legt deze codes nergens uit. De foutmelding verwijst naar een pagina die de code niet behandelt, en het verschil tussen S3140 en S3150 is door Microsoft nooit gedocumenteerd — wie u dat verschil uitlegt, heeft het niet van Microsoft. De tekst van beide codes is verder woordelijk gelijk.
Wat u eraan doet: Dien een melding in via olcsupport.office.com; dat is het loket voor Outlook.com, en niet sender.office.com — dat portaal gaat alleen over zakelijke Microsoft 365-postbussen. Meld u daarnaast aan voor SNDS om te zien wat Microsoft van uw adres vindt. Staat u op een gedeeld IP-adres, dan is uw hoster aan zet: alleen de eigenaar van het IP-blok kan zich voor SNDS aanmelden.
S3140 — Outlook.com blokkeert het netwerk waar uw server in staat
Outlook.com en Microsoft 365
Dezelfde melding als S3150, woord voor woord, met een ander nummer erachter. Microsoft heeft nooit gepubliceerd wat het verschil tussen beide is. Wat u eraan heeft: het gaat om een blokkade op netwerkniveau, niet om een oordeel over dit ene bericht.
Wat u eraan doet: Dien een melding in via olcsupport.office.com en meld het IP-blok aan voor SNDS. Staat u op gedeelde hosting, dan moet uw hoster dat doen — de aanmelding verloopt via de reverse DNS of de RIPE-registratie van het blok, en die staat op zijn naam.
Dit bericht is doorgestuurd, en dat verklaart veel
Alle ontvangers
In de melding staat een ander oorspronkelijk adres dan het adres waaraan is afgeleverd, of een adres dat met SRS0= begint. Er is dus doorgestuurd, en dat is de meest onderschatte oorzaak van bezorgproblemen. Drie dingen gaan bij doorsturen tegelijk mis. SPF klopt niet meer, want de doorstuurserver staat niet in het SPF-record van de oorspronkelijke afzender; SRS repareert dat, maar daarmee lijnt SPF uit op úw domein en niet meer op het From-domein, zodat DMARC volledig op DKIM leunt. DKIM breekt zodra de post onderweg wordt gewijzigd — een voettekst, een [SPAM]-markering in het onderwerp, herschreven links of een virusscanner die opnieuw codeert, is elk genoeg. En de klachten komen bij u terecht: markeert de ontvanger doorgestuurde rommel als spam, dan telt dat tegen uw server.
Wat u eraan doet: Filter spam vóórdat u doorstuurt in plaats van erna, en wijzig het bericht onderweg niet. Weeg af of doorsturen wel de juiste oplossing is: laat de ontvangende partij de post ophalen via IMAP of POP, dan is er geen doorstuurserver die reputatie en bounces erft. ARC wordt hier vaak als oplossing genoemd, maar honoreren gebeurt in de praktijk alleen op basis van handmatige vertrouwenslijsten, en de IETF-werkgroep werkt sinds april 2026 aan een voorstel om ARC als Historic te classificeren. Reken er dus niet op.
Wat een bouncemelding eigenlijk is
Een bounce is geen foutmelding van uw eigen mailprogramma maar een apart bericht, opgesteld
volgens een standaard (RFC 3464). Daarin staat één veld dat alles bepaalt: de action.
Staat die op failed, dan heeft uw server het opgegeven. Staat die op
delayed, dan is dit een tussenbericht en staat uw post nog in de wachtrij — dan
hoeft u niets opnieuw te versturen, en dat is precies wat de meeste mensen toch doen.
Daarnaast staan er twee codes in, en die worden vaak door elkaar gehaald. De klassieke
SMTP-code is het getal van drie cijfers (550, 421). De enhanced status
code is de code met punten (5.7.26). Die tweede vervangt de eerste niet maar staat
ernaast, en is fijnmaziger. Het eerste cijfer van beide komt overeen.
Een regel uit uw maillog lezen
Draait u zelf Postfix, of kijkt uw hoster met u mee in het log, dan ziet u niet de nette bouncemail maar een regel als deze:
postfix/smtp[2418674]: A1B2C3: to=<iemand@example.com>,
orig_to=<SRS0=fGp0=FY=voorbeeld.nl=info@uwdomein.nl>,
relay=smtp.google.com[2a00:1450:4025:402::1a]:25,
delay=0.2, delays=0.13/0/0.06/0.01,
dsn=5.2.1, status=bounced (host smtp.google.com said: 550-5.2.1 ...)| Veld | Wat het betekent |
|---|---|
smtp[2418674] |
De uitgaande SMTP-client van Postfix, met procesnummer. Let op het verschil met
smtpd: dat is de inkomende kant. |
A1B2C3 |
Het wachtrijnummer. Handig om alle regels van één bericht bij elkaar te zoeken, maar geen uniek kenmerk: Postfix hergebruikt deze nummers. |
to= |
Het uiteindelijke adres, ná alle aliassen en doorstuurregels. |
orig_to= |
Het oorspronkelijke adres, vóór die herschrijving. Staat dit veld er, dan is er onderweg iets omgezet — en dat is bijna altijd de sleutel tot het probleem. |
relay= |
Met welke server is gesproken, en op welk IP-adres en welke poort. |
delays= |
Vier tijden: vóór de wachtrij, in de wachtrij, verbinding opzetten (DNS, TCP, TLS) en het versturen zelf. Een groot derde getal wijst op een traag of onbereikbaar doel. |
dsn= |
De statuscode. Dit is het veld waar u op zoekt. |
status= |
sent, deferred (blijft in de wachtrij),
bounced (opgegeven) of expired (de wachttijd is
verstreken). |
Eén verwarrend punt: het woord deferred komt van Postfix zelf en niet van de ontvangende partij. Een Yahoo-melding die "temporarily deferred" zegt is dus niet hetzelfde veld — de statuswaarde staat los van de tekst die de andere kant terugstuurde.
4 of 5: dat is de enige vraag die u eerst moet beantwoorden
Bij een 4 hoeft u niets te doen. Uw server houdt het bericht vast en probeert het vanzelf opnieuw, met steeds langere tussenpozen. Een standaard Postfix geeft het na vijf dagen op; pas dan krijgt u een echte bounce. Handmatig de wachtrij forceren helpt niet en werkt bij afknijpen op reputatie zelfs averechts, want u maakt het patroon juist verdachter.
Bij een 5 is er iets veranderd nodig: aan het bericht, aan het adres of aan uw instellingen. Opnieuw versturen zonder wijziging levert precies dezelfde weigering op. Blijven schrijven naar adressen die permanent weigeren is bovendien schadelijk — het is voor ontvangende partijen een direct signaal dat u uw lijst niet bijhoudt.
De uitzondering die u een keer tegenkomt: een 5 waarvan de oorzaak tijdelijk
is. 5.2.1 met ReceivingRatePerm van Gmail is er zo een — de code is permanent,
maar morgen kan het bericht er wél doorheen. En andersom kan een 4 alsnog in
een definitieve bounce eindigen als hij vijf dagen aanhoudt; dan ziet u
4.4.7 of status=expired.
Waar uw melding blijft
De tekst die u hierboven plakt wordt in deze pagina verwerkt en verlaat uw browser niet. Er zit geen formulier omheen en er wordt niets verstuurd; u kunt dat controleren in het netwerktabblad van uw browser. Dat is hier geen vinkje maar de reden dat de tool zo gebouwd is: in een bouncemelding staan e-mailadressen en IP-adressen van u en van derden, en dat zijn gegevens waarvan wij geen verwerker willen zijn.
Wat wél gebeurt: uw browser haalt deze pagina bij ons op, dus ons webserverlog bevat uw IP-adres. Dat is gewone verwerking en staat in onze privacyverklaring.
Wat deze uitlegger niet doet
- Hij controleert niets. Hij leest de melding die u heeft en zoekt de code op; hij kijkt niet in uw DNS en test uw mailserver niet.
- Hij kent niet elke code. Providers verzinnen eigen nummers en documenteren die vaak niet. Staat uw code er niet bij, dan geeft de tool wel wat het eerste cijfer betekent.
- Hij heft geen blokkade op. Verwijdering van een blocklist of een providerblokkade vraagt u zelf aan bij die partij, en pas nadat de oorzaak is opgelost.
- Hij bewaart niets, dus er is ook geen geschiedenis. Wilt u een reeks meldingen over tijd volgen, dan heeft u het log van uw mailserver nodig.
Veelgestelde vragen
Mijn bericht kwam terug met 4.7.0. Moet ik het opnieuw versturen?
Nee. Een code die met 4 begint betekent dat de ontvanger het later opnieuw wil proberen, en uw mailserver doet dat vanzelf — een standaard Postfix vijf dagen lang. Opnieuw versturen levert een tweede exemplaar in dezelfde wachtrij op en versterkt bij afknijpen op reputatie juist het patroon waar de ontvanger op reageert.
Waarom krijg ik bounces terwijl mijn SPF, DKIM en DMARC in orde zijn?
Omdat lang niet elke weigering over authenticatie gaat. Reputatie van uw IP-adres, het volume dat u op dat moment verstuurt, klachten van ontvangers, een blocklist waar uw hoster op staat of simpelweg een volle mailbox aan de andere kant leveren allemaal bounces op. Kijk daarom eerst naar het tweede cijfer van de code: een 7 gaat over beleid en beveiliging, een 2 over de mailbox van de ontvanger.
Dezelfde code betekent bij Gmail iets anders dan in de standaard. Hoe kan dat?
Dat klopt en het is een bekend probleem. De officiële registratie kent 5.7.27 toe aan een afzender zonder ontvangende mailserver, maar Google gebruikt die code voor een mislukte SPF-controle. Hetzelfde geldt voor 5.7.30 en 5.7.40. Filtert u op codenummers, dan moet u dat per ontvangende partij doen; de zin naast de code is betrouwbaarder dan het nummer.
Gaat de melding die ik plak naar jullie servers?
Nee. De tekst wordt in uw browser verwerkt en er wordt geen bestand of formulier verstuurd; u kunt dat controleren in het netwerktabblad van uw browser. Wel bevat ons webserverlog uw IP-adres, zoals bij elk websitebezoek.
Ik zie steeds bounces van berichten die ik niet zelf heb verstuurd.
Dan gaat het om doorgestuurde post, of iemand gebruikt uw domeinnaam als afzender. Het verschil ziet u in uw DMARC-rapporten: doorgestuurde post komt in kleine aantallen met een geslaagde DKIM-controle, misbruik komt in pieken zonder DKIM en met falende SPF.