Smart Sending Infrastructure & Sharding
Our proprietary sharding engine rotates outgoing volume across multiple accounts in a strict round-robin sequence, mimicking natural human behavior to protect your sender reputation.
Sending infrastructure is the part of email marketing that decides whether anything else matters. Copy, targeting and timing are all downstream of one question: did the message arrive in the inbox at all? This module is the answer to that question, and it works by refusing to do the thing that gets senders filtered - concentrating volume on a single identity.
Why volume concentration is the core problem
A mailbox provider evaluating an incoming message looks at the sending history behind it. One address that normally sends thirty messages a day suddenly producing four thousand is the single clearest signal available that something has changed, and the change is almost never benign. This is why campaigns fail despite good content and clean lists: the pattern was judged before the content was read. Distributing that same four thousand across twenty-five mailboxes means each one sends a hundred and sixty - a busy day for a person, and nothing a filter would flag.
How the rotation avoids collisions
Round-robin sounds trivial until several workers process the same queue concurrently. Two workers reading the same pointer will both select the same account, doubling its load and defeating the distribution. The rotation here advances an atomic Redis counter, so every worker receives a distinct position no matter how many run in parallel. Accounts in cool-down, unauthorised, or over their daily quota are skipped during selection rather than attempted and failed.
Pacing is a separate problem from distribution
Spreading volume across accounts is only half the work. Forty messages leaving one mailbox in ninety seconds is still recognisably automated, even though forty is a safe daily figure. Each dispatch is therefore scheduled with a randomly chosen delay between twenty-five and forty-five seconds, calculated when the job is queued and baked into the delayed job rather than held by a sleeping worker. The result is roughly eighty to a hundred and forty-four messages an hour per account, with no fixed rhythm for a filter to key on.
What happens when a provider pushes back
Providers signal overload with SMTP 421 and 429 responses. Treating these as failures and retrying immediately is how a short throttle becomes a long one. Instead, the affected account enters a sixty-minute cool-down recorded as an expiring key, and drops out of the rotation until it clears. The remaining accounts continue, so the campaign slows rather than stopping. If every account ends up cooled down simultaneously, the campaign pauses and alerts you - the correct behaviour when the alternative is accumulating thousands of failures nobody is watching.
Feature Breakdown
Multi-Provider SMTP Relay
Relay marketing messages securely using Google Workspace, Microsoft 365, or custom SMTP servers, with automatic STARTTLS encryption enforced on port 587.
Technical Capabilities:
Infrastructure Sharding Engine (Round-Robin)
Distribute your campaign volume evenly across all active sending accounts using atomic Redis pointers to prevent any single account from triggering spam volume thresholds.
Technical Capabilities:
Randomized Jitter Delay (Anti-Spam Timing)
Ensure natural sending patterns by applying random, non-repeating delays between consecutive messages in the queue.
Technical Capabilities:
Automated Account Cool-Down
Protect temporary connection errors and rate-limiting blocks by auto-throttling affected accounts for 60 minutes.
Technical Capabilities:
UTC Daily Send Limit Reset (Cron Job)
Align with major ESPs like Google and Microsoft by resetting account daily quotas at midnight UTC.
Technical Capabilities:
Spec Sheet
Need a Deep Dive?
See exactly how this module manages background queues, encryption, and delivery logic in our sequence flowchart.
View technical guideReady to Connect Your Nodes?
Scale your deliverability with our intelligent sharding relay. Add your domains and start landing in the inbox.
Smart Sending Infrastructure & Sharding questions.
The specifics people ask about before relying on this part of the platform.
What is email sharding and why does it improve deliverability?
Email sharding splits one campaign's volume across several sending accounts and domains instead of pushing everything through a single mailbox. Because spam filters key on volume-per-sender in a short window, spreading 5,000 messages across 25 mailboxes means each one sends 200 rather than 5,000 - well inside normal business behaviour.
Which email providers can I relay through?
Google Workspace, Microsoft 365, and any custom SMTP server. Connections enforce STARTTLS on port 587, and connection pooling avoids repeating the handshake for every message.
How does the round-robin rotation decide which account sends next?
An atomic Redis counter advances a pointer through the pool of ready accounts, so concurrent workers can never pick the same account twice. Accounts that are in cool-down, unauthorised or rate-limited are skipped automatically.
How fast can each account send?
A random 25 to 45 second delay is applied between messages, which works out at roughly 80 to 144 emails per hour per account. The delay is calculated when the job is queued and baked into the scheduled dispatch, so workers never sit idle waiting.
What happens if a sending account starts failing?
An SMTP 421 or 429 response puts that account into a 60-minute cool-down, recorded as an expiring Redis key so it restores itself automatically. The remaining accounts keep sending. If every account goes offline, the campaign pauses and alerts you rather than burning through the list with failures.
When do daily sending limits reset?
At 00:00 UTC, via a scheduled job. That matches how Google and Microsoft account for daily quotas, so your counters and theirs stay aligned.