Een bounce lezen

Module 6: Bounces en problemen oplossen · Leestijd: 11 minuten

Leerdoel: Na deze les kun je een foutmelding over een niet afgeleverde mail (een bounce) ontleden: welke server de fout gaf, voor welk adres, wat de code betekent, en of het tijdelijk of definitief is.

Kernbegrippen: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, antwoordcode (RFC 5321), uitgebreide statuscode X.Y.Z (RFC 3463), uitstelbericht, backscatter

Wat is een bounce?

Kan een mailserver een mail niet afleveren, dan stuurt hij een bericht terug naar de afzender. Dat heet een bounce (of: non-delivery report, NDR). Hij komt van een afzender als Mailer-Daemon@..., MAILER-DAEMON of Mail Delivery System, met een onderwerp als:

• Mail delivery failed: returning message to sender
• Undelivered Mail Returned to Sender
• Delivery Status Notification (Failure)
• Warning: message ... delayed 24 hours (dit is geen bounce maar een uitstelbericht, zie verderop)

Veel mensen gooien zo'n bericht meteen weg, of schrikken van de Engelse tekst. Jammer, want een bounce vertelt bijna altijd precies wat er mis is. Je moet alleen weten waar je moet kijken.

Een bounce heeft altijd een lege envelope-afzender (Return-Path: <>). Dat is bewust: een bounce op een bounce zou anders een eindeloze lus kunnen geven (RFC 5321).

Wie heeft de mail geweigerd?

Een mail gaat langs minstens twee servers: die van jouw aanbieder en die van de ontvanger. Een bounce kan in twee situaties ontstaan:

1. De ontvangende server weigert de mail tijdens het SMTP-gesprek (les 1.2), bijvoorbeeld na RCPT TO (adres onbekend) of na de inhoud (spam of DMARC). Jouw eigen server krijgt die weigering en maakt er een bounce van voor jou. De fout komt dan van de ontvanger, de bounce van je eigen server.
2. Je eigen server geeft het op, bijvoorbeeld omdat de ontvanger dagenlang niet bereikbaar was, of omdat je zelf een limiet hebt bereikt.

Het onderscheid is belangrijk: in het eerste geval moet je weten wat de ontvanger niet beviel, in het tweede geval zit het probleem dichter bij huis.

Het leesbare deel

Bovenaan staat een tekst voor mensen. Die verschilt per mailsoftware, maar bevat bijna altijd dezelfde dingen:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pieter.devries@example.net
    host mx1.example.net [198.51.100.20]
    SMTP error from remote mail server after RCPT TO:<pieter.devries@example.net>:
    550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Lees het zo:

Het machinedeel: de DSN

Onder de tekst staat meestal een deel voor programma's, de delivery status notification (RFC 3464). Dat is altijd hetzelfde opgebouwd, wat het makkelijk leesbaar maakt:

Reporting-MTA: dns; mail.hosting.example

Action: failed
Final-Recipient: rfc822;pieter.devries@example.net
Status: 5.1.1
Remote-MTA: dns; mx1.example.net
Diagnostic-Code: smtp; 550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Helemaal onderaan staat de originele mail of alleen zijn kopregels. Daar zie je welke mail het was, en welk afzenderadres en welke Return-Path er gebruikt werden. Dat is soms de sleutel tot de oplossing (zie de DMARC-casus in de opdracht).

De codes lezen

Er zijn twee soorten codes, en meestal staan ze allebei in een bounce.

De antwoordcode (RFC 5321): drie cijfers, zoals 550 of 451. Het eerste cijfer is het belangrijkste:

De uitgebreide statuscode (RFC 3463): drie getallen met punten, zoals 5.1.1 of 4.7.500. Het eerste getal is weer 2, 4 of 5. Het tweede getal zegt waar het probleem zit:

Het derde getal is de precieze reden. Grote ontvangers gebruiken daar hun eigen nummers voor, zoals Gmail met 5.7.25 tot 5.7.30 en Microsoft met 4.7.500 en 5.7.509. Die staan in hun eigen documentatie (les 6.2).

Vuistregel: de code met een 5 aan het begin en een 7 in het midden (5.7.x) is bijna altijd een beleidskwestie: authenticatie, reputatie of spam. Daar helpt opnieuw versturen niet; je moet iets veranderen.

Uitgesteld is nog niet mislukt

Bij een tijdelijke fout (4xx) bewaart je server de mail en probeert hij het opnieuw. RFC 5321 raadt aan het minstens vier tot vijf dagen vol te houden, met minstens een half uur tussen de pogingen. Veel servers sturen na een paar uur of na een dag een uitstelbericht:

Action: delayed
Status: 4.7.500
Diagnostic-Code: smtp; 451 4.7.500 Server busy. Please try again later from [203.0.113.25].
Will-Retry-Until: Thu, 12 Nov 2026 08:58:40 +0100

Dat betekent: niet opnieuw versturen, de server probeert het zelf nog. Verstuur je het toch opnieuw, dan krijgt de ontvanger het straks misschien twee keer. Lukt het uiteindelijk niet voor Will-Retry-Until, dan komt alsnog een echte bounce, vaak met 4.4.7 (bericht verlopen in de wachtrij).

Nep-bounces: backscatter

Krijg je ineens tientallen bounces van mail die je nooit hebt verstuurd? Kijk dan in de originele mail onderaan. Staat daar een afzender van jouw domein, maar een server en tekst die je niet kent, dan heeft een spammer jouw adres als afzender gebruikt. De ontvangers sturen hun bounces naar jou. Dat heet backscatter.

Je mailbox is dan meestal niet gehackt (zie les 3.4 voor het verschil). Wat helpt: een DMARC-beleid dat stap voor stap strenger wordt (les 4.4), zodat ontvangers vervalste mail weigeren voordat er een bounce ontstaat. Kijk wel in je verzonden mail en bij je aanbieder of er echt niets van jouw mailbox is verstuurd.

In de praktijk: zo ziet het eruit

Bij WebOké zie je naast de bounce ook in E-mail Tracering in DirectAdmin wat de server met een bericht deed: Geleverd, Uitgesteld of Mislukt, met het antwoord van de ontvangende server. Andere panelen hebben vaak een vergelijkbaar maillog of "berichtspoor"; bij Microsoft 365 heet het bijvoorbeeld berichttracering. Het is handig om eerst daar te kijken als je geen bounce hebt, of als iemand zegt dat je mail niet aankwam.

Samenvatting

• Een bounce komt van Mailer-Daemon en heeft een lege Return-Path. Lees hem, hij vertelt meestal precies wat er mis is.
• Kijk eerst wie de fout gaf (SMTP error from remote mail server = de ontvanger) en voor welk adres.
• In het machinedeel: Action, Status, Remote-MTA en vooral Diagnostic-Code.
• Eerste cijfer: 4 = tijdelijk, 5 = definitief. Tweede getal: 1 adres, 2 mailbox, 3 systeem, 4 route, 5 protocol, 6 inhoud, 7 beleid.
• Uitstelbericht (delayed): niet opnieuw versturen. Bounces van mail die je niet verstuurde: backscatter.

Quiz

Opdracht

Opdracht Z6.1: Drie bounces ontleden. Je krijgt drie voorbeeldbounces (bounce-1.txt, bounce-2.txt en bounce-3.txt). Vul per bounce in: het adres waarvoor het misging, de server die de fout gaf (Remote-MTA), de statuscode, of het tijdelijk of definitief is, en wat de afzender moet doen (kies uit een lijst). Het programma kijkt na met een vaste sleutel en geeft per veld uitleg.

Verder lezen

De stappen in deze artikelen gelden voor de panelen van WebOké; bij andere aanbieders werkt het vergelijkbaar.

• Mail delivery failed: zo lees je de foutmelding en wat de codes betekenen
• Foutmelding: 550 5.5.0 Requested action not taken: mailbox unavailable
• Controleren of een e-mail is aangekomen met E-mail Tracering
• DirectAdmin handleiding 9.3: E-mail Tracering: waar is mijn mail gebleven?
• RFC 3464 (opbouw van een DSN), RFC 3463 (uitgebreide statuscodes), RFC 5321 paragraaf 4.2 (antwoordcodes) en 4.5.4.1 (opnieuw proberen)