Email Deliverability Issues: Isolate the Failing Layer
Summarize with AI
Troubleshoot email deliverability issues as an isolation problem. First segment the evidence by mailbox provider, sending domain, and sender inbox. Then separate it by campaign and recipient cohort. Change one input inside the failing branch while holding the comparison branch still. Do not change several inputs at once. Editing DNS or replacing domains while also rewriting copy or changing recipients destroys the evidence needed to identify which layer failed.
Freeze the incident window and evidence
Choose the first clearly affected send and a comparison period before it. Preserve message IDs, timestamps, sending domain, sender inbox, sending IP when available, recipient domain, campaign version, cohort label, authentication results, SMTP response, bounce class, and human reply class.
Do not overwrite changing statuses. Keep the raw provider response beside your normalized label. RFC 3463 defines enhanced mail status codes, including the distinction between persistent transient 4.X.X failures and permanent 5.X.X failures. Those codes provide structured delivery evidence, but they do not prove inbox placement or human attention.
Accepted, delivered, inboxed, and replied are different states. A receiving server can accept a message without placing it in the primary inbox. Preserve the distinction so a campaign problem is not misdiagnosed as transport failure.
Our opinion is that teams should not change a sending domain until the provider split has been checked. A domain-wide intervention based on a Gmail-only or one-inbox symptom is an expensive way to hide the original fault.
Build the five-axis isolation table
Create one row per meaningful slice. Do not pool all sends into a single deliverability number.
| Axis | Compare | Evidence to preserve |
|---|---|---|
| Provider | Gmail, Microsoft, other known providers, unknown | SMTP codes and provider telemetry, plus replies |
| Domain | Each sending domain under the same period and policy | SPF, DKIM, DMARC, sending source, IP context |
| Inbox | Individual sender inboxes on the same domain | Error concentration and send log, plus authentication headers |
| Campaign | Frozen subject, body, links, sequence position, and send policy | Exact campaign version and assigned recipients |
| Cohort | Recipient source, verification state, role, segment, and geography | Eligibility snapshot and bounce or reply class |
LeadHaste practice: we assign an immutable campaign version and preserve the segment definitions used at send time. This is a LeadHaste operating method, not a claim that mailbox providers require the same record.
Branch one: mailbox provider
Ask whether the symptom is concentrated at one receiving provider. Compare the same sending domain and inbox pool, using the same campaign version and a similar recipient cohort across providers. If Gmail changes while Microsoft and other groups remain stable, continue inside the Gmail branch. Do not average the difference away.
Google's Postmaster Tools dashboard guide says its data covers outgoing mail to personal Gmail accounts and includes spam rate, domain and IP reputation, authentication, and delivery errors. Google also says the data is not real time, may take longer than a day to update, can omit low-volume days, and may include only DKIM-authenticated messages in some dashboards.
A blank dashboard is therefore missing evidence, not a healthy result. Compare the provider's telemetry window with your message-level records. If the affected provider supplies a rejection code, test the stated condition inside that provider branch before changing unrelated campaigns.
Controlled test: send the frozen treatment through one known-good and one affected sender branch to comparable eligible recipients at the same provider. Change neither copy nor links, and keep the cohort rule and timing policy fixed. If the difference remains provider-specific, keep the investigation there.
Branch two: sending domain
Within the affected provider, compare sending domains that used the same campaign and cohort rules. Check SPF and DKIM, along with DMARC results from actual message headers or provider evidence, not only from a DNS checker.
Google's email sender guidelines describe authentication expectations, PTR requirements for sending servers, shared-IP reputation effects, and the effect of frequent spam reports on domain reputation. Those are Gmail requirements and guidance. They do not establish a universal reason for every provider decision.
Controlled test: hold provider and inbox type constant while using the same campaign version and cohort definition to compare one affected domain with one domain that remains normal. If authentication differs, correct the verified configuration defect and repeat the same comparison. Authentication passing is an eligibility check, not proof that reputation or inbox placement recovered.
Do not rotate the domain merely because one external checker reports a poor score. Preserve provider telemetry and actual headers, along with message responses, before deciding whether the issue belongs to the domain.
Branch three: sender inbox
If one domain contains both affected and normal sender inboxes, compare inbox-level configuration and logs. Check whether the same provider, campaign version, cohort rules, authentication, and sending policy apply. Look for mailbox-specific authorization failures, provider throttling, connection errors, unexpected sending sources, or missing records.
Controlled test: assign a small, comparable recipient set to one affected inbox and one normal inbox on the same domain. Keep the campaign and send policy fixed. If only one inbox reproduces the symptom, pause that inbox from production while its account and sending logs are reviewed. Do not condemn the entire domain from one mailbox.
Escalate suspected account compromise or unauthorized sending to the mailbox administrator and security owner. Deliverability troubleshooting can expose the symptom, but it is not a substitute for an account-security response.
Branch four: campaign
Provider and domain comparisons may remain normal. If inbox comparisons do too, split by exact campaign version. Preserve subject, body, visible URLs, attachments, preview text, sequence position, and sending cadence as one treatment. If several changed together, the result belongs to the whole treatment.
Controlled test: compare the affected campaign with a known comparison campaign using the same infrastructure and equivalent cohort rules. For a copy-level test, change only the chosen element. If the recipient pool also changes, you cannot attribute the result to campaign content.
Classify human replies separately from out-of-office messages and unsubscribes, as well as delivery failures. We do not recommend pixel-derived opens as the primary diagnostic outcome. Our prospecting email subject line test explains how to preserve intact treatments and reply labels.
Branch five: recipient cohort
Compare recipient source, verification state, company segment, role-address policy, geography, and mailbox-provider composition before assigning the failure to infrastructure. Save the eligibility snapshot used before sending so later enrichment does not rewrite the evidence.
Controlled test: keep provider and domain fixed while using the same inbox, campaign version, and send policy to compare two cohorts that differ only on the suspected rule. If a purchased or newly sourced segment carries most permanent mailbox failures, route the finding to list acquisition and verification. If negative replies or complaints concentrate in one segment, review eligibility and relevance along with suppression handling rather than replacing infrastructure.
Our email list hygiene guide covers the upstream controls. This isolation branch only asks whether cohort construction explains the observed issue.
Stop when the experiment cannot identify a cause
Stop and redesign the comparison when multiple variables moved together, sample selection differs materially, provider data is delayed, or message records are missing. "No conclusion" protects the next decision better than a confident answer built from mixed treatments.
Maintain an incident record with the failing branch, preserved evidence, controlled change, observed result, owner, and next decision. If a test clears one branch, return to the tree rather than applying the same fix everywhere.
LeadHaste practice: across our 35+ tool outbound system, we keep client-owned domains and sender records connected to campaign and cohort versions. That lets us isolate a failing boundary without claiming that one test guarantees future inbox placement.
Ready to isolate the issue before changing the system?
We can review your ICP, campaign fit, sender evidence, and cohort boundaries before you make a broad infrastructure change. Book your free discovery call →
Frequently Asked Questions
A strong positive reply rate for B2B cold email is 1.5–3%. Top-performing campaigns with tight targeting and personalized copy can hit 4–5%. If you're below 1%, it usually signals a deliverability or messaging problem, not a volume problem.
The safe range is 30–50 emails per inbox per day for warmed inboxes. That's why outbound systems use multiple inboxes (we use 80) to reach 40,000+ monthly sends while keeping each inbox well within safe limits. Sending more than 50/day from a single inbox risks spam folder placement.
Yes. The CAN-SPAM Act permits unsolicited commercial email as long as you include a physical address, an unsubscribe mechanism, accurate headers, and non-deceptive subject lines. Unlike GDPR in Europe, the US does not require prior opt-in consent for B2B cold outreach.
Domain warm-up typically takes 2–3 weeks. During this period, sending volume gradually increases while the email warm-up tool generates positive engagement signals (opens, replies) to build sender reputation. Skipping or rushing warm-up is the most common cause of deliverability problems.
Cold email is targeted, relevant outreach to a specific person based on their role, industry, or company, with a clear business reason. Spam is untargeted mass messaging with no personalization or relevance. The distinction matters legally (CAN-SPAM compliance) and practically (deliverability depends on relevance signals).
