DEV Community: Kumar Deepanshu

AgentMail vs Lumbox for customer portal agents

Kumar Deepanshu — Tue, 20 Oct 2026 18:00:17 +0000

Originally published at lumbox.co

Choose Lumbox when you want an agent-owned inbox with a documented, bounded OTP retrieval endpoint and a paid entry plan starting at $9 per month. Evaluate AgentMail alongside it when its email allowances, platform features or existing integration fit your workflow better, because both products provide inbox infrastructure for agents.

I build Lumbox. This comparison is for startups whose browser agents log into third-party portals for customers, rather than a claim that one email service wins every workload. Pricing and documented capabilities were checked on October 3, 2026. Recheck them when making a purchase.

Compare the task before the feature list

Both products can be relevant when an agent needs its own email address. AgentMail’s quickstart shows creating an inbox and sending mail through its SDK. Lumbox exposes inbox creation, email retrieval and sending through its API and tools, documented in its inbox guide and MCP guide.

For customer portal agents, a new address is only part of the job. Existing accounts may send verification mail to a customer’s original mailbox. Neither a new inbox nor a lower subscription price automatically changes that destination. Decide whether the customer will forward relevant mail, change the account address where supported, or provide an authorized mailbox connection.

Then compare how much code your application needs between receiving that message and resuming the browser. That is the point where Lumbox’s OTP endpoint is worth evaluating directly.

A narrow, sourced comparison

Decision pointLumboxAgentMailAgent-owned inboxesAPI creates inboxesAPI and SDK create inboxesFree inbox allowance3 inboxes3 inboxesFree email allowance500 received and 100 sent per monthPricing lists 3,000 emails per monthFirst paid monthly planStarter: $9, 10 inboxesDeveloper: $20, 10 inboxesEmail allowance on that plan5,000 received and 2,000 sent per monthPricing lists 10,000 emails per monthCustom domainsListed in Starter featuresDeveloper lists 10 custom domainsMCP@lumbox/mcp-server, including get_otpPricing lists an MCP serverBounded OTP retrieval evaluated hereGET /v1/inboxes/:id/otp, up to 120 secondsVerify the current preferred extraction and waiting path in its docs

Lumbox figures come from packages/plans/src/index.ts and the pricing docs. AgentMail figures come from its pricing page. The email allowances are presented with their original definitions; a combined “emails” allowance and separate sent/received limits are not automatically equivalent.

This table deliberately does not mark every untested competitor capability as absent. A missing fact in this review is a question for evaluation, not proof that AgentMail cannot do something. It also does not compare deliverability, uptime or extraction accuracy, because no controlled benchmark was run.

What the Lumbox OTP endpoint does

After provisioning and routing, the client makes one retrieval request. The server waits up to the requested timeout for a recent verification-category message containing parsed codes. It returns code, all_codes, from, subject, expires and email_id, or HTTP 408 if no suitable result is found before the wait ends.

The default timeout is 30 seconds and the maximum is 120. The REST route accepts from and since. Without since, it looks back five minutes. These details are implemented in apps/api/src/routes/inboxes.ts and linked through the API reference.

This removes the need for a repeated polling loop in the client for that retrieval step. The server still polls its database once per second. It also does not configure forwarding, prove sender identity, reserve a code for a particular run or confirm that the portal accepted the value.

If these remaining responsibilities already exist in your application, the endpoint can be a compact fit. If you already have a reliable AgentMail integration that supplies the same workflow outcome, switching needs a stronger reason than a shorter example.

When AgentMail deserves a closer look

AgentMail’s published free email allowance is larger than Lumbox’s listed free allowances. A team testing many messages with only a few inboxes should compare that difference using its actual inbound and outbound traffic. The lowest paid subscription is not necessarily the lowest total cost for every workload.

Its pricing page also lists product features such as threads, labels, SDKs and an MCP server. Inspect the capabilities you actually need and their plan availability. If your team already understands AgentMail’s event and message model, that familiarity has practical value even though it cannot be converted into an invented savings figure.

For procurement requirements, request the relevant evidence directly from each vendor. Do not infer equivalent security assurances from similar feature names or a checkbox in a comparison article.

When Lumbox is a useful candidate

Lumbox fits an evaluation centered on inbound verification mail, especially when the application wants a parsed code from a bounded API call. It also provides send and reply, custom domains and a credential vault. Those features have distinct configuration and authorization requirements; they are not a guarantee that a complete portal login works without integration.

The $9 Starter plan gives a small team a lower subscription entry point than the AgentMail Developer plan observed here. That is a price comparison, not a claim that Lumbox is the cheapest agent email service on the market.

Test with a forwarded message from the portal you care about. Check the received sender, extracted code and classification. The parser is rules based, so template coverage matters more than a generic statement that a product “supports OTP.”

Make the decision with a reproducible pilot

Use the same authorized portal account and message templates for both candidates. Record whether mail arrives, whether your extraction path finds the correct value, and whether the browser reaches the intended authenticated state. Include a timeout and a repeated code request.

Track the integration code you maintain, active inbox count, sent and received volume, and the human steps required to onboard a customer. Keep results separate from hypotheses. A successful demonstration with one template does not establish universal portal coverage.

If your immediate blocker is email-code retrieval, start with Lumbox’s API reference and one test inbox. If AgentMail already meets the requirement with an integration you trust, keeping it can be the reasonable decision.

Kumar

Build a support inbox agent that drafts every reply for approval

Kumar Deepanshu — Tue, 13 Oct 2026 18:11:32 +0000

Originally published at lumbox.co

A lot of support email asks the same few questions: how do I change my billing email, where is my invoice, how do I cancel. The answers are already in your help docs. This post sets up a Lumbox inbox that reads each new support email, looks up the answer in those docs and in past threads, and writes a reply that waits in a queue until a person approves it.

Request and response shapes for every endpoint below are in the auto-reply agent recipe.

Point support@ at a Lumbox inbox

Custom domains need the Starter plan ($9 a month). Add the domain with POST /v1/domains. The response lists the DNS records to create (ownership TXT, MX, SPF, DKIM and DMARC), and POST /v1/domains/:id/verify checks them. The MX records route the whole domain’s mail to Lumbox, so if your root domain already receives mail somewhere else, use a subdomain such as help.yourco.com.

Once the domain is verified, create the inbox:

curl -X POST https://api.lumbox.co/v1/inboxes \
-H "X-API-Key: $LUMBOX_API_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "Support", "domain": "help.yourco.com", "local_part": "support"}'

Replies go out from support@help.yourco.com, in the customer’s original thread.

Paste your help text as the knowledge base

Send each help article to POST /v1/knowledge with a title and plain-text content. Lumbox splits it into chunks and embeds them. One document can be up to 2 MB, and a Starter org can store 10 MB in total.

When an email arrives, the agent has two lookup tools:

search_knowledge returns up to five chunks with a similarity score of 0.3 or higher, each with its document title and up to 1,500 characters of text.
search_past_conversations searches earlier emails in the same inbox, outside the current thread, and returns up to five matches with sender, subject, date and a 300-character snippet. The agent can limit it to emails from the current sender.

It can also read your contact record for the sender with get_contact and tag the email with set_labels. Its system prompt tells it not to invent order numbers, prices, dates or policies, and to hand the thread to a person when the tools do not give it an answer.

Turn on draft-first mode curl -X POST https://api.lumbox.co/v1/inboxes/$INBOX_ID/auto-reply \ -H "X-API-Key: $LUMBOX_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "enabled": true, "mode": "draft", "instructions": "Answer for YourCo support. Under 120 words. Escalate refunds." }'

New inboxes default to auto, which sends replies without review, so pass "mode": "draft" yourself. Each reply now becomes a pending draft, and Lumbox fires a draft.created webhook with the draft ID, recipient, subject and the first 500 characters of the text.

POST /v1/drafts/:id/approve sends the draft as written. If you add a text field to that call, your edited version goes out instead, and POST /v1/drafts/:id/reject discards it without sending anything. Each approval fires draft.approved with the sent email’s ID and an edited flag, which tells you how often the agent’s wording needed a change. The dashboard shows the same queue under Inboxes > Drafts, with an edit box on each draft.

Escalate to a human, in Slack

Refunds beyond policy, account deletion and legal questions should reach a person. The agent has an escalate_to_human tool for these. When it calls it, no reply or draft is written, the thread is marked NEEDS_HUMAN, and Lumbox fires thread.escalated with the sender, the subject and the agent’s reason.

Subscribe one webhook to all three events:

curl -X POST https://api.lumbox.co/v1/webhooks \
-H "X-API-Key: $LUMBOX_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://your-server.com/lumbox", "events": ["draft.created", "draft.approved", "thread.escalated"]}'

The response includes a signing secret, shown once. Lumbox posts its own JSON, so Slack needs a small relay. It checks the X-Lumbox-Signature header (a hex HMAC-SHA256 of the raw body) and posts to a Slack incoming webhook, which takes a JSON body with a text field (Slack docs):

import { createServer } from "node:http";
import { createHmac, timingSafeEqual } from "node:crypto";

createServer(async (req, res) => {
let raw = "";
for await (const chunk of req) raw += chunk;
const expected = createHmac("sha256", process.env.LUMBOX_WEBHOOK_SECRET).update(raw).digest("hex");
const got = String(req.headers["x-lumbox-signature"] ?? "");
if (got.length !== expected.length || !timingSafeEqual(Buffer.from(got), Buffer.from(expected))) {
return res.writeHead(401).end();
}
const { event, data } = JSON.parse(raw);
if (event === "thread.escalated") {
await fetch(process.env.SLACK_WEBHOOK_URL, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ text: Needs a human: "${data.subject}" from ${data.from}. ${data.reason} }),
});
}
res.writeHead(200).end();
}).listen(3000);

The same relay can post draft.created to a channel, so whoever is on support sees each draft as it arrives.

Some mail never reaches the agent. Lumbox skips no-reply and mailer-daemon senders, mailing lists, bulk and auto-submitted mail, and spam. It stops answering a thread once the inbox has sent five messages in it. An email that scores high on the prompt-injection screen becomes a draft even when the inbox is in auto mode.

The bill

On Starter you do not need a model key, because the agent runs on Lumbox AI. Every model call and embedding call is metered by its token counts, priced, and deducted from the plan’s monthly AI credit: $2 on Starter, $10 on Pro and $40 on Scale. The credit resets on the 1st of each month (UTC). If it runs out, new emails get no agent run until the reset, an upgrade, or until you save your own key with PUT /v1/ai-config, after which model calls bill to your provider account. GET /v1/usage/ai shows the month’s spend, with agent replies listed under auto_reply.

In the test run for this post, two drafted replies used 3,111 input and 144 output tokens and cost $0.000421 of AI credit, about $0.0002 a reply, on top of the $9 plan. At that rate Starter’s $2 credit covers roughly 9,500 replies a month. Approved replies also count toward the plan’s monthly sends, which is 2,000 on Starter.

Free works for a trial on a trylumbox.com address, with three limits: no AI credit, no custom domain, and 100 sends a month. On Free you save your own model key, and the knowledge base needs an OpenAI key or a connected Cloudflare account for embeddings.

For comparison, Intercom’s Fin, used with a helpdesk you already have, costs $0.99 per outcome with a 50-outcome monthly minimum (fin.ai/pricing, checked 2026-10-04). Fin’s help center describes that floor as a $49 a month base plan that includes 50 resolutions (Fin pricing: Outcomes). Fin also covers chat, WhatsApp and SMS and answers customers directly. The setup in this post covers email only, and a person approves each reply.

The full recipe, including custom HTTP tools for lookups such as order status, is at lumbox.co/docs/auto-reply-agent. Create an account to try it.

Email for browser agents using Skyvern, Browserbase or Steel

Kumar Deepanshu — Tue, 13 Oct 2026 18:11:31 +0000

Originally published at lumbox.co

Add email verification to a browser agent by connecting its login workflow to an inbox API, retrieving the matching code, and passing that value back to the active browser challenge. Lumbox can supply the email side of this design while Skyvern, Browserbase or Steel supplies the browser workflow, with adapter work depending on the platform you use.

The useful unit of evaluation is a customer portal login. A browser can navigate a form correctly while the code travels somewhere the runtime cannot read. Replacing the browser provider does not necessarily change that email route. Start by identifying the destination mailbox and the owner who can authorize access or forwarding.

Define the handoff

Keep browser state and email state connected in your application. Save the customer account reference, portal origin, browser session, inbox ID and attempt start time before requesting the code. These are application records, not fields that Lumbox automatically adds to a portal email.

The email adapter’s job is to return a candidate verification value with enough context to inspect it. The browser adapter’s job is to place that value into the intended challenge and check the result. If either adapter times out, the parent workflow decides what happens next.

Part of the workflowResponsibilityCustomer onboardingEstablish authorized access and email routingBrowser controllerNavigate, request a code and identify the challengeEmail adapterRetrieve a matching message or parsed codeApplication stateAssociate the result with the active attemptBrowser verificationConfirm the portal accepted the login

This boundary also makes vendor evaluation easier. You can exercise the email adapter with a controlled message before running a whole browser task. You can test the browser with a manually supplied code before diagnosing an inbound-email delay.

Skyvern: inspect its existing authentication path first

Skyvern documents authenticator-based TOTP and email or text-message code handling, including ways to push codes into a waiting workflow. Its 2FA setup documentation is the right starting point for deciding where an external code source belongs.

Do not add another integration merely because the workflow involves email. If Skyvern’s existing authentication route already meets the customer’s needs, use that. If you need a separate inbox service, retrieve the code in your application and connect it to the documented Skyvern input for the active run. Verify the current input contract before implementing the adapter.

This article proposes an architecture. It does not establish a native Lumbox connector in Skyvern, and it does not claim an end-to-end integration has been tested. The distinction matters when estimating implementation work for a pilot.

Browserbase: keep email retrieval in your orchestration

Browserbase provides infrastructure for agents that browse and interact with the web. Its platform introduction describes cloud browsers and other agent infrastructure. Your application can coordinate a browser task with an HTTP request to Lumbox.

When the browser reaches a code challenge, preserve the session and call the email adapter from the runtime controlling the task. Once a suitable result arrives, resume the intended interaction. Avoid letting an unrelated browser task consume a result simply because it is the latest one in a shared mailbox.

An adapter does not need to make the model responsible for polling. Deterministic application code can wait, classify the outcome and expose only the result needed for the next browser action. That leaves the browser agent free to handle page interaction without repeatedly asking whether mail has arrived.

Steel: distinguish existing Lumbox tools from a custom adapter

Steel documents a browser API, session management and credential capabilities in its documentation. Lumbox’s repository also contains Steel-backed browser tools. Those tools require the relevant browser configuration; installing an email MCP server is not proof that a browser session is ready.

If you already control Steel directly, the same external email-adapter pattern applies. If you use Lumbox’s browser tools, inspect the Lumbox browser documentation and test the tool path you intend to call. Do not assume a compound signup tool handles every portal’s challenge sequence.

Choose one controller for a given session. Two independent agents typing into the same challenge can create a confusing failure even when the email response is correct. Session ownership belongs in the workflow design.

The Lumbox retrieval contract

For an existing inbox, call GET /v1/inboxes/:id/otp with an explicit since timestamp and, where useful, a received-sender filter. It waits 30 seconds by default and accepts up to 120 seconds. A successful response includes code, all_codes, from, subject, expires and email_id; HTTP 408 indicates no suitable code before timeout. See the API reference.

The route selects mail in the verification category, and extraction depends on parser rules. Forwarded templates therefore need their own check. The sender seen by Lumbox may be the forwarder. A substring sender filter cannot authenticate the portal or uniquely identify the browser attempt.

For a magic link, read the appropriate structured link fields from an email response instead of expecting the numeric-code shortcut to solve the task. For a phone-only challenge, an email inbox alone does not provide a phone number or receive SMS directly.

Run a small integration trial

Use an owned test account and write down the expected outcome before recording a demo. First, establish that the message arrives and is parsed. Then test the handoff into the browser. Finally, confirm the authenticated page represents the account you intended to access.

Include a delayed message and a second overlapping attempt. Check that the application neither switches inboxes accidentally nor submits a stale result after the browser has moved on. Keep a human handoff available when the route or challenge changes.

Record the result by stage rather than reporting only “login failed.” Useful stages are delivery, extraction, retrieval, browser entry and portal acceptance. This gives your team a concrete basis for comparing browser providers and inbox services without attributing every failure to the model.

For a first Lumbox trial, the free plan includes three inboxes. That supports a small routing experiment, subject to its email limits. Use the pricing documentation for current allowances, then size the pilot around the inboxes you need to keep active.

Implementation references: apps/api/src/routes/inboxes.ts, apps/mcp-server/src/tools.ts, apps/docs/content/docs/browser.mdx, and packages/plans/src/index.ts. Platform documentation and source checked October 3, 2026. No live integration benchmark is claimed.

Kumar

How AI agents receive email OTP codes

Kumar Deepanshu — Tue, 06 Oct 2026 18:00:44 +0000

Originally published at lumbox.co

An AI agent can receive an email OTP by routing the verification message into an inbox it can access, then reading the extracted code through an API. Lumbox provides that inbox and a GET /v1/inboxes/:id/otp endpoint that waits for a matching message for up to 120 seconds.

For a startup building agents that log into customer portals, the first question is where the portal sends its email. An agent-created account can use an agent-owned address. An existing customer account may still send codes to the customer’s mailbox. In that case, the customer needs to configure a suitable forwarding rule, or your application needs an authorized connection to that mailbox. Creating another inbox does not change the portal’s delivery address.

Establish the route before debugging the agent

Begin with one customer-authorized workflow and one known message template. Create a Lumbox inbox, save its returned ID and address, and arrange delivery to that address. The inbox documentation describes inbox management. Use the returned address instead of constructing one from a presumed default domain.

Then trigger a verification email in a test account you control. Inspect the received message before involving the browser agent. Check which address appears as the sender and whether forwarding changes the subject or body. A forwarding service can become the received sender, so filtering for the original portal’s domain may miss the forwarded message.

This separates a routing problem from an extraction problem. If the inbox contains no message, changing the model prompt will not repair delivery. If a message is present but has no extracted code, inspect its actual content and classification. If a code comes back but the portal rejects it, investigate the login attempt and expiry separately.

Make one bounded retrieval request

The following request assumes that the inbox already exists and mail is routed to it. Set LUMBOX_API_KEY, LUMBOX_INBOX_ID, ATTEMPT_STARTED_AT, and EXPECTED_RECEIVED_SENDER in your runtime. Capture the attempt timestamp immediately before requesting the portal’s code. The sender value should match what arrives in the destination inbox.

curl --get --max-time 130 \
"https://api.lumbox.co/v1/inboxes/${LUMBOX_INBOX_ID}/otp" \
-H "X-API-Key: ${LUMBOX_API_KEY}" \
--data-urlencode "timeout=120" \
--data-urlencode "since=${ATTEMPT_STARTED_AT}" \
--data-urlencode "from=${EXPECTED_RECEIVED_SENDER}"

The server’s default timeout is 30 seconds. It clamps the requested timeout between 1 and 120 seconds. Configure the HTTP client and any proxy to permit the intended wait, with some transport margin. A client that gives up earlier can hide the server’s eventual result.

The API reference is the public entry point. The inspected implementation returns code, all_codes, from, subject, expires, and email_id. Use code, not an assumed otp field. These names matter when an agent hands the response to deterministic application code.

Know what matching actually means

The endpoint looks for recent messages categorized as verification and returns the first extracted code from the newest matching message when codes are available. Without since, it uses a five-minute lookback. The optional from filter uses a substring match against the received sender address.

A sender filter is a retrieval filter. It is not proof that a message belongs to a particular browser run. A timestamp narrows the window, but two overlapping attempts against the same account can still fall inside it. Keep the relationship between customer, portal account, browser session, inbox and attempt in your application.

ObservationWhat it establishesWhat to check nextNo message in the destination inboxThe retrieval path has no mail to inspectPortal delivery and forwardingMessage exists, no suitable parsed codeReceipt alone is insufficientTemplate, category and extracted fieldsHTTP 200 with codeA matching parsed code was returnedCorrect attempt and portal acceptanceHTTP 408No suitable code was found before the wait endedDelivery, filters and parser output

Lumbox’s parser uses patterns and category rules. This is useful for predictable automation, but it is not a promise that every email template will match. Test the exact messages your buyers receive, including the forwarded version. The email documentation covers the structured message representation.

Treat a timeout as an application decision

A timeout returns HTTP 408 with error: "No OTP found" and the timeout value. It does not tell you whether the portal failed to send, forwarding was delayed, the filter excluded the message, or parsing produced no suitable result.

Record the stage that failed without putting the code or full email body in ordinary logs. A useful diagnostic record includes the attempt ID your application owns, the inbox ID, request start time, response status and whether the browser remained on the challenge screen. Store sensitive message content only where your support process needs it.

Decide in advance whether to retry retrieval, request another code, or hand control to the customer. Requesting another code may change what the portal accepts. That behavior belongs to the portal, so a generic retry loop should not assume older codes remain valid.

Fit retrieval into the browser workflow

Once you have a candidate code, check that the browser still represents the intended account and challenge. Supply the code through your browser controller, then inspect a defined success condition such as the authenticated account page. A successful inbox read and a successful login are different events.

Your application should also remember completed attempts. The OTP endpoint is not a consume-once queue, and another request can return the same recent message. Preventing duplicate use or simultaneous submissions is your orchestration responsibility.

This pattern is a good fit when the missing part of a portal agent is receiving email and extracting a verification value. If your application already has authorized mailbox access and parsing that works for its templates, retaining that route may be simpler. Lumbox is useful when you want an agent-owned inbox and a bounded retrieval API without building the client polling loop yourself.

The server still polls its database internally once per second. “One call” describes the client’s retrieval step after provisioning and routing, not an entire login or an absence of polling anywhere in the system.

Implementation references, relative to the Lumbox repository: apps/api/src/routes/inboxes.ts (OTP and wait handlers), apps/api/src/utils/parser.ts (extraction and classification), and apps/docs/content/docs/api-reference.mdx (public reference source). Checked October 3, 2026.

Kumar

Sequential IDs Are a Security Decision

Kumar Deepanshu — Thu, 10 Sep 2026 06:00:07 +0000

Originally published at lumbox.co

A convenient helper, of a kind that exists in most codebases:

function findByRef(ref) {
  if (/^\d+$/.test(ref)) {
    return db.get("SELECT * FROM runs WHERE id = ?", Number(ref));
  }
  return db.get("SELECT * FROM runs WHERE public_id = ?", ref);
}

Take an id or a public handle, return the row. Scripts pass the numeric id, the web passes the handle. It reads as a kindness.

Now route an HTTP path segment through it:

app.get("/api/runs/:id", (req, res) => {
  const run = findByRef(req.params.id);
  res.json({ run, leads: leadsOf(run.id), shareUrl: shareFor(run.id) });
});

Every URL the application generates contains a random handle with 72 bits of entropy. Nobody guesses one. But the route also accepts 1, and 2, and 3, and now the entire table is walkable with a for loop.

Why the gate did not catch it

The route was deliberately unauthenticated, and for a defensible reason: the page for a run polls its own status, and running that poll through the authenticated, rate-limited path would have made a page consume its own quota. Public reads were an intentional design decision.

That decision is completely fine, and it is only fine while the identifier is unguessable. The auth rule and the identifier scheme were two separate choices made by two different people at two different times, and the security property lived in the space between them where nothing tested it.

The matcher did not help either. It was anchored:

const COSTLY = /^\/api\/(runs|run|brief)\/?$/;

That matches /api/runs and nothing below it. The collection was rate limited. Every individual resource under it was not.

The fix is a second function, not a check

The instinct is to add a validation branch to the handler. Better to make the unsafe capability unreachable from the network:

/** The only lookup a request off the network may use. */
function findByPublicId(ref) {
  return db.get("SELECT * FROM runs WHERE public_id = ?", ref);
}

Internal callers keep the flexible helper. HTTP handlers get the narrow one. The rule is now expressed in the type of thing a handler can call, rather than in a check somebody has to remember to write in each new route.

Write the test against the vulnerability

A test asserting the new function works is nearly worthless, because it would pass before the bug existed and after it was reintroduced somewhere else. Assert the distinction instead:

assert.ok(findByRef(String(row.id)), "the numeric path still exists internally");
assert.equal(findByPublicId(String(row.id)), undefined, "and is unreachable publicly");

That test documents why the two functions exist. Delete the second one and it fails.

Two things worth taking away

First, a helper that accepts several kinds of identifier is a fine internal convenience and a poor public boundary. The flexibility is the vulnerability.

Second, when you deliberately leave something unauthenticated, write down what is carrying the security instead. If the answer is "the identifier is unguessable", then any code path that accepts a guessable identifier for the same resource is a bug, and it is worth a test that says so.

Plan Then Execute: One LLM Call Instead of Thirty

Kumar Deepanshu — Wed, 09 Sep 2026 18:00:12 +0000

Originally published at lumbox.co

If you have built a browser agent, you have probably shipped this loop: send the current page to the model, ask what to do next, execute that one action, repeat. It is the default across browser-use, Stagehand's agent mode, and most framework browser tools. The model is the brain, the browser is the body, and every step is a round trip.

There is a different shape. Make one model call that writes the whole plan down as JSON, then run that plan with a deterministic executor that never calls a model at all. This post is what that looks like in practice, including the exact schema we run in production, and honest arithmetic on what it saves.

Why the loop is expensive twice over

The obvious cost is the round trips. The less obvious one is what you send on each of them.

An agent loop has to include the current page state on every call, because that is the only thing telling the model where it is. A serialised DOM or accessibility tree for a real signup page is commonly ten to fifty thousand tokens. Twenty steps at twenty five thousand tokens each is half a million input tokens for one task.

The structural cost is worse. At every step the model has to re-derive the plan it already held implicitly one step earlier. Ask it to sign up for a product and it sketches the same sequence in its head each time: go to the signup page, fill the email, submit, wait for the code, paste the code, verify. Then it picks one action and throws the rest away. Next step, it sketches it again. Most of the time it lands in the same place. Sometimes it picks the login link instead of the signup link, and every subsequent step compounds that.

Linear goals do not need this. "Sign up with this address" has one obvious sequence. The model is very good at writing that sequence down once. It is mediocre at re-deriving it twenty times without drifting.

The shape

goal --> planner (1 LLM call) --> JSON plan --> executor (0 LLM calls) --> result

The planner gets one shot and is told so in its system prompt. It has no follow-up call to correct itself, which is deliberate: it makes the model plan defensively rather than optimistically.

The ten step types, exactly

This is the real schema, not a simplification. A plan is { "reasoning": string, "steps": Step[] } and a step is one of:

{ "type": "navigate", "url": string }
{ "type": "click", "describe": string, "text"?: string, "selector"?: string }
{ "type": "fill", "describe": string, "selector"?: string, "label"?: string, "value": string }
{ "type": "wait_seconds", "seconds": number }
{ "type": "wait_for_text", "text": string, "timeout_seconds"?: number }
{ "type": "wait_for_email", "inbox_id"?: string, "from"?: string, "subject"?: string, "timeout_seconds"?: number }
{ "type": "use_otp_from_inbox", "inbox_id"?: string, "selector": string, "timeout_seconds"?: number }
{ "type": "open_link_from_inbox", "inbox_id"?: string, "from"?: string, "timeout_seconds"?: number }
{ "type": "extract_text", "describe": string, "selector"?: string }
{ "type": "done", "summary": string }

Three constraints in the planner prompt do most of the quality work:

Every plan ends with done. The executor breaks out of its loop on done and takes the summary as the task result. A plan without one runs to the end of the array and returns a generic summary.
Prefer text over selector on a click. Humans see text, and text survives a CSS refactor. Selectors are the fallback, not the default.
Keep plans under fifteen steps. Long flows fail. If the goal is bigger than that, the planner is told to plan the first sub-goal only and emit done with a summary of what is left, so the caller can decide whether to continue.

Values can carry {{inbox_address}}, which the executor substitutes before each step runs. That is what lets a plan be written before the inbox it will use exists.

The three steps that cross into email

Six of the ten types are ordinary browser actions. Three are not, and they are the reason this architecture is worth describing at all:

wait_for_email blocks until a message matching the filter lands in the bound inbox
use_otp_from_inbox waits for the mail, extracts the code, and fills it into a selector
open_link_from_inbox waits for the mail, finds the verification or magic link, and navigates to it

In an agent loop, "check the email" is not an action the browser can take. You break out of the loop, poll a mail API in your own code, feed the result back in as text, and hope the model picks up where it left off. That handoff is where a lot of signup automation actually breaks.

Here it is one step in the plan, because the inbox and the browser session are in the same runtime. A full email-verified signup:

{
  "reasoning": "Standard email signup with a code sent to the inbox.",
  "steps": [
    { "type": "navigate", "url": "https://example.com/signup" },
    { "type": "fill", "describe": "email field", "label": "Email", "value": "{{inbox_address}}" },
    { "type": "click", "describe": "submit the signup form", "text": "Sign up" },
    { "type": "wait_for_email", "from": "example.com", "timeout_seconds": 120 },
    { "type": "use_otp_from_inbox", "selector": "input[name='code']" },
    { "type": "click", "describe": "confirm the code", "text": "Verify" },
    { "type": "wait_for_text", "text": "Welcome", "timeout_seconds": 30 },
    { "type": "done", "summary": "Account created and email verified." }
  ]
}

No glue code between the browser and the mailbox, because there is no boundary to glue across.

The arithmetic

We have not run a published benchmark, so here is the calculation instead of a number to take on faith. Substitute your own figures; the shape holds.

Take a twenty step task, twenty five thousand tokens of page state per step, priced at Claude Sonnet rates of $2 per million input tokens and $10 per million output.

Agent loop. Twenty calls carrying 25k tokens each is 500,000 input tokens, or $1.00, before a single output token. Add roughly 500 output tokens per step and you are at about $1.10.

Plan then execute. One call. The system prompt is roughly 600 tokens and is marked for caching, so it costs about a tenth of that on every call after the first. The goal plus inbox context is perhaps 1,000 tokens. Output is capped at 2,048. Call it 1,700 input and 800 output: about $0.011.

That is roughly two orders of magnitude, and the dominant term is not the number of calls. It is that the loop pays for the page state twenty times and the planner never pays for it at all. If your pages serialise smaller, the gap narrows proportionally. If you run more steps, it widens.

One thing that is easy to get wrong here: the planner call is a good candidate for prompt caching precisely because the system prompt is frozen and comes first, while the volatile part (the goal, the inbox context) goes last. Reverse that order and the cache never hits.

What this architecture does not do

Being straight about the limits, because they are the reason to keep a loop around for some jobs.

There is no replanning. The executor runs each step, and on the first failure it records the error, stops, and returns everything up to that point. It does not retry, ask a model for a fix, or improvise. When a page has changed since the plan was written, the plan is wrong and the task fails. That is a deliberate trade: predictable failure with a full step-by-step event log beats an agent that quietly does the wrong thing for another fifteen steps.

There is no plan cache. Every call plans from scratch today. Caching by goal and domain is the obvious next win and it is not built.

Exploratory goals do not fit. "Find a product under fifty dollars" or "research this site and report back" have no linear sequence to write down. The whole premise is that the plan is knowable in advance. When it is not, you want the loop, and you should pay for it.

The fifteen step cap is real. Longer plans get noisier and the model starts over-explaining. Splitting into sub-goals with an explicit handoff summary works better than raising the cap.

When to use which

Goal shapeUse
Linear and repeatable: signups, email verification, password resets, form fills, single page extractionPlan then execute
Branchy and exploratory: research, comparison, navigating an unfamiliar menu treeStep level agent loop

Most production browser automation is the first row. It is worth knowing that the first row does not need an agent at all.

The general version

This is not really about browsers. Whenever a model's strength is sketching a sequence once and its weakness is re-deriving that sequence repeatedly, plan then execute wins: multi step API workflows, file operations, migration scripts. The test is simple. Ask whether the plan is knowable before you start. If it is, write it down once and run it with an interpreter you control. If it genuinely is not, that is what the loop is for.

The runtime described here is the browser act endpoint: one call, one planner hit, deterministic execution, with the inbox in the same runtime so the verification steps are primitives rather than glue.

Pagination Is an Agent Experience Problem

Kumar Deepanshu — Wed, 09 Sep 2026 18:00:11 +0000

Originally published at lumbox.co

A list endpoint returning everything is a familiar, forgivable shortcut. A human calling it gets a slow page and scrolls. A browser handles a 794KB JSON response without complaint.

An agent does not. The response goes into a context window, and a large one either truncates the conversation, evicts the instructions that came before it, or fails outright. The tool call does not return data, it returns a wall.

We had this on list_inboxes. An account that provisions an inbox per task accumulates them quickly, and one had 3,219. The response was 794,423 characters across 28,975 lines. It exceeded the caller's limit and returned nothing usable, on the MCP surface we describe as the reason to use the product.

The costs are different

For a human API the cost of a big response is latency and bandwidth, both of which degrade gracefully. For an agent the costs are:

Context. Finite and shared with everything else the agent needs to remember. A large response can evict its own instructions.
Money. Tokens are billed. A response nobody reads is still paid for.
Attention. Even within limits, burying three relevant rows in three thousand measurably degrades what the model does next.

Graceful degradation does not exist here. It works, or the turn is destroyed.

What a paginated response owes an agent

Human pagination assumes a UI that renders "next". An agent has to decide, from the response alone, whether to continue. So say so explicitly:

{
  "data": [ /* 50 rows */ ],
  "cursor": "inb_a1HjMJs44WShWc3CpEeI",
  "has_more": true,
  "total": 3226
}

total is the field people leave out and it is the one that changes behaviour. Without it, the agent knows there is more but not whether that means one page or sixty five. With it, it can decide to filter instead of paging, or tell the user the list is large, or stop. Return it on the first page only, since recounting on every page is wasted work.

Make the tool description carry it

The schema is not enough. The model reads the description, so the description has to explain the protocol:

"List the email inboxes you have created, newest first. Paginated: the
first page reports 'total', and 'has_more' with 'cursor' means there are
more. Pass that cursor back to continue."

Do not break the SDKs

Adding a default limit changes behaviour for everyone who was relying on getting everything. A method documented as returning all inboxes should keep doing that, which means the SDK follows the cursor internally:

async listInboxes() {
  const out = [];
  let cursor;
  for (;;) {
    const res = await this.get("/v1/inboxes?limit=200" + (cursor ? "&cursor=" + cursor : ""));
    out.push(...res.data);
    if (!res.has_more || !res.cursor) return out;
    cursor = res.cursor;
  }
}

The agent-facing tool exposes the pages. The library-facing method hides them. Those are different audiences and it is fine for them to differ.

One implementation note

If your ids are random, a cursor of WHERE id < :cursor is not correct, because random ids do not sort in the order you are returning rows. Use your database's cursor primitive, which walks the ordered result, or key the cursor on the actual sort column. This bug is quiet: it works for page one and silently skips or repeats rows later.

We Buy the Browser and Build the Inbox

Kumar Deepanshu — Wed, 09 Sep 2026 06:00:32 +0000

Originally published at lumbox.co

An agent that can act on the web needs two things that are easy to confuse. It needs a browser that does not get blocked, and it needs an identity that can receive mail, because almost every meaningful action behind a login starts with a code or a link sent to an address.

They look like two halves of one product. They are not. One of them is a commodity and one of them is not, and getting that backwards is an expensive way to spend a year.

The commodity half

Stealth browser runtimes are a solved and crowded category. Steel ships a self-hostable stealth Chromium. Browserbase ships the hosted version. Browser-use added stealth sessions. Anthropic and Microsoft both expose browser-level primitives directly to a model. These products differ on price, on residential proxy quality, on geography, and on how quickly they respond when an anti-bot vendor ships an update. They do not differ on what they fundamentally are.

When four or five funded teams ship the same primitive, the honest read is that it is infrastructure now. The correct move for a small team is to buy it.

So we run on Steel. browser-executor.ts opens a Steel session with stealth on, runs the plan against it, and deletes the session in a finally block so a thrown step cannot leak a browser. That is the entire relationship. It is about a hundred lines of client code, and if the anti-bot landscape shifts, that is Steel's problem to solve and ours to benefit from.

We would not win a stealth arms race against five better-resourced teams. Entering it would have cost us the thing we can actually win.

The half that is not a commodity

Now the other side. An agent needs an address that can receive a verification code. The available options are worse than they look:

A real mailbox on a consumer provider. Automating a personal account is against terms, and consumer providers are aggressive about flagging automated access. This works until it very suddenly does not.
A disposable inbox service. Built for humans testing signup flows. Public inboxes, addresses on domains that half the internet already blocks, and no API contract you would put in a production path.
A raw transactional email provider. Excellent at sending. Receiving means running your own MX, parsing MIME, and building everything above it yourself.

None of these is a mailbox an agent can reason about. That is a different object, and the gap between "an email arrived" and "the agent knows what to do" is where the work actually is.

The test we used

One question, applied to each half: if we do nothing here, does someone else's roadmap solve it for us within a year?

For the browser, the answer was clearly yes. Five teams are already sprinting at it and their output arrives as a version bump.

For the agent mailbox, the answer was no. Every adjacent vendor is optimising for a different customer. Transactional email vendors optimise for sending at volume. Disposable inbox tools optimise for a human watching a test run. Nobody in that set has a reason to build long-poll retrieval or structured extraction, because their users do not need it.

Build where the answer is no. Buy where the answer is yes. It is not a sophisticated test, but applied honestly it kills a lot of appealing projects, including our own stealth browser.

What "a mailbox an agent can reason about" means concretely

The difference is not the mail. It is what sits between the mail arriving and the agent continuing.

Blocking retrieval instead of polling. An agent waiting for a code should not run a sleep-and-check loop, burning tokens re-reading an empty inbox and guessing at an interval. It should make one request that returns when the mail lands or times out. A polling loop is a retry policy the caller has to invent; a long poll is one line.

Extraction as part of the contract. The agent wants the six digit code, not a MIME tree. Handing a model the full HTML body of a marketing-styled verification email and asking it to find the code costs tokens and introduces a failure mode that did not need to exist. Pulling the code out is deterministic string work. Do it once, server side, and return the code.

The same for links. Magic link flows need the link extracted and followed, not summarised.

That is why the browser plan has wait_for_email, use_otp_from_inbox, and open_link_from_inbox as first class steps rather than as escape hatches into user code. Because the inbox and the browser session are in one runtime, the verification step in a signup flow is a step in the plan, not a handoff out of the plan and back into it. Most signup automation breaks at exactly that handoff.

What we are honest about

Buying the browser is a real dependency. If Steel has an outage, browser tasks fail; a provider abstraction is on the roadmap and it is not built today, so a swap would mean a code change, not a config change. That is the price of the decision and it is the right price to pay at our size. Writing an abstraction layer for a second implementation you do not have yet is how small teams accidentally build frameworks instead of products.

Some things are worth owning. A stealth Chromium is not one of them when five teams already ship it. The mailbox the agent thinks with is.

If you want the second half without building it, that is what Lumbox is: a real inbox per agent, with blocking retrieval and structured extraction, on one API key.

Email Verification When You Are One Person

Kumar Deepanshu — Wed, 09 Sep 2026 06:00:31 +0000

Originally published at lumbox.co

Email verification pricing is built around a particular customer: a sales team that has bought a list of 50,000 strangers and needs to know which addresses are real before burning their domain on it. Per-credit pricing, bulk tiers, enterprise plans.

If you are one person with a signup form, you have a different problem, and most of what that product sells solves something you do not have.

Three different questions

"Verify this email" is really three questions with very different costs.

Is it syntactically an address? Free, instant, and you should already be doing it. Do not use an elaborate regex. Check for one @, a domain with a dot, and no whitespace. Over-strict validation rejects real addresses, and plus-addressing and newer TLDs are the usual casualties.

Can the domain receive mail at all? Free, fast, and this is the highest value check available to you. Look up the domain's MX records. No MX means no mail, ever, and that catches the entire class of typos that matters: gmial.com, hotmial.com, a domain that expired. One DNS query, no vendor.

Does this specific mailbox exist? This is the expensive one, and it is what you are actually paying vendors for.

Why the third question costs money

Proving a mailbox exists means opening an SMTP conversation with the receiving server and getting as far as RCPT TO without sending anything. It is a normal protocol interaction, and it is also exactly what someone harvesting addresses does, so mail servers defend against it.

They defend by refusing connections from IP addresses that are not established senders. Residential and most cloud IPs are refused outright. Some providers accept every address regardless, which tells you nothing.

What a verification vendor sells is a pool of IP addresses with enough reputation that mail servers will still talk to them. That is a real asset and genuinely hard to build. It is not clever code.

The dangerous failure

If you write this yourself and run it from your laptop, you will get 5xx rejections and it is tempting to record them as "invalid". They are not. A 5xx at RCPT TO from an unestablished IP is the server declining to talk to you. Marking those addresses invalid deletes real customers from your list.

Only treat a rejection as a bad address when the response names the recipient, typically a 5.1.x code with text about an unknown user. Everything else is unknown, and unknown is a legitimate answer that any honest verifier should return.

What to actually do

For a signup form:

Syntax check on the client for immediate feedback.
MX lookup on the server. Reject with a helpful message when the domain cannot receive mail, and offer the obvious correction for common typos.
Send a confirmation email. This is the only check that proves both that the address exists and that the person asking controls it, and it costs one email.

You do not need a verification vendor for a signup form. Confirmation email is verification, and it is stronger than anything a vendor can sell you.

For a list you already have and want to mail, the calculus changes. If it is a few hundred addresses collected through your own signup flow, mail them and let the bounces suppress themselves. If it is tens of thousands of addresses of unknown provenance, verify first, because a 13.8% bounce rate will get your sending account reviewed and the vendor fee is cheaper than that.

The honest summary

Syntax and MX are free and catch most real-world mistakes. Mailbox-level verification needs clean sending IPs, which is a thing you rent rather than build. And if you control the signup, a confirmation email beats all of it.

How to Warm Up a New Sending Domain

Kumar Deepanshu — Mon, 07 Sep 2026 18:00:30 +0000

Originally published at lumbox.co

A domain that has never sent mail is not trusted or untrusted, it is unknown. Receiving servers treat unknown senders cautiously, and the way you move out of that category is by sending mail that people engage with, in gradually increasing volume, consistently.

Before you send anything

Get authentication right first, because a warm-up on a misauthenticated domain teaches receivers the wrong lesson.

SPF: a TXT record authorising your sending service. Keep it under the 10 DNS lookup limit or it fails silently.
DKIM: the provider gives you a key to publish. Verify it is actually signing by checking a received message's headers, not by trusting the dashboard.
DMARC: start at p=none with a reporting address so you can see what is happening, then move to quarantine and reject once the reports are clean.
Reverse DNS and a valid return path, if you run your own infrastructure.

The ramp

Volume roughly doubles every few days, with the exact numbers mattering far less than the shape. A workable four week ramp:

Week 1:  50 -> 200 per day
Week 2:  500 -> 2,000 per day
Week 3:  5,000 -> 10,000 per day
Week 4:  20,000+ per day

Two rules matter more than the numbers. Send every day, because a domain that sends 2,000 on Monday and nothing until Friday looks like a burst, not a business. And never skip a rung because you are in a hurry.

Who you send to matters more than how many

This is the part people miss. During warm-up, send to your most engaged recipients first, and expand outward. Opens and replies are positive signals. Deletions without opening are neutral at best. Spam complaints are severely negative.

Order your ramp by engagement:

People who opened or replied in the last 30 days.
Last 90 days.
Last 180 days.
Everyone else, if at all.

Sending to a two year old list on day three of a warm-up will produce bounces and complaints at exactly the moment receivers are deciding who you are.

Watch the right numbers

Bounce rate under 2% and complaint rate under 0.1% are the working targets, not the published limits. The published limits are where enforcement begins, which is far too late to be your alarm.

Segment by receiving domain too. Gmail, Outlook and Yahoo form independent opinions, and it is normal to be doing fine at one and badly at another. An aggregate number hides that completely.

If it goes wrong

If placement drops mid-ramp, go back a step and hold there. Do not push through. The signal you are getting is that you moved faster than trust accumulated, and the only remedy is time at lower volume.

And if you are ramping because you were forced off a shared domain after an incident, be aware you may be warming a new domain while the underlying provider account still carries the old reputation. Reputation attaches to more than the domain name.

Shared or Dedicated Sending Domain: How to Actually Choose

Kumar Deepanshu — Fri, 04 Sep 2026 18:00:06 +0000

Originally published at lumbox.co

Every email platform offers both. The shared domain works instantly and needs no DNS. The dedicated domain needs SPF, DKIM and DMARC records and a warm-up period. The marketing copy rarely tells you which one you should be on, because the honest answer depends on a number.

The number is your monthly volume

Reputation is built from consistent volume. A receiving mail server forms an opinion about a sending domain by watching it over time. If you send 200 messages a month from your own domain, there is not enough signal for anyone to form a positive opinion, and you get treated as an unknown sender indefinitely.

Rough guidance:

Under a few thousand a month: shared domain. You will get better placement riding an established reputation than you will building your own from nothing.
Consistent five figures a month: dedicated. There is enough volume to establish and hold a reputation, and you stop being exposed to other senders.
Anything you brand: dedicated, regardless of volume. If the from address needs to say your company name, that is a product requirement, not a deliverability one.

What you are actually buying with a shared domain

You are renting someone else's reputation, and rented reputation is pooled. The other tenants affect your placement. A platform that runs a shared domain well is one that polices who may send under it, because the alternative is that one abusive tenant degrades delivery for everyone.

Questions worth asking a provider before you rely on their shared domain:

Can a free account send under it, and how much?
Are addresses on it screened for brand impersonation?
Is there a per-account ramp, or can a new account send at full volume on day one?
Is reputation pooled per provider account, or segmented?

A provider that cannot answer these has not thought about the failure mode, and the failure mode lands on you as unexplained spam placement.

What you take on with a dedicated domain

Your reputation becomes yours. That is the whole point and also the whole risk. A bad month is your bad month, and nobody else's volume dilutes it.

You also take on the setup. SPF authorises the sending service. DKIM signs the message so it cannot be tampered with in transit. DMARC tells receivers what to do when the first two disagree, and it is the one people skip. A domain with SPF and DKIM but no DMARC record is a domain anyone can spoof with no consequence.

The subdomain most people get wrong

Send bulk mail from a subdomain, not your root domain. If mail.example.com gets a reputation problem, example.com is largely insulated, and your invoices and password resets keep arriving. Sending marketing and transactional traffic from the same domain means one bad campaign can stop your password resets.

Separate them further if the volumes are different in kind: transactional on one subdomain, marketing on another. Receivers form separate opinions, which is exactly what you want.

Switching later

Moving from shared to dedicated is not a flag flip, it is a warm-up. Plan several weeks. Do not move all traffic at once, and do not start with your least engaged recipients. The next post in this series covers the ramp.

Recording a Bounce Is Not the Same as Honouring It

Kumar Deepanshu — Wed, 02 Sep 2026 18:00:29 +0000

Originally published at lumbox.co

Almost every email integration gets the first half right. The provider posts a bounce or a complaint to a webhook, you parse it, you write a row. There is a nice chart in the dashboard showing bounces over time.

Then someone sends to that address again next week, and it bounces again, and you record a second row.

The table is not the defense

A suppression list only does anything if something reads it at send time. If your bounce data exists purely to render a graph, you have built observability, not protection. Every hard bounce you have ever recorded is an address you are still willing to mail.

The fix is not complicated, but it has to go in the right place:

async function sendEmail(input) {
  const blocked = await isSuppressed(input.orgId, input.to);
  if (blocked) {
    throw new SendBlocked("recipient is suppressed: " + blocked.reason);
  }
  return provider.send(input);
}

The important word is every. Find the function that every send path funnels through and put the check there. If you have a single-send route, a batch route, a reply route and an auto-responder, and you add the check to three of them, you have not added the check.

Batch sends need their own path

A batch of 100 recipients where 4 are suppressed should send 96 messages, not throw. That means the batch path needs a filter rather than a guard:

const { allowed, dropped } = await filterSuppressed(orgId, recipients);
if (allowed.length === 0) throw new AllRecipientsSuppressed();
await provider.sendBatch(allowed);
return { sent: allowed.length, suppressed: dropped };

Report the dropped ones back to the caller. Silently sending to fewer people than they asked for is how you lose their trust in the numbers.

What to suppress, and what not to

Suppress on permanent failures and on complaints. Do not suppress on transient ones.

Hard bounce (mailbox does not exist, domain does not exist): suppress permanently.
Complaint (recipient marked it as spam): suppress permanently, and treat it as more serious than a bounce. Complaint thresholds are twenty times tighter than bounce thresholds.
Soft bounce (mailbox full, greylisted, temporary failure): do not suppress. Retry. Suppressing these throws away deliverable addresses.
Blocked by reputation: this is about you, not the recipient. Suppressing the address hides your own problem and loses a real contact.

The race nobody plans for

Provider webhooks are fast. Sometimes they arrive before your own database has finished writing the row for the message you just sent. If your handler looks up the message by provider ID and drops the event when there is no match, you will silently lose exactly the bounces that happened quickest, which are disproportionately the hard ones.

Do not drop unmatched events. Fall back to attributing them by the sending address, or queue them for a retry. An unmatched bounce is still a bounce.

One check worth writing

The regression that matters is not "does suppression work", it is "does every path use it". A test that enumerates your send routes and asserts each one refuses a suppressed recipient will outlive any individual bug fix.