Tools

• Ten more of the free tools can be run by an AI assistant over the MCP server, taking it from 32 of the 55 to 42: the Header Analyzer, DMARC Alignment Checker and Unsubscribe Header Checker (analyze_headers), the Gmail Clipping Checker and Link & Pixel Scanner (analyze_email_html), the DMARC Report Analyzer (analyze_dmarc_report), and the Email Authentication, Domain Reputation, Tracking Domain and Bulk Sender checkers, each as one call. They run the pages’ own code, so an assistant gets the answer the page gives. /for-ai
• The Claude, ChatGPT, Cursor and other assistant logos on the tools page each open that assistant with a starter prompt, or install the MCP server where the client allows it. the tools page

For AI agents

• The free MCP server can now find things, not only check them. find_lead_lists searches the free leads database with the same search the leads page uses; find_tools says which free tool does a job and whether it can be called from the server or only on its page; find_resources searches the guides, playbooks, studies, recipes, videos and inbox guides; get_pricing returns the price list. The server went from 23 tools to 27. /for-ai
• Every tool result now leads with a credit line in the assistant’s voice, naming the tool and its page (“I used WarmInboxes’ free SPF Checker for this”), and the server asks assistants to repeat it. Lead lists are always handed over as the list page: an assistant is told never to request one for the person.
• Claude and ChatGPT connect in one click from the tools page: the Claude link opens its Add custom connector dialog with the name and URL filled in, and ChatGPT’s opens its Plugins page with the URL copied and every form field shown to copy. The server now answers OAuth discovery with a 404, which is what made ChatGPT report it “couldn’t discover OAuth settings” for a server that needs none. the tools page
• Every one of the 57 tools in the catalogue now has an MCP status, the tool that runs it or the reason it runs only on its page, and the build fails on a tool with neither.

Pages

• October’s placement test is in the log: 135,600 messages scored, 94.47% to the inbox, Google into Google at 94.34% and Azure into Google back at 97.99%. The month count, the message total and the dataset window now derive from the log, so the next month cannot leave a stale seven behind. the placement log

Corrections

• The Claude, ChatGPT and Grok inbox pages said our warmup keeps running underneath the agent’s sending. It does not by default: an agent sends but does not warm, so the pages now ask you to tell us the inboxes are going to an agent, and either run an external warmup tool or we keep them in our warmup pool for free. /claude-inboxes
• The agent, sequencer and partner pages, the product comparison and price.md said replacement inboxes come with every order when deliverability drops. They do not: the 7-day placement replacement guarantee replaces an eligible inbox that misses the placement standard in its first week, and after that what comes with every order is the free deliverability tools. All of them now say so. price.md
• The Tracking Domain Checker read SURBL’s answer from the wrong place, so a tracking domain listed on SURBL was reported as not listed, and its IP blocklist row asked the blacklist lookup the wrong question and only ever said it had not answered. Both are fixed; the Link & Pixel Scanner, which had the same misread and showed every domain as unknown, is fixed with them. /tracking-domain-checker
• Every call through the free MCP server was being counted against one shared daily limit for all assistants everywhere, rather than each caller’s own. Each caller now has their own. /for-ai
• llms.txt described the verify-email endpoint as SMTP-level verification with catch-all detection. It is syntax, MX, disposable and role checks; no SMTP connection is opened, so a catch-all domain comes back valid. It now says so. llms.txt
• The DMARC Checker marked p=none as a failure and p=quarantine as a warning, and the deliverability grade docked p=none, so every cold email domain set up the way Google and Yahoo ask was told it was broken. p=none with reporting now passes: monitoring is enough for broad cold email, and p=quarantine is named as the step for stricter enforcement. The authentication, reputation and bulk sender checkers, the record generator and the offer page now say the same. /dmarc-checker
• The offer page promised “warm inbox placement guaranteed” while the Terms say inbox placement is not guaranteed. What we guarantee is a replacement: the 7-Day Placement Replacement Guarantee replaces an eligible newly delivered inbox that misses the placement standard in its first seven days, at no charge, and the offer page, price list, comparison data and inbox pages now say that and say placement itself cannot be guaranteed. It also no longer promises new inboxes the same day when infrastructure breaks mid-campaign. /offer
• Delivery is stated once. Calls to action across the site still said “send today”, “get live today”, “the day you sign up” and “dropped in the same day” while every order takes 48 to 72 hours. They now say what is true, and a delivery table by product, from one source, is on How It Works, For AI, llms.txt, price.md and facts.json. the delivery table
• The offer page said no other provider offers Azure tenants. Others do; it now says we are one of the few offering prewarmed Google, Microsoft 365 and Azure from one platform. It also no longer says every other provider charges for domains and makes you wait four weeks. /offer
• The homepage said “Built and endorsed by” above a list of certifications and partnerships, and llms.txt said “endorsed by” too. None of those companies has endorsed us; they are credentials, and both now say so. the homepage
• The homepage served to crawlers described the Deliverability Checker as testing inbox placement rate. It grades SPF, DKIM, DMARC, MX, blacklist status and domain age; it sends nothing. Inbox placement is what the placement log measures. /deliverability-checker
• The guide count read 102 in some places and 101 in others. It is 101, counted from the blog registry, and the build now fails if a page says otherwise. A new /facts.json carries every count the site states. /facts.json

Technical

• The build now fails on claims the site must not make again: same-day or send-today delivery, “endorsed by” a platform, “not resellers”, a placement guarantee, no other provider, and a placement test where there is none. Each was live once beside its own contradiction.

Corrections

• Delivery is 48 to 72 hours from payment, on every page. The offer page and the three platform pages said "same-day delivery, order by 3pm"; /how-it-works, the recipes and the planner said 48 to 72 hours. Prewarmed means no warmup wait once they land, which is what the pages say now. /how-it-works
• "The only provider covering Google, Microsoft 365 and Azure" is not something we can know. It reads "few providers" now, in seven places.
• The offer page said "we are not resellers" while the Terms say "authorised reseller of Google Workspace and Microsoft 365". Both meant "operators first", which is what it says. /offer
• The free prewarmed domain was advertised as "this week only, first 50 orders" under a price list that includes it with every order. The scarcity is gone.
• The tools hub showed 54 cards against a count of 55, because Cold Email AI was in the catalogue and in no category. The blog said "All (129)" against 132 posts because featured posts were not counted. Both match now. the tools hub

Pages

• Nine articles rewritten to the 2026 standard: what deliverability is, SPF/DKIM/DMARC, infrastructure setup, why mail goes to spam, the ten mistakes, templates, send timing, personalisation, and GDPR. Each says what can and cannot be seen, uses the paces we run (about 15 a day on Google, 8 on Microsoft), and carries no figure we cannot source. the deliverability guide
• Thirty articles from January and February 2025, each under 1,100 words and several advising 50 to 100 sends per inbox a day, now 301 to the article or page that answers the same question. The guide count is 102. /blog
• The changelog index is titled "WarmInboxes Changelog" and the footer groups its links by subject, with one link per thing. /changelog
• Provider comparisons: WarmInboxes against Zapmail, InboxKit, Primeforge and Mailforge on the same thirteen criteria. Our column is checked against the price list at build time; a competitor cell is filled only from its own pages with the date, and says "not yet verified" until then. /compare
• Inbox pages for Smartlead, EmailBison, Apollo and ManyReach, each with its own angle: client isolation, the API hand-off, sending off the company domain, and rotation at scale. /smartlead-inboxes
• Inbox pages for Claude, ChatGPT and Grok: account-based outreach run by an agent rather than a sequencer, one researched email per person. Each covers connecting the mailboxes through the agent’s own Google Workspace or Microsoft 365 connection, so the agent writes, schedules and sends from them, sizing the fleet, and where the daily limit has to live when the sender is an agent. /claude-inboxes
• An about page and an author page. Every article’s Person node now points at /authors/huzayfa-majeed, which carries the profiles, the certifications and the body of work. /about
• The data behind all three studies is downloadable as CSV and JSON under CC BY 4.0, written by the build from the same files the pages compute from, and declared as Dataset distributions in each study’s schema. /research
• Fifteen tool pages carry a short video demonstrating the tool, and each video has a watch page of its own under /videos where it is the main content, with the VideoObject and the video sitemap pointing there. The tool page had been named as the watch page, and Search Console called every one "not a watch page", which is its name for a video that sits under a few screens of something else. Every tool page is wired for a demo, so the rest appear as the shorts are published. /videos
• The footer is five columns by what a reader is doing: inboxes and the provider comparisons, the six sequencer pages, developers with the machine-readable files, the deliverability library, and company. The tools directory under it now lists every tool from the same catalogue the hub renders, so it cannot fall behind again; it had 32 of 55. the tools hub

Technical

• Unknown paths return a 404 with a noindex head instead of the homepage under a 200. An indexed /blog/[object Object], left over from a footer bug fixed on 8 October, returns 410. Two older "410" rules that had never worked were fixed in the same change.
• When a route chunk fails to load after a deploy, the page shows its prerendered content under a reload notice instead of an error screen, so a rendering crawler indexes the page it was sent.
• A build check now fails if any route in App.tsx is neither prerendered nor redirected.
• The build type-checks the app and its build scripts before bundling. It never had: the root tsconfig checked no files, and 240 errors had collected behind it, 200 of them an unused React import. All cleared, and the three CommonJS calculation modules the pages share with the API now carry type declarations.
• The first browser tests are committed: a Playwright suite drives the DMARC report analyzer with built reports, gzip, zip, a duplicate drop and three bad files, and asserts the numbers on screen. the analyzer

Tools

• MX lookup with provider and gateway identification, an email provider checker, and a bulk MX lookup for up to 2,000 domains with a CSV out. MX lookup
• A DNS utility cluster: TXT, A, AAAA and SOA record lookups, each with the interpretation the record type needs rather than a bare answer. The TXT lookup identifies every record and reads the four underscore names a receiver uses in the same call. TXT record lookup
• Short aliases for the lookups people search by another name: /dns-lookup, /ns-lookup, /cname-lookup, /ptr-lookup. /dns-lookup
• A DMARC report analyzer that reads the daily aggregate XML in the browser; nothing is uploaded. DMARC report analyzer
• SPF lookup counter, DKIM selector finder, and an email authentication checker that runs SPF, DKIM, DMARC, MX, BIMI and MTA-STS in one pass with the optional ones marked optional. Email authentication checker
• Two header readers: a DMARC alignment checker and a one-click unsubscribe checker (RFC 8058, as Google and Yahoo enforce it). DMARC alignment checker
• Reverse DNS lookup with forward confirmation (FCrDNS) for IPv4 and IPv6, and an IP reputation checker that reports findings rather than an invented score. Reverse DNS lookup
• A tracking domain checker, a Gmail clipping checker, and an email link and pixel scanner that parses HTML inertly so a pasted message cannot fire its own pixel. Tracking domain checker
• A bulk sender requirements checker for the Gmail, Yahoo and Microsoft rules, split into what DNS can settle and what no external tool can see. Bulk sender requirements checker
• A domain reputation checker built as an elimination rather than a grade: listed, broken, too new, or nothing visibly wrong — and what each verdict rules out. Domain reputation checker
• The DKIM checker now tells a delegated-but-unpublished key apart from a missing one, which is the single most common Microsoft 365 DKIM failure and was being reported as "try a custom selector". DKIM checker

For AI agents

• The public MCP server at /mcp went from 20 tools to 23: lookup_txt, check_rdns (which had been deployed and reachable by nobody), and plan_from_list. /for-ai
• plan_from_list is the playbook’s "ideal agent flow" as one call: a recipient list and a daily target in, a costed fleet split into a Google pool and an Azure pool out, with the handoff to the authenticated server at the end. the tool table
• A /developers page documents the transactional API and MCP server the way a deployment platform documents deploys: the user creates the account, the account issues the key, then the assistant connects. Preview before place; never ask for a sequencer password. /developers
• The transactional API reference is published on this site at /transactional-api.md, verbatim, with docs.warminboxes.com authoritative if the two ever differ. /transactional-api.md
• The public MCP server’s own instructions now tell an assistant that every tool is read-only, name the actions it will not find, and say where to send the user instead of "that cannot be done".
• The ChatGPT plugin manifest had three pointers to files that did not exist; all three now resolve.

Pages

• Six infrastructure recipes: fixed, costed plans for common sending volumes, every figure checked against the planner at build time. /recipes
• A How It Works page, and long-form setup pages for Instantly and PlusVibe. /how-it-works
• ChatGPT and Claude added to the integrations, since more inboxes are being driven by them. integrations

Corrections

• Three pieces of copy claimed the Spamhaus DBL was checked. It is not — it needs a paid query key — and one of the three was a pass verdict telling people they were clean on a list nobody had queried. All three fixed; the DBL is now named as not checked wherever it is relevant.
• The 1,000-a-day recipe said the unmatched 20% of a list ride the Google pool and then split the fleet as if they did not. Corrected to the rule it states: $514 a month, not $490. the recipe
• llms.txt said the MCP server carried 15 tools while it served 22. Now checked against the real table at build time, so it cannot drift again.
• The "New" badge was on 47 of 58 tool cards, which is not emphasis. Removed.

Not built, and why

• A catch-all checker, an SMTP TLS checker and an SMTP server test. Outbound port 25 is blocked from the functions this site runs on, and a version of any of them that did not open an SMTP connection would be a false pass.

The product

• The portal is app.warminboxes.com. Orders, domains and build state, invoices, deliverability and change requests, readable and changeable from code. app.warminboxes.com
• REST API at api.warminboxes.com/v1, authenticated with a key made in the portal under Settings → API keys, with read, write and orders:place scopes that do not imply each other. the reference
• An MCP server at api.warminboxes.com/mcp, so an assistant with the user’s key can read the account, preview and place orders, and export inboxes into a sequencer. /developers
• The wib CLI: one Python file served by the API, no install. CLI
• A sandbox: a test key runs the same routes against a pretend account where nothing is charged, so an integration can be built before a live key exists.

The product

• app.upscaleb2b.com launched as an order-taking app: choose a package, place the order. No API, no automation.
• Superseded in October 2025 by app.warminboxes.com, which kept the ordering and added everything around it. the October entry