Delivery event
A delivery event says a receiving mail server accepted the message. That is the end of the part you control. It is not proof anyone read the mail, and not proof it landed in the inbox rather than the spam folder. Delivery, bounces, complaints, opens and clicks together are the timeline of a message after it leaves your code.
At a glance
- Category
- Delivery
- Means
- The receiving server accepted the message
- Does not mean
- It reached the inbox, or that anybody read it
- Arrives
- On the message timeline, and on your webhook endpoints
- Followed by
- Opens, clicks, complaints — or nothing at all
How it works
Your send is queued, and a sending server opens a conversation with the receiving server named by the recipient domain's MX record. If that server answers with a success code after the message body, the message has been accepted and a delivery event is recorded. Everything afterwards happens inside the receiving organisation and is invisible to you: filtering, folder placement, forwarding rules. What you get instead are the later signals the reader or the provider chooses to generate.
Why it matters
Delivery is routinely mistaken for the inbox, and that mistake ruins reporting. A campaign can show ninety-nine per cent delivered and still be sitting in junk folders, because the receiving server accepted every message and then filed it. Knowing that delivery is an acceptance rather than a placement changes what you watch: complaints, replies and clicks tell you where the mail actually went, and a sudden fall in those with delivery unchanged is the classic shape of a filtering problem.
Example
A password reset is sent at ten past nine. The message timeline shows it queued, then delivered four seconds later. There is no open, because the customer's client blocks images, but there is a click on the reset link two minutes afterwards. The click is the proof the mail arrived somewhere the customer could see it; the delivery event only proved that the receiving server took it.
Common mistakes
- 01Reporting delivery rate as inbox rate, which hides a filtering problem behind a reassuring number.
- 02Treating a missing delivery event as a failure, when a deferral may still be in the retry window.
- 03Assuming the absence of later events means the mail was never seen, when image blocking and privacy proxies routinely suppress opens.
- 04Building an alerting rule on the delivery count alone, which stays perfectly flat through exactly the kind of filtering problem you wanted to be told about.
In Rasket
Every email keeps a timeline of its events, and the same events reach your webhook endpoints as they happen. Events
Related terms
Frequently asked questions
Can I tell whether a message reached the inbox?
Not from delivery alone. Folder placement happens inside the receiving organisation and is never reported back, so clicks, replies and complaint rate are the closest practical indicators.
How long after sending should delivery appear?
Usually within seconds. A longer gap normally means the receiving server deferred the message and it is being retried, which is ordinary and often resolves without any action.
What if there is no delivery and no bounce?
The message is most likely still in the retry window after a temporary refusal. If it stays that way, it will eventually be reported as failed with the last reply the receiving server gave.
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.