When a campaign fails, start with the control that failed. Domains, DNS, mailboxes, schedules, account assignments, tracking, lists, and offers belong to different diagnostic layers.
When DKIM fails, changing the campaign schedule will not repair it. When messages continue after a reply or send through the wrong accounts, adding domains will not repair that either. Diagnose the failed control before changing the stack.
A sequencer is the software that runs the campaign: it chooses which mailbox sends, when messages send, and when follow-ups stop. Infrastructure is the layer underneath it, including domains, DNS, mailbox accounts, provider access, and the systems used to send and receive mail.
Product bundles vary. Some sequencers provision mailboxes or configure DNS, while some infrastructure providers enforce sending controls. Start by identifying the setting or asset that must change and the logs that can confirm its behavior.
| Symptom | Check First | | --- | --- | | Messages fail authentication | Domains, DNS, keys, and the sending provider | | Messages send too quickly or continue after a reply | Sequencer limits, gaps, assignments, and stop rules | | A campaign cannot reach its planned volume | Mailbox availability and sequencer limits | | Recipients complain despite successful delivery | List source, targeting, suppression, and message | | Losing one domain removes too much planned capacity | Infrastructure design and replacement readiness |
Infrastructure begins with the assets that identify and carry the sender: domains, DNS, mailbox accounts, provider or tenant configuration, and the systems used to send and receive mail.
Its responsibilities include:
Google's sender guidelines make several of these
dependencies explicit. For mail to personal Gmail accounts, all senders need SPF or DKIM, valid
forward and reverse DNS for sending IPs, TLS, RFC 5322 formatting, and spam rates below 0.3%.
Senders above Google's bulk threshold need SPF and DKIM, DMARC at least at p=none, and alignment
between the visible From domain and either the authenticated SPF or DKIM domain. Google separately
recommends gradual volume increases and Postmaster Tools spam rates below 0.1%. Authentication
establishes identity; it does not make an unwanted message acceptable.
A sequencer may test whether those records exist, but the registrar, DNS zone, DKIM key, mailbox license, and tenant still need an explicitly assigned owner. Which vendor performs that work varies by stack. If DKIM is missing or a domain expires, changing a campaign schedule does not fix the underlying failure.
Infrastructure also determines how much planned capacity can disappear at once. Ten mailboxes on one domain create a larger single point of failure than ten mailboxes distributed across several well-managed domains. The sequencer can rotate across the accounts it receives, but it cannot create missing domains or prepare replacement capacity after a concentrated domain is removed.
Spreading mailboxes across domains can reduce the loss caused by one domain pause. It does not isolate the sender from shared tenant, provider, IP, tracking-domain, or aggregate receiver signals. Every domain should remain a stable, authenticated identity rather than a disposable replacement for poor performance.
The sequencer decides how leads and messages move across connected accounts. Its controls typically include:
These are not cosmetic settings. They change the actual traffic pattern. As one documented example, Instantly's current campaign options include account assignment, stop-on-reply behavior, open and link tracking, delivery optimization, daily limits, and time gaps.
Rotation deserves special attention. A campaign can appear to have ample capacity while one account is disconnected, paused, or already consumed by another campaign. Instantly's inbox-rotation guidance notes that removing an account from a campaign can allow another to take over, while disconnecting or removing it at the account level can leave the campaign waiting. That is sequencer behavior, not evidence that the remaining mailboxes are unhealthy.
Tracking is a good example. The sequencer decides whether to add an open pixel, rewrite links, or use a tracking domain. Infrastructure or DNS may own the domain behind that tracking. A problem can therefore begin in a campaign setting and surface as a domain or reputation issue.
Pacing crosses the boundary too. The sequencer enforces limits and gaps, while the connected accounts and the operator's conservative per-account budgets determine planned throughput. A 300-message campaign target cannot be met when current account limits and availability provide only 150 planned sends. Actual accepted volume remains dynamic because providers and receivers can throttle or reject traffic based on account, tenant, IP, domain, message, and recipient signals. Conversely, a large mailbox pool does not prevent bursts if the sequencer is told to send too much inside a narrow window.
Authentication can also be shared work. Infrastructure authorizes sending paths through SPF, publishes DKIM public keys and DMARC policy, and controls the domains and keys. The outbound provider or integration must use an authorized path, DKIM-sign with the matching private key, and preserve a visible From identity that passes DMARC alignment. Verify the result in received headers. A clean DNS setup does not help if the application sends with a misaligned identity.
Cross-boundary failures need evidence from both systems: DNS and authentication checks, mailbox status, campaign assignment, activity logs, SMTP responses, and the final message headers received at the destination.
The operator still owns list source, data age, suppression, targeting, offer quality, factual copy, and the decision to continue or stop. Recipient reactions show whether the campaign itself should continue. Google tells senders to monitor spam rates, server responses, bounces, deferrals, and domain reputation. Yahoo's sender best practices similarly emphasize authentication, complaints, unsubscribes, and standards compliance.
If authentication passes and pacing matches the configured limits, but recipients consistently complain, opt out, or reject the offer, inspect the source, targeting, and message before adding capacity or changing sequencers.
Start with the symptom and collect the evidence from the layer that controls it:
Extra capacity is useful only after list quality, recipient response, and configuration have been examined. Domain diversification does not rehabilitate unwanted mail.
If the evidence is mixed, do not change five variables at once. Authentication failures, suppression defects, or credible recipient complaints should trigger an immediate pause. Controlled cohort testing is appropriate only after those issues are cleared. Define the observation window and stop conditions before the test, then compare receiver and SMTP signals with the baseline.
Ask an infrastructure provider who owns the domains and mailboxes, how authentication is configured, how many inboxes share each domain, what reputation exposure is shared, how assets are monitored, and what happens when capacity has to be repaired or replaced.
Ask a sequencer how it assigns accounts, enforces limits across campaigns, spaces traffic, handles replies and unsubscribes, rewrites links, exposes SMTP errors, and behaves when an account becomes unavailable.
Then document the handoff between them. Record which domains and inboxes belong to which campaigns, where limits are enforced, which system owns suppression, who reviews replies, and which evidence triggers a pause.
Record the owner, configured limit, evidence source, and pause condition for each critical variable. That makes the first diagnostic step clear when a campaign fails.
Size domains and density to your sending target and see the capacity that holds.
Book a Call