Send pipeline Gmail API · Microsoft Graph · SMTP/IMAP

One queue. Three providers.
Real throttling.

Every lead drops into a single send queue. NuMail routes each message out through whichever of your mailboxes is next in line (Gmail API, Microsoft Graph, or raw SMTP) and never sends faster than a real person would. No shared IPs, no blast relays. Your mailboxes, paced like mailboxes.

Start a 14-day trial →How the engine works
+4/day
Slow ramp / new SMTP box
9–5
Default window · Mon to Fri
3
Send providers, one queue
1M+
Emails / month / workspace
▸ The architecture

One queue routes across every provider.

Leads enroll once. The scheduler picks the next eligible mailbox per lead, respecting that mailbox's provider, throttle, daily cap, timezone and send window, then dispatches through the right transport.

Enrolled leads

Every lead in an active campaign step becomes one queued job, tagged with the campaign, the sequence position, and the eligible mailbox pool.

→
Per-lead send queue
Throttled scheduler
next-eligible-mailbox · per-box limits
G

Gmail API

OAuth send via users.messages: no SMTP password, full thread headers.

M

Microsoft Graph

sendMail on the connected M365 mailbox, with native conversation IDs.

S

SMTP / IMAP

Any provider (custom domains, Zoho, Fastmail), sent SMTP, read over IMAP.

▸ What the engine does

Five controls. Per mailbox.

The pipeline isn't one global rate limit. Every mailbox carries its own provider, cadence, daily ceiling, timezone and send window, and the scheduler enforces all five before a single message leaves.

⇄

Provider routing

One queue, three transports. A campaign can pool a Gmail mailbox, a Microsoft 365 mailbox and an SMTP custom-domain box together; the scheduler dispatches each send through the correct API for whichever mailbox it lands on. Threading, Message-ID and reply detection are handled per provider, so a lead stays in one clean conversation no matter who sent it.

Gmail APIMicrosoft GraphSMTP + IMAP
⏱

Per-mailbox throttle & ramp

Each mailbox sends on its own clock: its own daily limit, send window and timezone, plus an optional minimum gap between sends, set per mailbox or per campaign with jitter. Turn on slow ramp and a new box starts at 4 sends a day, adding 4 a day until it reaches its limit; SMTP mailboxes connect with it on. There is no global firehose to misconfigure.

Per-box daily limitOptional gap ±jitterSlow ramp +4/day
◐

Local-timezone scheduling

Every mailbox has a timezone. Daily limits reset at that mailbox's local midnight (not UTC, not your dashboard's clock), so a London box and a Denver box roll over independently. Quotas, send windows and "sent today" counters all read from the mailbox's own day boundary.

Local midnight resetPer-mailbox TZ
⊘

Bounce & suppression

Hard bounces suppress the address instantly: it's added to the workspace suppression list and never contacted again from any campaign. Soft bounces (full mailbox, greylisting, transient 4xx) are counted against the lead, and a third soft bounce suppresses the address like a hard one. Suppression is workspace-wide and survives re-imports.

Hard → suppress3rd soft → suppress
▤

Send-window controls

Set the hours and days each mailbox is allowed to send, typically business hours, Monday through Friday, in the mailbox's local timezone. Weekends are skipped by default; the queue holds anything scheduled outside the window and releases it the moment the window reopens, without bunching. A campaign can also skip major US holidays, so your sending pattern reads human even at a million-a-month volume.

Business-hours defaultWeekend skipUS holiday skipHolds & releases cleanly
▸ Ramp & throttle, visualized

New mailboxes earn their volume.

A fresh mailbox blasting hundreds of cold emails on day one is how domains get burned. With slow ramp on, a new box starts at 4 sends a day and adds 4 a day until it reaches its daily limit, then holds there.

The default is the safe default.

Every mailbox connects with a modest daily limit, a business-hours window and the weekend skip already set, and its count resets at its own local midnight. SMTP mailboxes also start on the slow ramp. Change any of it per mailbox when you have the reputation to spend.

  • New Gmail / M365 box50 / day
  • New SMTP box30 / day, slow ramp on
  • Slow ramp4 on day 1, +4 / day
  • Gap between sendsOff unless you set one
  • Reset boundaryLocal midnight
  • WeekendsSkipped
Daily send ceiling · new SMTP mailbox4 → 30 by day 8
Day 1 · 4Day 8 · 30Day 14 · 30
▸ NuMail vs blast-senders

Throttling isn't a setting. It's the product.

Shared-IP relays optimize for throughput and let deliverability be your problem. NuMail optimizes for mailboxes that keep landing in the inbox at scale.

Shared-IP blast senders

Throughput first

  • ✕Send from a pool of shared IPs and shared subdomains, so your reputation rides on every other sender on the relay.
  • ✕"Rate limits" are global per account, not enforced per mailbox, so one campaign can starve another.
  • ✕One provider path. If their relay is throttled or blocklisted, every mailbox you own goes down with it.
  • ✕Daily resets and windows run on the platform's clock, so a mailbox can dump its whole quota at 3am local.
  • ✕Bounces are counted, not enforced; the same dead address gets retried across campaigns.
NuMail send pipeline

Your mailboxes, paced

  • ✓Sends go out from your own Gmail, Microsoft 365 and SMTP mailboxes: your domains, your reputation, no shared IPs.
  • ✓Real per-mailbox throttling: per-box daily ceiling, send window and optional gap, independent of every other mailbox and campaign.
  • ✓Three providers behind one queue: lose a Gmail box and the rest of the pool keeps sending uninterrupted.
  • ✓Limits reset at each mailbox's local midnight; sends only fire inside its business-hours window, weekends skipped.
  • ✓Hard bounces suppress instantly and workspace-wide; a third soft bounce does the same. Dead addresses stay dead.

Send a million.
Like a human would.

Connect your Gmail, Microsoft 365 and SMTP mailboxes, set a pool, and let the pipeline pace it. Daily limits, send windows and bounce handling are on by default.