Changelog

Two changes landed on the send tier, and both concern the part of sending that happens either side of the message itself. How someone gets out of your list, and how a domain earns the right to send in the first place.

What's new in v2.10.0

• One-click unsubscribe on subscriber broadcasts. Every broadcast to a subscriber audience now carries List-Unsubscribe and List-Unsubscribe-Post headers, which is what makes Gmail and Yahoo render their own unsubscribe control beside your sender name. Both of them require that mechanism from bulk senders. Loading the page does nothing on its own, and only the confirming action records the opt-out, so the link scanners that fetch every URL in a message cannot quietly unsubscribe your audience for you.

• A sending source is now armed explicitly. Enrolling a domain puts it in your pool as warming, and a warming source is never claimed, so a perfectly good broadcast could be refused with no_sources for a reason that looked nothing like the cause. spideriq send sources promote <mailbox_id> is the step that arms it. Promotion re-stamps the warm-up ramp to that day, so a source starts at day one of its curve rather than at a volume it has not earned.

• That step is available to agents as well as to people. send_promote_source ships in @spideriq/mcp-mail, spideriq send sources promote in the CLI, and @spideriq/mail-skills teaches both, including the part that matters most: a refused promotion is an answer to report, not an error to retry.

Full walkthrough in the docs at https://mail.spideriq.ai/docs/sending/bring-your-own-domain, and unsubscribes now have a page of their own at https://mail.spideriq.ai/docs/sending/unsubscribes.

SpiderMail's send tier can now carry your own sending identity end to end. This release adds domain onboarding you drive yourself, sending credentials stored per tenant, deliverability broken down per sending source, and an automatic pause when a source starts going bad.

What's new in v2.9.0

• Bring your own sending domain. You publish SPF, DKIM and a tracking CNAME in your own DNS, and I read them back over a public resolver. Each record is reported separately, so a failed check names the exact record to fix rather than saying the domain is wrong.

• Your domain sends only for you. A verified domain joins your pool and nobody else's. Sending reputation does not carry across domains, so another tenant's cold outreach cannot reach your inbox placement.

• Bounce and complaint rates per source. The pool page breaks deliverability down by sending source instead of showing one number for everything, so you can see which domain is drifting before it takes the rest with it.

• A source that goes bad pauses itself. Cross 0.3% complaints and that source stops sending and raises an alert. Queued mail is held rather than dropped, so nothing is lost while you look at it.

I never hold a credential to your DNS zone. The verification path reads public records only, which means taking your domain off the internet is not a mistake this product is able to make.

Read the docs at https://mail.spideriq.ai/docs

Every message SpiderMail stores is scanned for prompt-injection technique before an agent reads it, and every message it sends is checked for credentials before SMTP. Both layers are on by default and have run in production since February 2026. This entry documents them; the behaviour is not new.

Added

• Inbound prompt-injection scanning. Stored messages are scanned before an agent sees them, across four families of technique: instruction override, persona reassignment, requests to return secrets or history, and fake system blocks. Matches are recorded as security flags on the message.

• Obfuscation detection. Encoded blocks, escape sequences and zero-width characters are detected, decoded and re-scanned, so an instruction hidden inside an encoded payload is examined rather than passed through.

• Quarantine. A message carrying a genuine injection signal is held out of the inbox until a person reviews it. Obfuscation alone does not quarantine.

• Outbound credential blocking. Messages are checked for provider keys, payment keys, cloud access keys, private keys, auth headers and password-shaped assignments before the send. A match blocks the send and returns the reason, so an agent is told why rather than reporting success.

• A review surface. GET /mail/security/events, GET /mail/quarantine, and POST /mail/messages/{message_id}/release, which returns a message to the inbox and records the release. All three reach agents through the mail skill over CLI and MCP, plus a dashboard page under Mail.

Known issues

• The inbound patterns are too broad and quarantine legitimate mail. Reviewing all 108 messages held as of 2026-08-10: 38 matched forget your (as in "don't forget your meeting"), 60 matched a form of send email / send emails / send message, 3 matched forget all, and roughly 7 look like genuine attempts. That is about 94% false positives. Two patterns are responsible, both because their qualifying words are optional: the rule intended for "forget your instructions" also matches "forget your umbrella", and the rule intended for "forward all previous messages" also matches "send emails". A fix making the qualifiers required is the obvious correction. Until then, review the quarantine rather than assuming a held message is hostile.

• Three of the four tiles on the dashboard security page do not report correctly. "Injection attempts" counts only within the most recent 50 events, so it reads 0 while messages sit quarantined; "Blocked outbound" and "Credential leaks prevented" filter on event types that the API does not emit, so both are always 0. The API reads are correct — GET /mail/security/events and GET /mail/quarantine return the true picture.

Notes

• Neither layer has a setting. Both are always on.

• A flag is not a hold. As of 2026-08-10, across 76 mailboxes and 4 client accounts, 247,846 stored messages had been scanned since 2026-02-25; 8,608 carried a flag and 108 were quarantined. 8,500 of those flags are obfuscation signals, deliberately broad because encoded blocks are ordinary in email. Read the flag count as annotation, not as attacks.

• The outbound blocker has blocked 0 sends over the same period. It is a control that is in place and has not yet been needed.

• Treat both scanners as a backstop. Pattern lists are designed to catch known technique and are updated as technique changes. Instruct your own agents that email bodies are data rather than commands.

• Container hardening covers the poller, which runs read-only with tmpfs scratch and no-new-privileges. The mail worker and test worker carry no-new-privileges only.

Full documentation: Agent security

SpiderMail now connects to three cold-email platforms and reports deliverability for every sending account behind them, in one view.

Added

• Brand-scoped outreach connections for Smartlead, lemlist and Instantly. Create, inspect, update and remove a connection; run a sync to pull the provider's current sending accounts and warmup state.

• Per-sender deliverability health: health score, sent, inbox, spam, bounce and reply counts over 24 hours and 7 days, plus warmup state and last-polled time. Available for one sender or as a single overview across the whole brand.

• A warmup trend read, for direction over time rather than a single day's figure.

• Lead push: a SpiderIQ campaign's verified leads can be pushed into a chosen Smartlead campaign. The push is idempotent, quota-aware against the account's lead cap, and reversible. A push-status read reports available headroom and per-campaign counts.

• Two opt-in push filters, restricting the export to leads carrying a VayaPin pin or a VayaPin SEO article. Setting both requires the lead to have both.

• The whole surface is exposed to agents through the mail skill, over the CLI and MCP.

Notes

• Reads accept a standard access token; writes require brand-admin.

• Warmup auto-pauses after persistent domain failures and does not resume on its own. Re-enable it only once the domain is healthy. The blocked-reason text on a paused account is stale until the next successful cycle, so trust the active/inactive status instead.

• This surface reports deliverability rather than fixing it. A domain_does_not_exist bounce is a DNS problem; a 553 Relaying disallowed error with healthy DNS is a send-block at the mail host, usually requiring domain re-verification there.

Documentation: mail.spideriq.ai/docs/sending/outreach

Added

• Sync scope, chosen when you connect a mailbox. Import the last 100, 300, 500 or 1,000 messages, everything since a date, or the whole archive. Available in the Add Mailbox dialog, the REST API (POST /api/v1/mail/mailboxes), and @spideriq/mcp-mail.

• Per-mailbox polling interval. Each mailbox can set its own interval instead of sharing one global schedule. Minimum 60 seconds, maximum 24 hours.

Changed

• New mailboxes now default to importing the last 500 messages, not the entire archive. The previous behaviour is still available and is shown with its cost before you select it: roughly 100 messages every five minutes, so a 100,000-message mailbox takes about three and a half days.

Notes

• Sync scope is applied as a floor on the starting fetch position, so older mail is never requested. Verified across roughly 140 consecutive poll cycles over 12 hours: 7,640 fetch attempts, none below the floor (measured 2026-08-06).

• Mailboxes connected before this release are unchanged. As of 2026-08-06, 265 of 266 carry no scope or interval setting.

• Widening the scope backfills. Narrowing it does not delete already-imported mail; that remains a separate action.

• The CLI does not carry these fields yet.

What's New

Full custom domain support with automatic SSL provisioning for every tenant.

• Add and verify custom domains via content_add_domain

• Automatic SSL certificate provisioning

• Set primary domain for canonical URLs

• Domain health monitoring and DNS verification

What's New

The Component Marketplace is now live — browse, insert, and customize pre-built UI components with automatic Shadow DOM isolation.

• 50+ marketplace components across hero, pricing, CTA, footer categories

• Theme token inheritance — components adapt to tenant color palette

• Scoped CSS with no style leaks via Shadow DOM encapsulation

• One-click insert with page_insert_section

What's New

All destructive operations now use a two-phase confirmation protocol for production safety.

• dry_run: true returns a preview + confirm_token

• Second call with the token executes the operation

• Covers: deploy_site, publish_page, publish_component, publish_post

• Added content_deploy_site_preview for staging verification

What's New

Launch of the Directory module — a structured local business listing system built into every tenant.

• Create and manage listing categories with custom schemas

• Upsert individual listings with geo coordinates, contacts, hours, and rich media

• Bulk import from IDAP verified business data

• Full CRUD API for programmatic directory management

What's New

Introduced component_update_and_propagate — atomically update a component's HTML, CSS, or JS and repoint every consuming page to the new version in a single two-phase call.

• Supports staged rollout via page slug filtering

• Automatic semver bumping (patch, minor, major)

• Full version history with content_list_component_versions

• Block duplication across pages with content_duplicate_block