The short version
- Campaigns declare a send window in their own timezone: a start hour, an end hour, and whether weekends are allowed.
- Messages queued outside the window are deferred to the next opening — never dropped, and never sent anyway.
- Window arithmetic runs against the IANA timezone database, so daylight saving transitions are handled correctly without a date library.
- Daily caps are the lower of your plan's limit and your mailbox's own limit. The trial allows 5 emails per day; monthly workspaces are bounded by the mailbox.
- Guards run at send time: already-sent, entitlement, daily cap, send window, bounced addresses, and unsubscribes are all re-checked immediately before the message leaves.
An outreach email that arrives at 3:14am local time announces itself. So does one that arrives on Sunday, and one that arrives as the eleventh message that hour from the same sender. None of those are content problems — the email may be excellent — and all of them are the reason it gets ignored.
Timing and volume are deliverability features, and they belong in the tool rather than in the sender's discipline.
What a send window is
Each campaign declares a window with four properties:
| Property | Meaning |
|---|---|
| Timezone | An IANA timezone such as America/New_York. Everything else is interpreted in it. |
| Start hour | Inclusive. A start hour of 9 means 09:00 is inside the window. |
| End hour | Exclusive. An end hour of 17 means 16:59 is inside the window and 17:00 is not. |
| Weekends | Whether Saturday and Sunday sends are allowed at all. |
Inclusive start and exclusive end is the same convention used everywhere else in software for ranges, and stating it explicitly avoids the off-by-one hour that otherwise shows up as “why did one email go out at five past five?”
Deferred, not dropped
A message that becomes due outside its window is not sent and not discarded. It is rescheduled to the next moment the window opens.
Both halves of that matter. Sending anyway would defeat the point of having a window. Dropping the message would silently lose outreach you approved — the worst possible outcome, because you would never know it happened.
There is one exception: when a person explicitly clicks send on a single message, it goes immediately. An operator making a deliberate choice is not the failure mode the window exists to prevent.
Editorial outreach
2 approved · your connected mailbox
Approved
Send
Follow up
Next message
A useful addition for your AI tools roundup
Hi Sarah,
Your comparison gives readers a practical view of the category. I noticed one relevant option is missing and pulled together the facts you would need to assess it…
Sarah Jones
growthlab.example
Marcus Lee
saasframe.example
Daily limits, doubled up
Two independent caps apply to how many emails leave a workspace in a UTC day, and the lower one always wins:
- 01
The plan limit
A trial workspace may send 5 emails per day. It is a small number on purpose: a trial exists to evaluate the pipeline, not to run a campaign.
- 02
The mailbox limit
Every connected mailbox has its own daily cap, reflecting what that provider and that account can send without trouble. Monthly workspaces are bounded by this rather than by the plan.
Taking the minimum rather than letting one override the other means neither a generous plan nor a generous mailbox can push the other past what it can safely handle.
A campaign is a loaded gun pointed at your own domain's reputation. Every guard on it is checked at send time, because between queueing and sending, the facts change.
The guards at send time
This is the design decision that matters most in the whole outreach system: nothing consequential is decided at queue time. A message may be queued on Monday and become due on Thursday, and in between, any of these can change.
| Guard | What it prevents |
|---|---|
| Already sent or replied | A retry or duplicate job sending the same message twice. |
| Active entitlement | Sending from a workspace whose plan has lapsed since the message was queued. |
| Daily cap | Exceeding the lower of the plan and mailbox limits for the current UTC day. |
| Send window open | Landing at 3am or on a weekend when the campaign said otherwise. |
| Contact not bounced | Sending again to an address that has already hard-bounced, which compounds reputation damage. |
| Contact not unsubscribed | Emailing someone who asked to be left alone — the one mistake with no acceptable excuse. |
| Mailbox still connected | Failing silently against a mailbox whose authorization has expired. |
Checking these at queue time would be faster and would be wrong. Someone can unsubscribe on Tuesday from a message that was queued on Monday and is due on Thursday. Only the check that runs on Thursday can catch it.
Follow-ups have their own brake
The same principle governs follow-ups: a scheduled follow-up is cancelled the moment a reply arrives. A live conversation never receives an automated nudge, because the nudge asks at send time whether the thread is still quiet. That mechanism is covered in reply classification and follow-ups.
All of it exists for one reason: outreach sends from your own mailbox, so the cost of getting this wrong lands on your domain and stays there.