SendGrid "Delivered" maar e-mail niet ontvangen
Ontwikkelaars stoten soms op situaties waarbij SendGrid een bericht als delivered rapporteert, maar de ontvanger de e-mail nooit ontvangt.
Dit is een bekende beperking van hoe de meeste e-mail-API's bezorgingsstatus rapporteren.
Waarom dit gebeurt
E-mail-API's die 202 Accepted of "delivered" terugsturen, geven aan dat de transportlaag het bericht heeft geaccepteerd voor verwerking — niet dat het de inbox heeft bereikt.
Na acceptatie kan de ontvangende mailserver het bericht nog steeds:
- Weigeren vanwege een volle mailbox
- Filteren naar spam
- Weigeren op basis van domeinreputatie
- Uren later een uitgestelde bounce terugsturen
Veel API's tonen deze uitkomsten asynchroon — of helemaal niet.
Wat "delivered" meestal betekent
Bij de meeste e-mail-API's betekent delivered of accepted:
Het bericht is ingediend bij de transportinfrastructuur.
Het betekent niet dat de mailbox van de ontvanger het bericht heeft geaccepteerd.
De volledige bezorgingsflow
- Je API-aanroep geeft
202 Acceptedterug - Provider dient in bij SMTP-transport
- Transport geeft door aan de mailserver van de ontvanger
- Server van de ontvanger accepteert of weigert
- Je applicatie wordt al dan niet op de hoogte gesteld
Stappen 4 en 5 zijn waar stille mislukkingen plaatsvinden.
Veelvoorkomende scenario's
| Scenario | Wat er gebeurt | Wat je ziet |
|---|---|---|
| Mailbox vol | Server weigert na acceptatie | "Delivered" of geen event |
| Spamfilter | Bericht stilletjes verwijderd | "Delivered" |
| Adres bestaat niet | Bounce uren later ontvangen | Vertraagde webhook of stilte |
| Domeinreputatieblok | Beleidsafwijzing | "Delivered" van transport |
Deterministische bezorgingsstatus
Truncus lost terminale bezorgingsstatus op en stelt deze direct beschikbaar in de API-response.
{ "status": "bounced", "reason": "mailbox_full" }
{ "status": "rejected", "reason": "spam_blocked" }
Je applicatie ontvangt de werkelijke uitkomst — niet de transportacceptatiestatus.
Waarom dit belangrijk is voor bepaalde e-mailtypes
Stille bezorgingsfouten zijn vooral problematisch voor:
- Wachtwoordresets — gebruiker wacht op e-mail die nooit arriveert
- Facturen en bonnen — betaling niet bevestigd
- Beveiligingswaarschuwingen — kritieke melding gemist
- Multi-tenant platforms — je kunt je eigen fout niet onderscheiden van het ongeldige adres van een klant
Systemen die moeten weten of de e-mail is ontvangen, hebben terminale bezorgingsstatus nodig — geen transportacceptatie.