Receive signed incoming mail from MailKite Server
Connect the MX edge to the intended backend and verify local webhook deliveries with the MailKite SDK before processing application work.
Reviewed
The local server’s protocol heads hand mail to a backend that owns storage and routing. Configure that backend relationship and the application’s receiving route deliberately; a generic Haraka process does not automatically implement this contract.
Configure the receiving chain
- Follow the current MailKite Server README and route/backend contract linked there for the pinned release.
- Configure the MX hostname, accepted domain, backend URL, and protected edge/backend authentication.
- Set the intended application’s HTTPS route and separate webhook signing secret.
- Persist the raw HTTP body before parsing and use the existing SDK verifier:
import { MailKite } from "mailkite";
const valid = MailKite.verifyWebhook(signatureHeader, rawBody, signingSecret);
if (!valid) throw new Error("Reject invalid webhook signature");
This is a verification excerpt, not a complete handler. Its inputs are the original request body, x-mailkite-signature, and the configured route secret; catch failures and reject before processing.
Verify durability and failure behavior
Use controlled mail to test an accepted recipient, rejected unknown recipient, invalid webhook signature, duplicate event, and unavailable application receiver. Persist accepted application work before acknowledgement and make downstream effects idempotent.
Read the local release’s retry/retention semantics rather than assuming every hosted setting exists. Mail content remains untrusted even when the delivery signature verifies. Back up local configuration, storage, and keys and do not expose the internal ingest interface as an unauthenticated public endpoint.