Instantly Not Sending Emails? Common Causes and Fixes

A campaign sitting at zero sends is rarely a content problem, and it is almost never fixed by rewriting subject lines. It is a transport problem, and there are five places it usually lives.

The reason the symptom is confusing is architectural. A sequencer is not a mail server. It is a command layer that authenticates into your Google Workspace or Microsoft 365 mailboxes and asks them to send. When you launch a sequence, contacts go into an asynchronous queue and a background worker picks up each row, renders the template, and opens a connection. If that connection is refused, the worker retries in a loop while the application still shows the campaign as active. The status you are looking at describes intent, not delivery.

Work through the following in order. The first two account for most stalls.

1. Expired tokens and invalidated app passwords

This is the most common cause by a wide margin, because it happens without you doing anything.

Google Workspace issues an OAuth grant when you connect a mailbox. Google revokes that grant automatically under a range of conditions: an administrator changes security policy, app access rules tighten, or the connection ages past what the workspace allows for an unverified third-party app. Once the token is revoked the platform can no longer authenticate, and the queue pauses until you reconnect and complete a fresh handshake.

Microsoft 365 enforces MFA, so connected mailboxes typically use a 16-character app password. Those are invalidated instantly whenever an administrator updates security defaults, enables conditional access, or changes the account's password policy. The worker then receives a 535 Authentication Failed from the Microsoft node and stops.

The fix in both cases is to reconnect the mailbox and confirm a new authentication actually succeeds, rather than assuming a green indicator in the interface means a live session.

2. Rate limits and shadowbans

Providers run real-time velocity monitoring that is entirely separate from your published daily limit. A 2,000-a-day allowance does not mean 2,000 as fast as software can push them.

If a sequencer attempts fifty messages inside a minute, the receiving node reads the pattern as an unmanaged script and answers with 421 Max hourly delivery limit exceeded. Tools that implement progressive backoff will slow down and recover; tools that do not will halt the run to avoid getting the account locked.

The more dangerous version is the shadowban. After repeated velocity violations, the provider keeps accepting your connections and returning success responses while quietly quarantining everything you send. Your logs show delivery; your open rates fall to almost nothing. If you see that combination, stop sending from that mailbox rather than pushing harder, and let it rest. Continued violation turns a temporary block into a suspension.

Pacing is the fix, and pacing means both slower sending and more mailboxes. Distributing 500 daily touches across twenty properly warmed accounts is safe in a way that 500 from one account never is. If you are setting up new domains, warm-up is the process that earns this headroom.

3. A broken tracking domain

A custom tracking domain rewrites the links and open pixels in every message so they match your sending domain. Because it modifies the HTML of every email, a small DNS error stops sending entirely.

Two failure modes dominate. The CNAME for your tracking subdomain gets deleted, retyped, or shadowed by a conflicting record, so the platform's lookup fails when it tries to build the next message. Or the SSL certificate on that host lapses. Receiving filters reject payloads containing insecure tracking assets, and because unencrypted redirect links look like phishing, well-behaved sequencers auto-pause rather than send them.

Check that the CNAME resolves to the tool's tracking host and that HTTPS on that hostname is valid and current. Both are quick to verify and easy to overlook, because nothing about the symptom points at DNS.

4. Integration and permission drift

Teams connect sequencers to enrichment tools, CRMs, and webhooks with API tokens. Those tokens have lifespans, and refresh can fail silently on a timeout, leaving the interface showing connected mailboxes while every backend call throws an auth exception.

Separately, routine IT work breaks these connections on purpose. A security audit, an access-control update, or a change to permission models can drop a third-party app below the clearance it needs to send, and the workspace cuts the integration. The tell is an "Account disconnected" entry appearing without anyone touching the campaign.

5. List and template errors

If the transport is healthy, the problem is usually the data.

A spreadsheet with hidden non-ASCII characters, corrupted byte markers, or malformed headers can import visually while failing at template compilation. The worker hits an unhandled parse exception on a row and pauses the campaign instead of crashing the workspace.

The other version is a merge tag without a fallback. A line like I noticed your expansion into the {{city}} market is fine until twenty rows have an empty city column. Rather than send visible template code to a prospect, the platform halts the run. Every dynamic field in your copy needs a fallback value, and it is worth auditing for that before every launch rather than after a stall.

Why several of these failure modes are structural

Notice what causes 1, 2, and 4 have in common: they are all consequences of sending through mailboxes you rent from someone else. The OAuth grant belongs to Google. The velocity cap belongs to Microsoft. The permission model belongs to your IT department. A sequencer sitting on top of those inherits every one of their failure modes, and there is no configuration that removes them.

The alternative is to send through infrastructure you control directly. RepMail sends natively through AWS SES rather than wrapping connected mailboxes, so there is no OAuth token to be revoked mid-campaign and no per-mailbox app password to be invalidated by a policy change. Bounce and complaint events arrive in real time through AWS SNS, which means failing addresses are suppressed as they fail rather than after a delayed log sync, and authentication is configured at domain verification rather than left to per-mailbox setup.

That does not make deliverability automatic, and nothing does. Your list quality, your content, and your sender reputation still decide placement. But it removes an entire category of stall from the picture, which is worth knowing when you are debugging the same connection error for the third time this quarter.