Receive incoming email through Resend
Connect Resend receiving events to a verified handler and retrieve the incoming message without confusing notifications with full content.
Reviewed
Resend receiving is a separate path from its send API. Start with an application receiving domain/subdomain and review the current receiving guide before changing DNS.
Configure and authenticate receipt
- Enable the receiving domain and publish the exact MX instructions. Do not replace an employee domain’s mailbox MX to test one address.
- Create a public HTTPS webhook endpoint and subscribe to incoming-email notifications.
- Store the endpoint signing secret separately from your API key and use Resend’s documented webhook verification against the original body.
- Verify before accepting event identities or fetching message content. Do not trust a POST solely because it contains a plausible email address.
Retrieve and store the actual message
Use the incoming message identifier with the documented receiving API to obtain the required body and attachment information. Do not assume the event notification contains a complete MIME message or permanent attachment URLs.
Persist accepted work before acknowledging the event. Deduplicate notifications and downstream effects, enforce attachment size/type policy, and retain only the content your application needs.
Test one controlled message, a duplicate event, an invalid signature, and a transient receiver failure. A send-delivery event is not an incoming-email event and must not launch the receive handler.
For implementation examples, the main guide’s Resend inbound walkthrough retains its existing menu. MailKite has its own signed JSON receiving contract; provider verifiers and event IDs are not interchangeable.