The useful question is not whether it was sent
A system can report success at its own boundary while the customer receives nothing. The gap only becomes visible when somebody asks about one message.
Sending from your apps
Transactional email from your own software, on your own domain.
Order confirmations, receipts and one-time codes leave automatically, paid for in blocks bought ahead and used up as your systems send.
Why this is the mail that matters
Nobody reads it before it goes, and nobody tells you when it does not arrive
When an order confirmation disappears, the customer assumes the order failed. The first warning is often a call about a payment they did not expect.
It is what you can find out afterwards
Keep the message’s reference, sender, outcome and refusal reason together. That is enough to answer a real question without claiming delivery.
So that is what the rest of this page is
The rest of this page follows one message through its checks, its record, and the answer returned to the software that handed it over.
One message, end to end
What happens after your software lets go
Each message carries its reference, passes the same ordered checks, and returns as taken or refused — with a reason your software can act on.
- Handed over, with your own reference
- Your software supplies a required reference. Retrying the same message keeps it one; changing the content under a used reference is refused.
- Checked in order, every time
- The account, sending switch, holds, rate and message limits are checked in that order on every message, then checked again immediately before it leaves.
- And if the counting itself fails, sending stops
- If the rate tally is unavailable, the message is refused. A hold placed on an account can only lower that rate, never raise it.
- Nothing goes out because a check was skipped
- A partial run cannot become permission to send. If one check is missing, the message stops.
- Taken is not delivered, and we do not blur the two
- Taken means we accepted responsibility for the message. It never claims that the recipient received it.
- Refused while you are still holding it
- A failed check returns a refusal immediately, naming the check and, where waiting is right, how long to wait.
- And when we genuinely cannot tell
- If the answer is lost after handover, the message is not sent again. Its unknown outcome remains until a person settles it.
The message leaves through machines we own, with no other mail platform in the path and nobody else to blame for its outage.
Whose name it goes out as
Having an address is not the same as being allowed to send from it
Every message is checked against the addresses its mailbox may use. Software cannot grant itself a trusted name at the top of an email.
Every message is checked against the addresses that mailbox is actually permitted to send as, and the permission has to have been proved rather than claimed. One that was never proved is not a permission. One that was given an end date stops on that date, instead of quietly outliving the reason it was granted.
Every way that check can fail comes back as the same answer, on purpose. A refusal that said which condition had failed would be a way for a stranger to work out which addresses your business has and which it does not, one guess at a time — so it is written so that it cannot be used that way.
Which matters more here than anywhere else in your mail. The address on an order confirmation is the one your customer replies to, marks as safe, and searches for next year when they want to know what they bought.
What is written down
The record kept for each message, and the part deliberately not kept
Enough to answer the question somebody will ask about one message in three weeks' time, and not one thing beyond that.
- The reference your own software gave it
- Kept exactly as supplied. Reusing it after a dropped connection remains the same message; using it for different content is refused rather than quietly sent twice.
- Which mailbox it left, and which address it went out as
- Both are kept, so a later question about the name at the top of the message has a direct answer.
- How far it got
- Taken, refused or not yet settled. “Taken” never quietly stands in for “delivered”.
- The reason, where there was one
- A refusal stays with the check that caused it, preserving the same answer your software received at the time.
- The moment we took responsibility for it
- Recorded to a fraction of a second, so two messages in the same minute still have an order.
- A fingerprint of the message, which nobody is ever shown
- A digest distinguishes different content under the same reference. The message and its subject are not kept in this record, and the digest is never displayed.
- And how long all of that is kept
- Kept for the configured retention period, except when the outcome is unknown. That record remains until a person has settled it.
When we will not take it
Refused while your software is still holding it
A direct refusal is a problem you can fix now. Accepting a message that will go nowhere creates a mystery the customer discovers first.
It names its own reason
The answer names the check that stopped the message and, when waiting is right, says how long to wait before trying again.
And it is never an accident of ordering
A partial run of checks cannot become permission to send. If one was skipped, the message stops rather than leaving through the gap.
What it costs, and what it needs
Bought in blocks, used up as you send
A block of five thousand messages, or a bigger one, bought before you need it and drawn down as your software sends. The rate is the same at every size — there is no discount for buying a big block and no penalty for buying a small one, so the size you choose is about how often you want to think about it rather than about price.
- 5,000 messages
- ₹100.00
- 25,000 messages
- ₹500.00
- 50,000 messages
- ₹1,000.00
That works out at the same two paise a message however much you buy, and a block is a purchase rather than a subscription: it is paid for once and carries no monthly charge. Whether an unused remainder expires is one of the open questions below. Prices exclude GST, which is added at 18%.
And it does not need anything else of ours
Not the business tools, not a website built by us, not anything but a name to send from. A business that buys nothing here except its sending is a customer in its own right, on the same footing as every other — not a lead for somebody to work on later.
How what is left is kept
A list, not a number
Each block is kept as an itemised record, so the balance can be explained line by line instead of merely stated.
Anywhere else, a balance is a figure kept somewhere with pieces taken off it. Ask why it says what it says, and the honest answer is only that it says so. The figure is the record — and a record with nothing behind it is a claim.
We do not keep that figure at all. What we keep is every line: the block you bought, and what has come off it since, with its date. The number you are shown is worked out from those lines at the moment you look, every time.
Which means it can be explained rather than merely stated. Nothing is summarised away once it gets old, and no part of the story is missing because somebody tidied up.
It also means a mistake cannot be quietly fixed. If something came off your balance that should not have, putting it back is a new line, with its own date and its own reason, sitting on the page beside the one it corrects. Both stay there. That is how every money record in this business is written — once, and never over — and it is not a setting anybody here can turn off.
Straight about this
What we have not settled
The block prices are settled. Expiry, part-used refunds, sending past the remainder and closing with something left still need explicit answers.
Does a block have a life?
Whether a block you have bought stays good indefinitely, or has a period attached to it, has not been decided. It is being settled now, and it will be written down plainly before anything can be bought.
You have used part of it and changed your mind.
What happens to the rest is undecided. It is the first thing anybody asks, which is exactly why a comfortable guess here would be worse than an open one — a guess is what people remember, and we would have to take it back.
Your software sends more than the block is holding.
Whether the sending stops until you buy another block, or carries on and is settled afterwards, is not decided. It is the one that would catch you out on a busy day, so it will be answered before anybody can buy.
And if the account closes with something left on it?
Also open, and on the same list as the rest. It is a decision about how we want to sell rather than anything waiting on software, so the honest answer today is that it has not been taken.
None of these is waiting on software. They are decisions about how we want to sell, and if one of them is the difference between this working for you and not, say so — that is the kind of thing that settles them.
Tell us what your systems send
Roughly what goes out, and what goes wrong for you when it does not — those two answers shape everything else, and they are a short conversation rather than a form to fill in. The published block prices are on the Email pricing page.