An enquiry has two lives. It is a stored record, and it is a message somebody hopes to read.
A setup that merges the two loses one of them. The first email provider outage decides which.
A failure timeline, minute by minute
Brightwater Dental, a fictional client, one missed appointment request.
14:02:11 visitor submits the form
14:02:11 the endpoint validates three fields
14:02:12 the response row commits, receipt id r_8f31
14:02:12 the page shows "thanks, we have your request"
14:02:12 a delivery row is written with state queued
14:02:13 the worker picks up the delivery row
14:02:14 the provider returns 202 accepted
14:02:14 delivery row state becomes provider_accepted
14:07:40 the practice manager says no email arrived
what is true at 14:07
- the request is stored and readable in the inbox
- the provider accepted one send
- nobody has evidence that a person received it
The only fact that matters at 14:07 is the third line from the top. The request exists, so nothing was lost while the notification was investigated.
What each state proves
| State | What it proves | What it does not prove |
|---|---|---|
| Saved | The response exists and can be read | That anybody was told |
| Queued | An attempt is waiting | That it will succeed |
| Accepted | The provider took the request | That it reached an inbox |
| Failed | The attempt ended with a recorded error | That the response is lost |
| Unknown | A request left and no answer came back | Anything. Never retry blindly |
The inbox rules, ready to copy
1. store the response before telling the visitor it worked
2. keep the notification in its own row, with its own state
3. show the stored response in an inbox a person opens daily
4. never delete a response because its notification failed
5. deduplicate a retry by the response id
6. read the state before retrying anything
7. record who was told, and when, after a retry
Acceptance: the setup is honest when
- a test submission returns a receipt id
- the response is visible in the inbox within a minute
- a failed delivery leaves the response readable
- a retry cannot create a second stored response
- the visitor confirmation never promises that a person has read it
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| No email, and no response in the inbox | The endpoint never stored it | Check the endpoint, then the origin rule |
| Response stored, no email | Delivery failed or went to spam | Read the delivery row, then retry if it never left |
| Two emails for one request | A retry duplicated a send | Deduplicate by response id |
| The client says spam | The sending domain has no authentication | Fix SPF and DKIM before blaming the form |
| Nobody checks the inbox | Alerts go to one person who is away | Add a second destination, or a shared mailbox |
Limits
Delivery is at least once, so a retry can repeat a notification. That is a reason to deduplicate on receipt, not a reason to skip retries.
Nothing here proves a person read a message. It proves the message was sent, which is a narrower and more useful claim.