How do ESPs track delivery and bounce events?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
You hit send. Now what? Your ESP doesn't just fire off a message and hope for the best. It watches every step of the delivery attempt and records what happens. Here's how that actually works.
When your ESP sends a message, it opens an SMTP connection with the receiving mail server. That server responds with a three-digit code that tells your ESP exactly what happened. A 250 means the message was accepted. A 550 means the address doesn't exist. A 421 means the server is temporarily busy. Your ESP reads those codes and classifies the outcome automatically.
Those codes feed directly into bounce classification. A 5xx code (permanent failure) triggers a hard bounce. The address goes on your suppression list so you never send to it again. A 4xx code (temporary failure) triggers a soft bounce. The ESP typically retries delivery over the next 24 to 72 hours before giving up. This retry window is managed by a queue inside the ESP's MTA layer.
Everything gets logged. Each delivery attempt, each SMTP response code, each retry, each final outcome. That log becomes the source of truth for your campaign stats and your deliverability reports.
How do you access that data? Two main ways.
- Dashboard reporting is the easiest. Your ESP shows you delivered, bounced, and failed counts per campaign. Tools like Postmark and Twilio SendGrid go further and show you the raw SMTP response messages for individual addresses.
- Webhooks are the developer-friendly version. Your ESP fires a real-time POST request to your own server whenever a delivery event happens (delivered, bounced, complained, unsubscribed). You can use that to update your CRM, trigger alerts, or build custom suppression logic without waiting for a nightly report. Mailgun, Postmark, and Brevo all support webhook events out of the box.
One thing worth knowing: "delivered" in your ESP's dashboard means the receiving server accepted the message. It does not mean the message landed in the inbox. A server can accept a message and then route it to spam internally. That gap is why inbox placement is a separate metric from delivery rate.
If you're building on an ESP's API and want to make sure your bounce and event handling is set up correctly, our free Email Header Analyzer can help you read what the receiving server actually reported. Or drop a message on our SOS hotline if something isn't adding up.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
