As of 2026-07-12

Cold email deliverability in 2026: what actually matters

No cold-email platform, including this one, can guarantee inbox placement. What follows is the mechanical, verifiable part: the authentication requirements that gate whether a message is even evaluated, the bulk-sender rules Gmail and Yahoo actually publish, and an honest account of what warmup does and doesn't do.

No guarantees, anywhere on this page This is not a pitch for a deliverability outcome. It's a factual explainer of the mechanics, so you (or your agent) can reason about what's actually in your control versus what Gmail/Microsoft decide unilaterally.

SPF, DKIM, and DMARC are mandatory, not best-practice

As of Gmail and Yahoo's 2024 bulk-sender requirements (still in force through 2026), a sending domain missing or misconfigured SPF, DKIM, or DMARC is commonly rejected at the SMTP level for bulk senders — not delivered to spam, not filtered, simply refused before a placement decision is ever made. This changes the failure mode from "landed in spam" to "never sent." Any cold-email setup needs all three configured correctly per sending domain, plus valid reverse DNS (rDNS/PTR records), before a single message goes out.

This platform's setup_infrastructure tool automates SPF/DKIM/DMARC/rDNS configuration for every lookalike domain it provisions and verifies the DNS before a mailbox on that domain is used — see the setup guide.

The Gmail/Yahoo bulk-sender rules

For senders delivering roughly 5,000+ messages per day to Gmail addresses, Google's bulk-sender guidelines require, in addition to authentication:

Even senders below the 5,000/day bulk threshold are, in practice, judged by the same underlying reputation signals — the published thresholds describe where enforcement is most mechanical, not where the underlying signals stop mattering.

Warmup timeline: what it is, and what it isn't

Warmup is the practice of gradually ramping a new mailbox's sending volume over roughly a 3-4 week timeline — typically from a handful of messages per day in week one to 25-40/day by week four — while a pool of other inboxes opens, replies to, and rescues warmup messages from spam. The goal is building genuine domain and IP sending history before real cold outreach volume hits it. Your first send happens on day one of this ramp, not after it — see the warmup timeline before your first send, and a domains/inboxes-per-volume calculator.

What this platform actually enforces, day by day: the ramp above isn't marketing copy here — it's a real server-side cap your agent cannot exceed, no matter how eager it is to send. Days 1-7: 5 sends/mailbox/day. Days 8-14: 15/day. Days 15-21: 25/day. Days 22-28: 35/day. Day 29+: 40/day, fully warmed. This ladder is a ceiling, not an entitlement — deliverability/health monitoring can hold a mailbox below it regardless of age (a throttled mailbox can sit at 5/day indefinitely), so the current warmupDay and dailyCap for any mailbox are visible at runtime via the infrastructure_status tool, and that live number is the one to trust, not the schedule above.

The honest limitations, stated plainly:

The strongest signal available to any sender, always, is real replies from real recipients to real campaigns — not synthetic warmup traffic. This platform bundles two mechanisms during the ~4-week ramp above: the server-enforced sending cap, and InboxKit's isolated (non-shared) warmup pool, activated automatically on every mailbox at no extra charge. The pool-signal skepticism above applies to this pool too — no neutral study confirms pool warmup lifts placement over ramp-only, so it's included because it can only help and costs the customer nothing, not because its lift is proven. Once a mailbox's ramp completes, the platform automatically cancels the pool subscription and reputation rides real sending alone. No "AI-driven" engagement layer exists, on this platform or, credibly, anywhere. Never trust a vendor claiming warmup "beats" or "bypasses" spam filters — that claim describes filter evasion, not reputation-building, and this platform does not make it.

Domain burn is a normal operating cost

Losing a sending domain to spam-block or reputation decay at a rate of roughly 8-18% per month is typical for active cold-email sending at any real volume — not a sign of a misconfigured setup. The response that actually works is structural: send from branded lookalike domains rather than your primary domain, so a burned domain is contained and replaced rather than damaging the domain your business depends on for everything else. Auto-retire-and-replace of a burning domain is treated as a routine, expected operation in this platform's design, not an incident.

The same disposal logic settles the delegated-subdomain question. A subdomain of your business domain (outreach.yourcompany.com) cannot be retired and replaced — it is welded to the domain your website and employee email run on, so retiring it in name changes nothing about the reputation it shares. Subdomains are the right tool for splitting legitimate mail streams — transactional vs marketing vs corporate — precisely because the parent domain's reputation carries over to each stream. Cold outreach inverts that property: carryover is the risk, and containment requires a domain you can throw away. That is why dedicated adjacent domains are the preferred bring-your-own path and a delegated subdomain is a distant second (domain options).

What an AI deliverability control loop can and can't do

A monitoring loop over vendor-provided signals (bounce rate, spam-complaint rate, placement-test results, warmup health) can automate the response within the rules: auto-pause a degrading mailbox, rotate sending, detect a burning domain and provision a replacement, throttle volume to what a mailbox's current health supports. What it cannot do is change how Gmail or Microsoft evaluate a sender — those are third-party, non-public decisions. Any platform, including this one, that implies otherwise is not being accurate.

Related