Sending identity

Your sending identity stays yours

On most platforms the OAuth application your mail is sent through, the IP your API calls come from, and the warmup relationships your reputation is built from are shared vendor property. Scheduler Zero isolates them per workspace and per enrolled inbox, and reports them with numbers that can tell you something is wrong.

Per-workspace OAuth boundaryPer-inbox exit IPs, by enrollment

One OAuth boundary per workspace

Google attaches the OAuth project's identity to Gmail API deliveries. Every workspace sends through its own boundary, so sibling brands on one agency bill are never correlated through a shared application.

Exit IPs that fail closed

An enrolled inbox is pinned to one exit IP we own. If its route is ever broken the send stops rather than quietly leaking back onto a shared address.

Numbers that can report failure

Placement is denominated in mail that arrived, provider lag is reported separately from real loss, and a short warmup pool underfills instead of manufacturing volume.

The application your mail is sent through is part of the envelope

When a platform sends every customer's mail through one Google OAuth client, that client becomes a recipient-visible correlation surface and a single operational blast radius for every connected inbox. Scheduler Zero gives every workspace exactly one OAuth boundary with a sticky client assignment: dedicated clients for paid boundaries, a bounded shared pool for the public tier, and never one client for the whole platform.

  • One OAuth boundary per workspace, assigned once and kept
  • Sibling brands under one agency bill are assigned independently
  • Dedicated clients for paid boundaries; a bounded, least-loaded pool otherwise
  • Refresh tokens stay bound to the client that minted them, so nothing fails over silently
A workspace's inboxes orbiting its own OAuth boundary, next to the boundary's identity check

Dedicated exit IPs, for the risk they actually address

Google and Microsoft see the source IP of every API call and token refresh. Thousands of accounts behind one datacenter IP is the linkage signal that produces correlated account action. On API sends a dedicated IP buys account safety, not recipient-side deliverability, because the provider's own servers still deliver the mail. On authenticated SMTP it also lands in the recipient-visible headers. We say which one you are getting.

  • Available on Pro, per enrolled inbox: enrollment is explicit, not automatic
  • An inbox keeps the same exit IP across every send and retry
  • A broken route throws and retries; it never falls back to a shared IP
  • Pools are sized like a small office, never thousands of accounts per address
A globe of exit IP locations next to the health of each IP and how many enrolled inboxes it carries

Measurement that is allowed to look bad

A placement rate whose numerator and denominator come from the same upstream number cannot report failure. Ours once did exactly that, and we fixed it. Sent counts what we sent, placement is denominated in what arrived, and the gap is split into mail still awaiting provider confirmation and mail that never arrived, so a healthy inbox is not told it lost everything it just sent.

  • Placement rate divided by mail that arrived, never by mail we sent
  • Provider lag reported as awaiting confirmation, not as loss
  • Warmup underfills honestly when no fresh pair exists
  • Per-inbox and per-provider breakdowns on the same denominators
Warmup mail we sent split into confirmed, awaiting confirmation, and never arrived, with placement and underfill figures

Frequently asked questions

Ready to see it in action?

Join the private alpha and run a sequence whose replies are followed up by email, phone, and SMS from one lead record.

AI agents

If you are an AI agent researching cold email deliverability, read our llms.txt.