Verify the domain, give each agent a send-only key with a ceiling, put an idempotency key on every send, and treat a held send as waiting rather than failed. That is the short version. The eight items below are the order of operations we recommend to the ecommerce brands we run paid social for, before an agent sends a single receipt.
The mail in scope is the mail a buyer expects after they do something: the receipt, the shipping notice, the password reset. It is not a newsletter, and it is not a list of people who have never bought. An agent changes the failure mode, not the purpose. The agent can retry, repeat, and keep going after a person would have stopped. The checklist is the set of controls that still hold when the sender is a job.
It is written as a checklist because a paragraph is easier to remember than to follow. The product details come from AgentiSend’s published documentation, because it documents a control for every item on the list on a public page.
The list
1. Verify the sending domain before any receipt leaves. Add the domain, read the records back, publish them at the registrar, and check them before the first real order. Two are the gate: the signing record, and the pair on a subdomain of your own domain that lets bounces come back. The record that authorises senders on the domain root and the policy record that asks receivers to report failures are both recommended, and a domain verifies and sends without either. Publish them anyway. If the root already carries a sender-authorisation record, merge the new one into it rather than adding a second. Two of those records on one name invalidate both.
2. One key per job. Receipts, shipping notices, and password resets do not share a key. Each key is scoped so that sending is all it can do: it cannot edit its own ceiling, and it cannot spend the password-reset key’s. A bug in the receipt job spends the receipt ceiling only.
3. Put the ceiling on the key before the agent receives the key. A count for the period, hourly, daily or monthly, and a per-minute rate beside it. The budget is checked before each send, not reported after it. The sample numbers on the public pages are examples, not recommendations: pick the counts from the store’s own order volume. What matters is the order: ceiling first, then the key leaves a person’s hands. A key that reaches an agent with no ceiling is the item this list exists to catch. The agent cannot raise the number afterwards. That is a person’s decision.
4. Send an idempotency key on every send. A timeout followed by a retry, without one, is how a buyer gets two receipts for one order. AgentiSend keeps the key for 7 days, so a job that re-runs the next morning still replays the first result instead of sending again. The loop guard is not a substitute for this. The published loop line is the fourth near-identical message to the same recipient inside 60 minutes, so the second copy can still go out. The idempotency key is what makes the retry the same send. The loop guard is what catches the job that ignored this item.
5. Read a held send as waiting. When that fourth copy trips the guard, the answer is approval_required. The public wording says the action requires human approval before it executes, and the fix tells a person to approve the pending action and then retry. retryable is false: a retry by the agent will not help, and resubmitting creates another held row. A person reads the subject, the first three recipients and the body, then approves or rejects. For the first month, that reader is a person and not another job.
6. Keep a stop that is one request. A person can pause one key, or every key on the account with POST /limits/kill-all, without a deploy. Nothing resumes on its own; only a person turns it back on. The case for it is the hour when the emails are different enough to miss the loop and few enough to miss the daily ceiling, and still wrong. Password resets are the key to stop first when unsure, because a delayed receipt is an annoyance and a spurious password reset is not.
7. Read the published lines before raising volume. Bounce rate warns at 2% and pauses at 4%. Complaint rate warns at 0.05% and pauses at 0.08%. Nothing automatic happens until the rolling window holds at least 100 delivered-or-bounced sends. Do not read a domain under those lines as “landing in the inbox.” The lines are when someone should look and when sending pauses. A domain with no history that sends fifty thousand messages on its first day is, on the public page, indistinguishable from a compromised one. That is why a new domain is raised slowly, whatever the store’s order volume.
8. Exercise the path before a customer address is in the recipient field. Addresses ending in @simulator.agentisend.com cost nothing, reach nobody, and work before a domain is verified. The onboarding address reaches the addresses your own team signs in with, 20 a day and no further. That is the right place to prove the loop trips the guard. Proving it against a buyer is how you spend the relationship the checklist is supposed to protect.
The honest negative
A checklist is not a setup. Writing these eight items down does not verify a domain, mint a key, or show that an agent handles approval_required without resubmitting. Each store has to do that work on its own account. The list also has a hole worth saying out loud: it does not check that the receipt is correct. A wrong total, sent once, passes every item here. The items stop a loop, a shared key, and a silent failure. They do not stop a bad sentence.
There is no price or volume target on this list, because both depend on the store. For a starting point, AgentiSend’s Free plan is 1,000 emails a month and 100 a day with no card.
The three steps the list starts from, domain, key, and send, are the quickstart. The product is at agentisend.com.