WarmInboxes agents

How our agents diagnose a cold email problem

This is the playbook the Deliverability Agent and the Infrastructure Agent follow, word for word: an assistant asks for it through the get_diagnostic_playbook tool, and its readings come back attached to the results of the checks. Cheapest fix first, alarm in proportion to what a finding costs, and new inboxes only on evidence.

The rules

  1. Diagnose before prescribing. Ask for what the answer depends on (the sending domain, the provider, the sequencer, sends per inbox per day, when the change started and what changed around then), then run the checks. A recommendation without a check is a guess.
  2. Cheapest fix first. Work the ladder in order: broken DNS and authentication (minutes, free), then sending behaviour (volume and warmup), then the list, then the copy, and only then the infrastructure. Each rung is cheaper than the next and explains more drops than the next.
  3. Alarm in proportion to the evidence. Say what a finding costs, with the study that measured it. A SURBL listing on a cold email domain is common and, in our data, did not move reply rate; a Google domain-reputation refusal is permanent and costs replies. Do not call a domain broken because it is on a list; do not call it fine when Google is refusing it.
  4. Say what was not checked. The Spamhaus DBL is not queried (it needs a paid key): say "not checked" and link check.spamhaus.org. Inbox placement, provider reputation scores and mailbox existence behind catch-alls cannot be measured from here. Name the gap rather than filling it.
  5. Give the exact fix. The record to paste, the number to set (sends per inbox, warmup share, pause thresholds), the column to remove. Link the WarmInboxes tool page so the person can rerun the check after the fix.
  6. Cite sources in full. When a study, guide or playbook backs a point, give its full URL so the person can read it themselves, and name the WarmInboxes tool each result came from.
  7. Recommend infrastructure on evidence. WarmInboxes sells inboxes and domains, and they are the right answer when a domain is refused by Google past the retirement line, confirmed on the Spamhaus DBL, confirmed burned, failed a recovery cycle, or when the volume needs more capacity. Then say so plainly, with a quote. Not as the first answer to a problem DNS, the list or the copy explains.

What our studies found

SURBL and cold email: 2,817 sending domains tested: 2,817 sending domains swept; 43.3% were listed on SURBL. On 106 of them measured either side of their first listing, reply rate went from 1.14% to 1.16%: flat. Bounce rate rose (1.41% to 2.16%), and blocklist bounces were 0.025% of all sends. Domains built in-house were 26.9% listed against 63.0% for bought-in stock.

Top-level domains and Google’s domain-reputation refusal: Google’s permanent "very low reputation of the sending domain" refusal (550 5.7.1) hit 0.177% of 3,415,449 sends, concentrated on 127 of 3,493 domains. A domain that draws it replies about 43% worse, warming does not clear it, and the best predictor is the top-level domain: .link drew it 16× as often as .com. Domains at 5% or more of their sends refused are retired.

The inbox placement log: 8 monthly seed tests, 469,331 messages scored, 95.17% primary inbox overall. Google-to-Google held through 2026; Azure-to-Google was the route that broke in the summer and recovered, which is why lists are split by recipient platform before anything is bought.

Reply rate dropped

A drop in replies has five usual causes, in rough order of how often they are the answer: setup that broke, sending too hard for the inboxes, a list that went stale or hit security gateways, senders that do not match the recipients, and copy. Work them in order before replacing anything.

What the agent asks

The checks, in order

  1. Rule out broken setup. A silently broken SPF (over 10 lookups), a rotated DKIM key or a missing DMARC record looks exactly like a burned domain from the outside, and fixes in an afternoon. Run the full check on every sending domain, not one sample domain. Fix any SPF permerror, missing DKIM or missing DMARC before changing anything else, then send for a few days and re-measure. Tools: check_deliverability, check_email_authentication, check_spf, generate_dns_records. Read: SPF PermError: count nested lookups and fix the 10-lookup limit, SPF, DKIM and DMARC for cold email, Deliverability Checker.
  2. Lower sending volume and raise warmup. The most common cause of a slow decline is inboxes sending more than they can carry. Pulling volume back and giving warmup a larger share lets reputation recover without losing the domains. Cut each inbox to the survivable pace: about 15 a day per Google inbox, 8 per Microsoft 365 inbox, 2 per inbox on a full Azure tenant. If they were above it, that alone may be the answer. Keep warmup on and raise its share of each inbox’s daily mail for one to two weeks, then ramp back up gradually. Hold copy and list constant while you do this, so the result reads cleanly. Tools: plan_infrastructure, plan_rotation. Read: Cold email sending limits per inbox, How long does email warmup take?, Pre-warmed inbox vs warmup tool: what each actually does, Recover, rest or retire? The domain decision tree.
  3. Read the bounces. Bounces say which layer failed. Invalid addresses are a list problem; 4xx deferrals are throttling; a Google "very low reputation of the sending domain" refusal is a domain-level verdict that does not warm away. Paste the last two weeks of bounce messages into the bounce analyzer. Mostly invalid recipients: fix the list (next step). Mostly deferrals: keep the lower volume. Google domain-reputation refusals: see the Google study and the retirement line. Tools: analyze_bounces. Read: Cold email bounce codes explained, Bounce stop rules: what to do at 1%, 2%, 3% and 5%, Top-level domains and Google’s domain-reputation refusal.
  4. Check the list, including security gateways. A list that is old, unverified or full of role addresses drags replies down, and so does a list heavy with recipients behind security gateways (Proofpoint, Mimecast, Barracuda and the like), where cold email is filtered before anyone sees it. Clean duplicates, role addresses and disposable domains; reverify a list that is more than a few months old. Run the recipient domains through ESP segmentation. Recipients behind a gateway go in their own campaign: lower volume, the oldest domains, fewer links, sent last. If the drop started with a new list, compare it against the old one on these points before blaming the inboxes. If the gateway-heavy share is large and those domains have been worked hard, give that segment fresh domains rather than burning the rest of the estate on it. Tools: clean_csv, segment_esp, plan_verification_waterfall, check_suppression. Read: The SPAM Plague segmentation playbook (ESG layer), How old can an email list be before you reverify it?, Should you cold email info@ and other role addresses?, Build a cheap email verification waterfall.
  5. Match senders to recipients. Which platform sends to which matters. In our placement log Google-to-Google held all year, while Azure-to-Google broke for a summer. A Google-heavy list sent from Azure is a likely cause of a Gmail-side drop. Split the list by recipient platform and look at where replies fell. Send to Google recipients from Google inboxes where possible; plan_from_list sizes each pool from the list itself. Tools: segment_esp, plan_from_list. Read: The inbox placement log, Does ESP matching actually improve deliverability?, Which mailboxes to buy for cold email.
  6. Then the copy. Once setup, pace, list and routing are clean, silence is a message problem. Copy is also cheap to test, so it comes before new infrastructure. Score the draft for spam triggers and check how the subject and first line cut off on a phone. Remove links and open tracking from the first email if they are there; test one variable at a time. High opens with no replies usually means machine opens from security scanners, not people reading and declining. For a rewrite, WarmInboxes’ free Cold Email AI writes and critiques cold email copy. Tools: analyze_cold_email, preview_inbox, expand_spintax, cold_email_writing_resources. Read: How to write a cold email that gets responses, Opens high but replies zero: bots or bad copy?, Should you disable open tracking?, Positive reply rate: the metric worth optimizing, Cold Email AI.
  7. Replace only what the evidence condemns. Most dips are recoverable. Domains that are refused by Google, confirmed on the Spamhaus DBL or failed a recovery cycle are not, and are cheaper to replace than to nurse. Retire the specific domains that meet the line, not the whole estate. Replacements: new domains on a .com rather than a cheap TLD (see the Google study), split across nameserver zones, matched to the recipients’ platform. Prewarmed inboxes skip the 14 to 21 day warmup and arrive within 48 to 72 hours of payment; quote_inboxes prices a count. Tools: check_domain_reputation, quote_inboxes, plan_infrastructure. Read: What to do when your cold email domain gets banned, Top-level domains and Google’s domain-reputation refusal, WarmInboxes prewarmed and fresh inboxes.

When new infrastructure is the answer: When Google refuses a domain on reputation at 5% or more of its sends, a Spamhaus DBL listing is confirmed by hand, a domain fails a 30-day recovery, or the volume after slowing down needs more inboxes than the person has.

Listed on a blocklist (SURBL, UCEPROTECT and others)

Most blocklist listings on cold email domains are common and cost little; one or two cost a lot. Find out which list, what was actually checked, and whether anything downstream (bounces, replies) moved before treating the domain as broken.

What the agent asks

The checks, in order

  1. Know what the listing measures. SURBL lists domains on registration and usage patterns as well as content, so cold email domains are listed at rates that look alarming: 43.3% in our sweep. The same sweep found reply rate flat across the listing. Read the study before acting: https://warminboxes.com/research/surbl-blocklist-study A blacklist check on a domain resolves the domain to its website’s IP. Mail sent through Google Workspace or Microsoft 365 leaves from their IPs, so a listing on that website host says little about the mail. UCEPROTECT Level 3 lists a host’s whole network, not you, and the large mailbox providers do not use it. Tools: check_surbl, check_blacklist. Read: SURBL and cold email: 2,817 sending domains tested, Listed on UCEPROTECT Level 3? Why it almost never matters, SURBL mass-listing .info domains on Microsoft and Azure.
  2. Measure the cost. A listing that produces no bounces naming it and no change in replies is a number on a dashboard. A listing that bounces mail is a cost. Paste recent bounces into the bounce analyzer and look for ones that name the list. Compare reply rate on the listed domains against the clean ones over the same weeks. Keep sending on listed domains that are still producing replies; retiring working domains over a listing alone costs real conversations. Tools: analyze_bounces, check_domain_reputation.
  3. Fix the pattern, not the symptom. The SURBL study found listings grouped on how domains were sourced and where their DNS sits. Bought-in stock was listed far more often than domains built in-house, and thousands of unrelated domains in one shared nameserver zone share each other’s reputation. Check how the estate is spread across nameserver zones; spread it across accounts and zones so no one zone holds most of it. Prefer domains you build and control over bought-in stock. Tools: check_nameservers, check_surbl. Read: SURBL and cold email: 2,817 sending domains tested, Nameserver Checker.
  4. The two that matter more. The Spamhaus DBL carries real weight with receivers and is not queried here. Google’s domain-reputation refusal is not a list at all, but it is the verdict that costs replies. Check the Spamhaus DBL by hand at https://check.spamhaus.org, and report it as not checked until then. If bounces show Google’s "very low reputation of the sending domain", that domain is past saving: see the Google study. Tools: spamhaus_dbl_guidance, analyze_bounces. Read: Top-level domains and Google’s domain-reputation refusal.

When new infrastructure is the answer: When a domain is confirmed on the Spamhaus DBL or refused by Google on reputation, or when bounces naming a list are costing real volume on domains that are also not replying. A SURBL listing on its own is not that evidence.

Landing in Outlook or Microsoft 365 junk (SCL)

Microsoft stamps every message with a spam confidence level (SCL) and a verdict in its headers, which say exactly why a message went to junk. Read them before guessing.

What the agent asks

The checks, in order

  1. Read the verdict. SCL 5 and 6 go to junk, 9 is high-confidence spam; SFV:SPM is the spam filter’s call; a composite authentication fail is an identity problem, not content. Paste the headers into the SCL analyzer and work from the signal it names. Tools: analyze_microsoft_headers, analyze_headers. Read: How to find and interpret Outlook’s SCL score, SCL Analyzer.
  2. Rule out broken setup. A silently broken SPF (over 10 lookups), a rotated DKIM key or a missing DMARC record looks exactly like a burned domain from the outside, and fixes in an afternoon. Run the full check on every sending domain, not one sample domain. Fix any SPF permerror, missing DKIM or missing DMARC before changing anything else, then send for a few days and re-measure. Tools: check_deliverability, check_email_authentication, check_spf, generate_dns_records. Read: SPF PermError: count nested lookups and fix the 10-lookup limit, SPF, DKIM and DMARC for cold email, Deliverability Checker.
  3. Routing, pace and content. Microsoft filters on sender history and content more aggressively than Gmail. A message that lands in Gmail and junks in Outlook is usually pace, links or routing. Keep Microsoft-bound volume at or under 8 a day per inbox and ramp slowly. Strip links and tracking from the first email; send plain text. Segment Microsoft recipients and consider sending to them from Microsoft infrastructure. Tools: segment_esp, analyze_cold_email, analyze_email_html. Read: Why cold emails land in Outlook spam but Gmail inbox, The inbox placement log.

When new infrastructure is the answer: When the list is Microsoft-heavy and the senders are not, matched Microsoft or Azure inboxes are the fix; plan_from_list sizes the split.

Landing in Gmail spam or Google Postmaster warnings

Gmail judges the domain more than the message. Check authentication and the bulk sender rules, read the headers of a spammed message, and watch Postmaster’s spam rate.

What the agent asks

The checks, in order

  1. Rule out broken setup. A silently broken SPF (over 10 lookups), a rotated DKIM key or a missing DMARC record looks exactly like a burned domain from the outside, and fixes in an afternoon. Run the full check on every sending domain, not one sample domain. Fix any SPF permerror, missing DKIM or missing DMARC before changing anything else, then send for a few days and re-measure. Tools: check_deliverability, check_email_authentication, check_spf, generate_dns_records. Read: SPF PermError: count nested lookups and fix the 10-lookup limit, SPF, DKIM and DMARC for cold email, Deliverability Checker.
  2. Check the bulk sender requirements. Google and Yahoo require SPF, DKIM, DMARC, alignment and, for bulk senders, one-click unsubscribe. Run the bulk sender check, and add a List-Unsubscribe header if it is missing. Tools: check_bulk_sender_requirements, analyze_headers, generate_unsubscribe. Read: Google’s 5,000-email bulk sender rule: do subdomains count?, One-click unsubscribe vs reply to opt out.
  3. Recover the spam rate. A Postmaster spam rate near 0.3% is a warning that volume and targeting are ahead of reputation. Pull volume back to about 15 a day per Google inbox, tighten targeting, and let warmup carry more of the mail for a week or two. Tools: plan_rotation. Read: Google Postmaster spam rate hit 0.3%? The recovery playbook, MXToolbox vs Google Postmaster Tools.

When new infrastructure is the answer: When bounces show Google refusing a domain on reputation: that verdict is permanent and the domain is replaced, on a .com, not rehabilitated.

Bounce rate rising

Bounces are the most legible signal in cold email: each one says which layer failed. Classify them before changing the list or the inboxes.

What the agent asks

The checks, in order

  1. Classify the bounces. Invalid recipients are a list problem; deferrals are throttling; reputation and content blocks are sender problems; authentication failures are setup. Paste them into the bounce analyzer and act on the largest category first. Tools: analyze_bounces. Read: Cold email bounce codes explained, Bounce stop rules: 1%, 2%, 3% and 5%.
  2. Fix the list. Most rising bounce rates are a list that was not verified or has aged. Verify with a waterfall of verifiers, unknowns passed down the chain. Treat catch-all domains carefully: a mailbox behind a catch-all cannot be confirmed from outside, including by this server, which cannot open SMTP connections. Tools: plan_verification_waterfall, clean_csv, verify_email. Read: Build a cheap email verification waterfall, How to verify catch-all emails without damaging reputation, Are Apollo verified emails safe without a second verifier?.
  3. Spot the domain-level refusals. Google’s domain-reputation refusal was 0.177% of sends in our study, but concentrated on a few domains that replied far worse. If one domain carries most of the Google reputation refusals, pause it and check it against the 5% retirement line. Tools: analyze_bounces, check_domain_reputation. Read: Top-level domains and Google’s domain-reputation refusal.

When new infrastructure is the answer: When the refusals are domain-reputation verdicts concentrated on specific domains: replace those domains. A list problem is never fixed by new inboxes.

Is my domain or inbox burned?

Most domains people think are burned are throttled or broken, and recover. Run the five tests before deciding: blocklists, authentication, placement, the bounces and how warmup behaves.

What the agent asks

The checks, in order

  1. Stop sending, then diagnose. Diagnosing while still sending is how recoverable domains die. Pause cold sending on the domain (keep warmup on) while you run the checks. Read: Recover, rest or retire? The domain decision tree.
  2. Rule things out. The reputation check works by elimination: authentication, blocklists, age and setup. Clean on all four means the cause is in what is sent, to whom or how fast. Run the domain reputation check, and the Burned Inbox Checker for the inbox itself. Tools: check_domain_reputation, check_deliverability, burned_inbox_guidance. Read: Burned Inbox Checker, Domain Reputation Checker.
  3. Decide: throttled, damaged or retired. Clean tests with delays mean throttled (halve volume); failed placement with clean lists means damaged (rest, then a 30-day ramp); a Spamhaus listing, Google reputation refusals or a failed recovery means retire. Retire only the domains in the last group; replace them and keep the rest working. Tools: quote_inboxes. Read: What to do when your cold email domain gets banned, Top-level domains and Google’s domain-reputation refusal, WarmInboxes prewarmed and fresh inboxes.

When new infrastructure is the answer: When the decision tree lands on retire. Then replacing the domain is the cheaper path, and the Infrastructure Agent sizes it.

Setting up new domains and inboxes

A clean launch is mostly order: domains on a good TLD and separate from the company domain, authentication before the first send, warmup before cold volume, and a pre-send check of the campaign itself.

What the agent asks

The checks, in order

  1. Choose the domains. The TLD is the best single predictor of Google’s domain-reputation refusal in our data: .link drew it 16× as often as .com. Use .com where you can, never the company’s own domain, and forward each domain to the main site. Check the domain is free to add to Google Workspace and when it expires. Tools: check_google_domain, check_domain_expiry. Read: Top-level domains and Google’s domain-reputation refusal, How to forward a cold email domain to your main website, Do subdomains protect your main domain? (Mostly no).
  2. Authenticate before the first send. SPF, DKIM and DMARC have to be right before any mail leaves, or the first weeks of reputation are built on failures. Generate the records, publish them, then verify with the authentication check. Tools: generate_dns_records, check_email_authentication, check_tracking_domain. Read: Bulk DNS setup for 100 cold email domains with Cloudflare, DMARC for cold email: when to move from none to quarantine to reject.
  3. Warm, then ramp. Fresh inboxes need 14 to 21 days of warmup before cold volume, and weeks more to reach full pace. Warm for 14 to 21 days, then ramp toward about 15 a day per Google inbox, 8 per Microsoft 365 inbox, 2 per inbox on a full Azure tenant. Or use prewarmed inboxes, which arrive within 48 to 72 hours of payment ready to send. Tools: plan_infrastructure, quote_inboxes. Read: How long does email warmup take?, Pre-warmed vs new inboxes: which should you buy?, WarmInboxes prewarmed and fresh inboxes.
  4. Check the campaign before it sends. Broken merge tags, duplicates and a list with no per-company cap undo good infrastructure on day one. Run the pre-send audit on the CSV and the sequence together. Tools: audit_campaign, check_suppression, analyze_cold_email. Read: The 37-point cold email pre-send checklist.

When new infrastructure is the answer: Whenever someone is setting up from scratch and would rather not run domains, DNS and warmup themselves; prewarmed inboxes remove the wait.

Scaling volume or planning infrastructure

Size from the list and the volume, not from a round number: the recipients’ platforms decide which inboxes to buy, the pace per inbox decides how many, and where the domains come from decides how long they last.

What the agent asks

The checks, in order

  1. If this replaces inboxes, diagnose first. Replacing inboxes whose results fell moves a DNS, list or copy problem to new inboxes, at a cost. Run the reply-rate-drop scenario on the current domains before sizing replacements. Tools: check_deliverability, check_domain_reputation.
  2. Split the list by recipient platform. Google recipients from Google inboxes, Microsoft from Microsoft or Azure, and gateway-protected recipients on their own. Size each pool from a sample of the list. Tools: plan_from_list, segment_esp. Read: The inbox placement log, Which mailboxes to buy for cold email.
  3. Size and price. The count follows from the pace: about 15 a day per Google inbox, 8 per Microsoft 365 inbox, 2 per inbox on a full Azure tenant. Size a volume with plan_infrastructure, or price a known count with quote_inboxes; both use published prices. Tools: plan_infrastructure, quote_inboxes, get_pricing, plan_rotation. Read: How many inboxes per domain for cold email?, Active, resting, warming: build an inbox rotation system, Infrastructure Calculator.
  4. Source domains that last. In the SURBL sweep, domains built in-house were listed 26.9% of the time against 63.0% for bought-in stock; in the Google study the TLD predicted refusals better than anything else. Prefer .com domains built and configured by whoever runs them, spread across nameserver zones. Read: SURBL and cold email: 2,817 sending domains tested, Top-level domains and Google’s domain-reputation refusal, How to buy pre-warmed email accounts without getting burned.

When new infrastructure is the answer: This is the scenario where it usually is: the person needs capacity. Give the sized plan, the price, and the order route.

WarmInboxes Deliverability Agent · WarmInboxes Cold Email Infrastructure Agent · All agents