Docs Get key
All server guides
Agent Mail Providers

Triage MailKite incoming email before invoking an agent

Verify the webhook with the MailKite SDK, durably deduplicate incoming work, and pass bounded untrusted content to the model.

Reviewed

A valid webhook proves that a request followed MailKite’s delivery path. It does not prove that the original email sender is authorized to instruct your agent. Establish transport trust first, then apply your application’s sender, recipient, attachment, and action policies.

Authenticate the original request

Configure an exact-address receiving route and deploy a raw-body handler using a supported receiver example. Install mailkite for Node.js; this verification excerpt uses the existing SDK contract:

import { MailKite } from "mailkite";
// rawBody is the original request Buffer, before JSON middleware.
const verified = MailKite.verifyWebhook(
  signatureHeader,
  rawBody,
  signingSecret,
);
if (!verified) throw new Error("Reject the unverified webhook");

The inputs come from the x-mailkite-signature header, untouched request bytes, and this route’s secret. This is not a complete HTTP server. Catch authentication failures and reject them before parsing content or invoking a model. Do not log the secret or the email body while diagnosing a mismatch.

Make incoming work recoverable

  1. Validate the authenticated event’s identity and type. Only incoming-email events enter the triage path.
  2. Persist the event or durable job, using event identity to suppress duplicate scheduling, before returning success.
  3. Associate the job with the configured address/tenant and original message identity. Do not route solely using sender-controlled display headers.
  4. Pass only necessary content to the model as untrusted email data. Limit attachment size/type, avoid rendering active HTML, and do not fetch arbitrary links automatically.

Keep the model’s classification/proposed answer separate from any send capability. A message asking the agent to reveal its credentials, change billing, or forward all mail must reach a policy rejection or human review—not an automatic tool call.

Test the boundaries

Use controlled content to test a valid receipt, invalid signature, duplicate event, temporary storage failure, and a message containing hostile instructions. A duplicate must not create a second reply proposal; a failed storage write must not be acknowledged as durable success.

The next guide handles outgoing approval. Review webhook security, delivery/retries, and data retention before production. Provider signatures authenticate deliveries, not the authority of instructions inside mail.