Safe outreach starts with clear boundaries
A practical guide to send limits, suppression, review and stop controls before a cold outreach workflow sends its first message.
Cold outreach becomes risky when its limits live only in a spreadsheet or in someone's memory. A sending workflow needs boundaries the system can check before it claims work. The goal is simple: every send should have an approved reason, an available mailbox, and a clear way to stop.
Put the limit next to the action
A daily limit is most useful at the point where a message is claimed for sending. That is where the system can consider the mailbox, its domain, recent activity, and the campaign together. A dashboard can describe a limit, but it cannot enforce one if workers are free to reserve messages elsewhere.
The boundary should answer a small set of questions in a predictable order. Is this mailbox allowed to send? Is capacity still available? Has the contact been suppressed? Is the approved campaign revision still current? If any answer is no, the worker should stop before it reserves or sends anything.
Terlido uses one send budget for warmup and campaign traffic. This prevents two parts of the product from treating the same mailbox capacity as if it belonged to each of them. The deliverability overview explains how authentication, mailbox age, and recent results fit into that boundary.
Keep suppression outside the campaign
An unsubscribe or suppression record should apply before campaign logic. If suppression belongs only to one campaign, a copied contact, a retried job, or a later campaign can bypass the original decision. Keeping that decision at a shared boundary makes the outcome consistent across sending paths.
Suppression checks should also happen close to the send. A contact can be eligible when a sequence is prepared and become ineligible before its next step is due. Rechecking at claim time avoids relying on an old snapshot. It also gives the audit record a clear explanation for why a planned message did not send.
This is why a stop control matters. A pause should prevent the next claim, rather than changing a label after more work has already been queued. Operators need to know where the stop takes effect and whether any already claimed work can still complete.
Make approvals specific
Approval works better when it identifies the exact thing being approved. A campaign name is not enough if the subject, body, recipients, or schedule can change later. Bind approval to a revision, and require another review when that revision changes in a meaningful way.
That does not mean every harmless edit needs ceremony. It means the system needs an explicit rule. Copy changes that affect what recipients see, audience changes that affect who can be contacted, and schedule changes that affect timing should not inherit approval by accident.
An agent can help prepare outreach without receiving unlimited authority. Narrow permissions, a revision tied to the approved campaign, and an audit record for each action make its work reviewable. Terlido's AI agents page describes the current MCP surface and its approval boundaries.
Record decisions people can inspect
An audit trail should describe decisions, not dump private message content. Useful records include the action, the approved revision, the mailbox boundary that was checked, and the result. Secrets, email bodies, and unnecessary recipient details do not belong in routine operational logs.
Clear records help with ordinary questions. Why did this message wait? Which approval allowed it? When was the campaign paused? A system that can answer those questions is easier to operate and easier to stop when something looks wrong.
Use a short pre-send review
Before enabling a workflow, confirm that authentication is visible, sending limits are explicit, suppression is shared, and the pause control blocks new claims. Check that the current content revision is the one reviewers saw. Then test the failure path with a draft or disabled workflow, without contacting anyone.
The checklist is intentionally plain. Safe operation comes from enforceable state and repeatable checks, not from a long policy document that the sending path never reads. Start with a boundary you can explain, then keep the implementation and the operator view consistent with it.
Mailbox capacity is one part of that model. How warmup and campaigns share one send budget explains why both paths need the same counter and claim-time decision.