Use MailKite alongside Postal

Postal and MailKite can serve different parts of your email system. Keep Postal for its existing sending and incoming-route workflows, and use MailKite for application-facing inbound mail that benefits from parsed signed webhooks, normalized SPF/DKIM/DMARC results, and attachment access. Postal is a mail delivery platform, not an IMAP/POP mailbox server.

Choose a DNS boundary

MX records apply to a domain, not an individual application. The simplest split is separate domains or subdomains—for example, leave example.com on Postal and use inbound.example.com on MailKite. Publish the MX records shown by each service for its respective domain and verify both paths independently.

If you must use addresses under one domain, keep a single MX receiving platform for that domain and configure address-level forwarding or routing there. Do not publish competing Postal and MailKite MX records expecting a recipient-by-recipient split; sender MX selection does not provide that guarantee.

Configure the two paths

1. Leave Postal’s sending domains, API credentials, and existing incoming routes unchanged for the Postal-owned domains and addresses.
2. Add the separate MailKite receiving domain, verify it, create the application route, and point that domain’s MX records to MailKite.
3. Configure the app to verify MailKite webhook signatures with its SDK and persist accepted events before acknowledging them.
4. Keep provider identity in your application’s message records (postal or mailkite) so retries, logs, attachment retrieval, and operational dashboards use the correct provider contract.
5. Test each domain with controlled messages, including a duplicate delivery and an attachment. Confirm the MailKite path verifies signatures and the Postal path continues to use its existing incoming routes.

The paths are not interchangeable. Postal processed payloads use fields such as plain_body, html_body, spam_status, and optional Base64 attachment data. MailKite’s event has its own schema, authentication metadata, and attachment references. Normalize both into an application-owned internal message shape only after applying each provider’s proper validation.

Connect them through your app

Your application can receive MailKite events on its MailKite endpoint while continuing to call Postal’s send API for messages that should leave through Postal. Keep the Postal server API key on the server, and keep the MailKite webhook signing secret separate. Route outbound messages explicitly by product/domain policy; avoid automatic dual-send or fallback on an ambiguous timeout, which can send duplicates.

For Postal inbound routes, see receive inbound email with Postal. For MailKite event setup, see receive MailKite email as signed JSON; for Postal API sending, see send email with the Postal API.