What actually happens after you press send

Most email tools show you a progress bar. It is reassuring and it tells you almost nothing. Here is what happens inside DearReach between the moment you press send and the moment a message reaches a mailbox provider, and why the design looks the way it does.

Step one: the audience is frozen

When you send, DearReach resolves your audience once and writes a row per recipient. That set is then immutable. Someone who subscribes a minute later is not silently added, and someone who is deleted mid-send does not vanish from the record.

This matters because a send that changes shape while it is running cannot be reasoned about. You could never answer “who received this” with confidence. Freezing the audience turns that question into a lookup.

Suppression is applied while that list is built, so unsubscribes, bounces, and complaints are filtered out before anything is queued.

Step two: the ledger, not the counter

Those per-recipient rows are the source of truth. Every state change lives there: queued, submitting, sent, bounced, complained, failed.

The numbers you see on the campaign page are projections built from that ledger. If a counter and the ledger ever disagree, the ledger wins and the counter is rebuilt. We never treat a running total as the record of what happened, because totals drift and rows do not.

Campaign completion is derived the same way. A campaign is done when there are no unfinished rows left, not when a counter happens to reach the audience size.

Step three: intent is written before the provider call

Before DearReach hands a message to the email provider, it records an attempt and moves the recipient into a submitting state. Only then does the network call go out.

The order is deliberate. If the process dies mid-call, the record already says “we were about to send this”, which is the information you need afterwards. The alternative, calling first and recording after, produces sends nobody knows about.

Step four: ambiguity is reconciled, not guessed

Sometimes a call is made and the answer never arrives. The message may have been accepted, or not. Those rows sit in that ambiguous submitting state.

The tempting shortcut is to sweep them up after a timeout and either retry them all or mark them failed. Retrying sends duplicates. Marking them failed loses real deliveries. So DearReach reconciles against what the provider actually reports rather than assuming, and only then resolves the row.

Why we say at least once, not exactly once

A database and an email provider are two separate systems. There is no shared transaction between them. Anyone who promises exactly-once delivery across that boundary is either simplifying for marketing or has not hit the failure case yet.

DearReach is at-least-once, and every job and every provider webhook is written to be idempotent, so replaying one is harmless. In normal operation you will not see duplicates. In a bad crash at exactly the wrong moment, a recipient receiving a message twice is a far better outcome than one silently receiving nothing.

We would rather tell you that plainly than describe a guarantee the physics does not support.

Pausing, resuming, and scheduling

Pausing stops new work being claimed. It does not try to recall messages already in flight, because that is not a thing anyone can do. Resuming picks up only the recipients who were never completed, so nobody is mailed twice by a pause.

Scheduled sends check the stored schedule at dispatch time. If you cancel or change it, the job that eventually fires finds the schedule no longer matches and does nothing.

Why this is worth reading about

Almost none of this is visible in the interface, which is the point. But when a send goes strangely, the difference between a tool that kept a ledger and one that kept a counter is the difference between an answer and a shrug.

You can see the per-recipient outcomes for any campaign in its activity view. That is the same ledger, not a summary of it.