The Receipt the Provider Gave You
When a message is handed to a mail or messaging provider, the provider hands back an identifier — its receipt for the thing it just accepted. There is a place to keep that identifier and nothing puts anything in it, so our record of a message and theirs cannot be joined.
Somebody says they never received the notification. This is one of the most common disputes in any business system and it has exactly three possible answers: it was never sent, it was sent and never arrived, or it arrived and they missed it.
Telling those three apart requires two logs — yours and your provider's — and something to join them with.
What our side records, which is a lot
More than most, and it is worth setting out because the absence only makes sense against it. Every notification records which rule produced it, which record it was about, which template and which version of that template, the channel, the recipient, the subject, the body as sent, whether it was delivered, whether it was opened, and how many times it was retried.
It also records why a message was not sent, which is the half most systems skip. Before anything is attempted, five different things can happen: the recipient has muted this kind of notification; the same message already went inside a cooldown window and is suppressed as a duplicate; the channel is switched off for them; it is inside their quiet hours and is deferred with a stated end time; or they are on a daily or weekly digest and it is queued into that instead.
So "why did I not get it" has a real answer in a large number of cases, and the answer is often that the person asked not to.
Everything in that list describes our side of the handoff. The dispute is nearly always about the other side.
The receipt that is not kept
When you hand a message to a mail or messaging provider, it does not simply accept it. It gives you back an identifier — a reference for the thing it has taken responsibility for. Every provider does this and it exists for one purpose: so that later, when there is a question, you can quote the reference and they can tell you exactly what happened to that specific message.
There is a place in our record for that identifier. Nothing has ever written to it.
So the two logs sit side by side and cannot be joined. Ours says a message with that subject went to that address at that time. Theirs holds the full delivery history — accepted, relayed, deferred, bounced, rejected — indexed by an identifier we did not keep. Matching them means searching the provider's records by recipient and approximate time and hoping the business did not send that person three messages that hour.
Why the join is the thing that matters
Because the interesting failures all live at the far end, and they are invisible from ours.
| What happened | Our record shows | The provider knows | Joinable today |
|---|---|---|---|
| Recipient muted it | Suppressed, with the reason | — | Answered by us alone |
| Duplicate inside the cooldown | Suppressed, with the reason | — | Answered by us alone |
| Quiet hours | Deferred, with an end time | — | Answered by us alone |
| Provider rejected it | Sent | Rejected, with a reason | By recipient and time, roughly |
| Recipient's server bounced it | Sent | Bounced, with the server's reason | By recipient and time, roughly |
| Delivered to a spam folder | Sent | Delivered | By recipient and time, roughly |
Why this field is nearly always the empty one
Because of where it appears in the code. Everything else about a notification is known before the send: the rule, the recipient, the template, the preference, the content. It is all assembled in one place and written in one go.
The provider's reference is the only thing that comes back after, in the response to the send. Capturing it means taking that response, finding the record you just wrote, and updating it — a second step, in a different part of the code, for a value nothing needs today.
So it gets designed into the storage, where it costs nothing, and skipped in the sending, where it costs a little. And it is only ever wanted on the day somebody is disputing a message from four months ago, by which point the person who could have added it has moved on.
What to do while it is true
Three habits
- When somebody disputes a message, check our record first. In a good share of cases the answer is a mute, a quiet-hours deferral or a digest, and it is recorded with a reason — no provider needed.
- If our record says it was sent, search the provider by recipient and a narrow time window immediately. Provider retention is finite and usually shorter than the argument.
- Keep the notification reference from our side — the rule, the record and the exact time — in whatever ticket the dispute is in. It is the closest thing to a join key you have.
Three questions for anything that sends on your behalf
Do you keep the provider's reference for each message?
What you will hear
Often a pause.
How to read it
The single most useful field in any notification log and among the most commonly skipped, for the reason described above. A yes is worth confirming by asking to see one.
Can you tell me why a specific person did not receive a specific notification?
What you will hear
Sometimes a very good answer.
How to read it
A system that records suppressions, mutes and quiet hours answers most of these from its own data. That is a real strength and it is worth separating from the provider question.
How long is the delivery record kept, on both sides?
What you will hear
Rarely matched up.
How to read it
Ask for both numbers. If yours is a year and the provider's is thirty days, the join only exists for thirty days regardless of what is stored, and disputes rarely arrive that fast.
The short version
A notification log that records everything about your side of a send is answering the easy half of every delivery dispute. The hard half lives at the provider, and the only thing that reaches it is the reference the provider handed back when it accepted the message. It is one field, it is written once, and it is the difference between "our records show we sent it" and "here is exactly what happened to it". Go and look at whether yours is filled in.
What AWRA OpsHub does today
- A record per notification naming the rule, the record it concerned, the template and its version, the channel, the recipient, the subject and the body as sent.
- Five recorded reasons a message can be stopped before sending — muted by preference, duplicate inside a cooldown, channel disabled, deferred for quiet hours with an end time, or queued into a digest.
- Delivery and open timestamps, and a retry count, so a message that took several attempts is visible as such.
- Per-recipient notification preferences, including quiet hours and daily or weekly digests, honoured before anything is attempted.
- A daily digest of integration failures, so a channel that has stopped working reports itself.
More we can add to your workspace
- The provider's own reference kept against each message, so our record and the provider's can be joined when somebody disputes a delivery.
- Bounce and rejection outcomes fed back onto the delivery record, so the far end's verdict is visible from our side.
- A delivery-failure view by recipient, showing addresses that consistently fail rather than individual sends that did.
- Retention stated on the delivery record, alongside what the provider keeps, so the window in which a dispute can be answered is known.
Where we point you to a specialist
- Recording why a message was deliberately withheld stays as important as recording that one was sent, and we would keep that half however the rest develops. A person who muted a notification and then asks why they did not get it is the commonest case by a distance, and it deserves a definite answer.
- What your provider retains and for how long is governed by them and by your contract with them. We would keep the reference that makes their records reachable; we would not undertake to hold their delivery history on their behalf.
- We would decline to treat an open as proof a person read something. An open is a signal about an image being fetched, it is wrong in both directions routinely, and presenting it as proof of receipt would be handing you evidence that will not hold when it matters.
Keeping the provider reference, feeding bounce outcomes back, and a delivery-failure view by recipient are one piece of work we can scope and quote on.
Two, and the first is one field
The record already has the place for it. What is needed is the second step after a send, and the outcomes that flow back afterwards.
Keep the provider reference
Capture what the provider returns when it accepts a message and store it against the delivery. One field, written once, and it turns every future delivery dispute from a search into a lookup.
Feed the outcome back
Bounces, rejections and deferrals reported by the provider written onto the delivery they belong to — so the far end's verdict is visible from our side without anybody logging in to two systems.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If notifications to customers or suppliers are ever disputed in your business, the first item is the one to raise.
Talk to us about notificationsPick a message from last month
One a customer or a colleague received, and try to find out from your provider exactly what happened to it. If that takes more than a minute, the reference joining the two records is missing, and it is missing on every message you have ever sent.
Talk to us about message delivery