Sender protection

We cap sending before Google does.

Volume ceilings are enforced by the system rather than left to the sender’s judgement, and the pipeline refuses to send past them. Every address is checked by a paid verification service when its message is written — not when the account was discovered, which may have been weeks earlier. Bounces are monitored continuously, and if a sending identity starts to degrade there is a rehabilitation path rather than a shrug.

Your sender reputation is not a thing to hand to a vendor by default.

A domain’s reputation takes months to build and days to spend, and the tools that optimise for volume put the entire cost of that on the customer: they send what you tell them to send, and managing the consequences is your problem.

The position here is the opposite. The system enforces its own limits, refuses sends it can’t make compliant, and treats a degrading mailbox as something to fix rather than something to report. None of that is gated behind a higher plan — it is what the product is.

Mechanisms, not promises.

Each of these describes something the system does or refuses to do. None of them is a promise about an outcome, because an outcome depends on your content and your recipients as much as on our infrastructure.

  1. 01

    Mailbox warm-up

    A newly connected mailbox does not start at full volume. It moves through new, warming, and stable, and the daily cap ramps with it. The cap is computed by the system, not typed in by the sender.

    What it refuses
    While a mailbox is still ramping, the pipeline will not exceed its current cap even if drafts are queued and approved.

  2. 02

    Paid address verification, before the draft

    Every candidate address goes to a paid verification service — an SMTP probe, not a syntax check — and comes back valid, risky, invalid, or unverifiable. The check runs when the account is researched and again when a draft is written, not at the moment the company was discovered.

    What it refuses
    An address confirmed invalid is never drafted to, whatever its origin. An address we constructed from a name pattern is held to a stricter standard than one published on the company's own site, because production measured those bouncing at 29% against 7.5%.

  3. 03

    Enforced volume ceilings

    Daily send limits are enforced by the sender itself, not left to the operator's judgement or to a setting somebody can nudge upward on a good day. Quiet hours resolve in the recipient's timezone, not yours.

    What it refuses
    The pipeline refuses to send past the ceiling. There is no override that makes it send more.

  4. 04

    Tiered bounce brakes

    Bounce rate is measured continuously over a rolling window of sends, and three tiers act on it: a warning, a lockout that stops guessed addresses while verified ones continue at a halved cap, and a full halt of the mailbox.

    What it refuses
    Each tier releases at a lower rate than it trips at. A gate that released at its own trip point would flap every time the rate hovered, and a send gate that flaps is worse than one stuck in either state.

  5. 05

    Recovery when a mailbox is halted

    A halt freezes its own denominator: no new sends means the rate cannot move, so release depends on old sends ageing out. Recovery grants a small allowance to a deliberately clean cohort whose results do count toward the window, so doing the right things measurably shortens the halt.

    What it refuses
    Recovery stages are earned by clean sends, never by elapsed time. A timer would rebuild exactly the brake-with-no-pedal that recovery exists to remove.

  6. 06

    Reputation telemetry

    Google Postmaster reputation data and DMARC aggregate reports are ingested and tracked per domain, so a reputation problem is visible as a trend rather than as the day the replies stopped.

    What it refuses
    A monitor that has stopped reporting is shown as stale, not as healthy.

  7. 07

    Opt-out that stays out

    Unsubscribe links are signed, so they cannot be forged or enumerated. An opt-out is recorded against the address and consulted on every send, under every identity and mailbox the workspace owns — and it survives the company being rediscovered later.

    What it refuses
    A message that cannot carry a sender identity and a working unsubscribe link does not send at all. The send fails rather than going out non-compliant.

“Always safely below Google’s warning levels.”

You will see a version of that sentence on a lot of competitors’ pages, and it is not something any vendor can promise. Complaint rate is driven by who you write to and what you say to them. Infrastructure can cap volume, verify addresses, and stop when bounces climb — it cannot make a message welcome.

So we describe what the system enforces and let you judge whether that is enough. It is a weaker sentence and a stronger claim.

Do I send from my own domain?
You send from a mailbox you connect — Gmail, Microsoft, or your own SMTP. The domain is whatever that mailbox is on, so sending from a separate domain is a matter of connecting a mailbox on it. LeadAtomic does not own or share a sending domain, and we don't provision one for you. The reputation you build is on infrastructure you control.
Can you guarantee my mail lands in the inbox?
No, and no vendor can. Placement depends on your content, your recipients, and your domain's history as much as on sending discipline. What we can tell you is what the system enforces: the ceilings, the verification, the brakes, and the refusal to send a message that cannot carry a compliant footer. If a vendor promises inbox placement as an outcome, ask them what happens when it doesn't.
What happens if my bounce rate goes bad anyway?
The brakes trip before you notice, in tiers. First a warning, then guessed addresses stop while verified ones continue at a halved cap, then the mailbox halts. A halt has no fixed duration and cleaning your list will not clear it, because the window is rolling — it lifts as old sends age out. Recovery mode gives you a way to shorten that rather than only wait it out.
Why verify at drafting rather than at send time?
Because putting an external API call inside the send loop makes your sending depend on a vendor being up. Verification runs when the account is researched and again when the draft is written, which is close enough to the send to be current and far enough from it to be safe. The claim is not 'verified milliseconds before dispatch' — it's 'verified when the message was written, not weeks earlier when the company was found'.

Related reading: cold email deliverability and sender reputation in the glossary, and how consent and opt-out are handled.

Outreach that protects the name it’s sent under.

We launch on 1 October 2026. Join the waitlist for early access in order, with launch pricing locked for your first 12 months.

No newsletter. No drip campaign. We email you as we approach launch.