Receive email through Elastic Email inbound routes
Configure a narrowly scoped inbound route and implement the actual incoming payload/security contract for your Elastic Email account.
Reviewed
Elastic Email’s API reference includes inbound route resources. Confirm the feature’s current account/plan availability and incoming webhook contract before designing a production receiver; listing an API operation does not guarantee access.
Set up the receiving path
- Select a dedicated receiving address/domain configuration and follow the provider’s current DNS/routing instructions.
- Create the route with the intended recipient conditions, priority, and HTTPS target.
- Implement the documented incoming request parser and endpoint protection. Do not assume an outbound event webhook and an inbound route share payload or signing behavior.
- Define attachment size/type limits and the message identity used for deduplication.
Use the current v4 reference’s InboundRoute section and linked help for the deployed feature. Do not import older unsigned/form-payload assumptions without verifying them against current account documentation.
Prove receipt and recovery
Send a controlled message to the original receiving address, then confirm route matching, source checks, and durable processing before acknowledgement. Test duplicates and a temporary receiver failure.
Treat raw headers, attachments, and HTML as untrusted data. A delivery notification for an outgoing message is not an incoming reply. Keep these paths distinct in the application and its logs.
MailKite receiving is another infrastructure choice with its own verified domain, payload, and signature. Migrating requires changing the route and verifier together, not simply renaming fields in an Elastic Email callback.