Route incoming Mailgun messages to an application

Mailgun inbound routes match received messages and apply configured actions. Choose a dedicated receiving domain/subdomain and check current regional/account support in Mailgun’s documentation.

Configure route scope and trust

1. Publish the receiving DNS instructions for the intended domain without moving unrelated employee mailboxes.
2. Create a recipient-specific route rather than an accidental catch-all. Review its priority and whether later rules also run.
3. Forward to a public HTTPS handler using the documented request format.
4. Verify the callback’s signature/timestamp/token with the current Mailgun signing secret and verification guidance. Do not substitute the sending key or a MailKite webhook secret.

Use the correct form/multipart parser and impose attachment/body limits. A received message’s headers and body remain sender-controlled data even when the callback itself is authentic.

Test the original address

Send a controlled message to the configured recipient, then confirm the matched route, authenticated callback, and durable stored work. Exercise duplicate callbacks and temporary failure; implement replay resistance and idempotent downstream effects.

If the webhook never arrives, investigate domain MX, region, route expression, and provider activity before changing application code. If it arrives but fails verification, compare the exact callback fields and the credential type rather than bypassing authentication.

The Mailgun Routes application guide provides a longer example. MailKite receiving is a separate signed-JSON contract and routing destination, not an extra Mailgun route action enabled by an SDK install.