How far apart should cold email follow-ups be for a small sender?
Spacing should give a real person time to respond and the system time to process state; there is no protocol-defined universal cadence.
Read field note →Follow-up systems
A follow-up system has to space touches sensibly and, more importantly, stop the moment a prospect replies — including from a different alias, or in the race between a locked job and the provider call. These notes also cover business-day scheduling, out-of-office handling, and RFC 8058 one-click unsubscribe.
New to this? Start with the pillar guide: Reply detection and follow-up state for cold email
When should a cold email sequence stop after no reply?
A sequence should have an explicit maximum touch count and stop conditions; indefinite follow-up converts uncertainty into repeated unwanted mail.
Read field note →Reply detection must cancel follow-ups before the next queue run
The safest follow-up is the one never sent after a recipient has already replied.
Read field note →Should a cold email follow-up stay in the same thread?
Threading preserves context when headers and provider behavior support it, but your system should not fake relationships it cannot reliably reconstruct.
Read field note →How to make follow-ups respect business days without hard-coding one timezone
Scheduling should store the recipient or campaign timezone assumption explicitly and compute the next eligible business window at execution time.
Read field note →How should an outbound system handle out-of-office replies?
Out-of-office messages are replies for state handling but not necessarily human interest; classify them separately from positive, negative and neutral responses.
Read field note →How long should SMTP 4xx errors be retried before a lead is treated as undeliverable?
SMTP defines 4xx as temporary but does not give one universal cold-outreach retry duration. The transport queue and the business workflow need separate expiration rules.
Read field note →One-click unsubscribe headers must be covered by DKIM: the RFC 8058 detail easy to omit
Publishing List-Unsubscribe and List-Unsubscribe-Post is not enough for RFC 8058 one-click behavior. The message needs a valid DKIM signature that covers those headers.
Read field note →Unsubscribe once, stop everywhere: build suppression above the individual outbound mailbox
If multiple mailboxes can contact the same lead, a per-mailbox unsubscribe flag is too narrow. The sending scheduler needs a shared suppression decision before any future queue run.
Read field note →A prospect can reply from a different alias: stop follow-ups from thread evidence, not From-address equality alone
People reply from delegated accounts, aliases, assistants, or another mailbox. A detector that requires the inbound From address to equal the original lead can miss a real conversation.
Read field note →The reply/send race: what if a prospect replies after the follow-up job is locked but before the provider call?
Polling for replies and dequeuing follow-ups are concurrent processes. Without a final state check, a perfectly detected reply can still lose a race to a job that was already claimed.
Read field note →Auto-Submitted is also a loop-prevention signal: do not let two autoresponders keep each other alive
RFC 3834 recommends Auto-Submitted markers on automatic responses and says automatic responders should not blindly answer messages that are themselves automatically submitted.
Read field note →Build the one-click unsubscribe endpoint idempotently: duplicate POSTs should not resurrect or error on an opt-out
RFC 8058 defines the one-click POST shape. The application behind the URL still needs safe repeat handling because receivers, users, or retries can submit the same opt-out more than once.
Read field note →