Before You Connect an Inbox: An Inbound Email Checklist for Self-Hosted Applications
Before connecting a business inbox to a self-hosted application, confirm the documented delivery method, what the application does with messages, and how your team will handle access and failures.
Start with the job the inbox should do
“Connect email” can mean different things: create a support conversation from an incoming message, attach correspondence to a customer record, or let staff reply from inside an application. Write down the intended workflow before choosing a mailbox or changing its settings.
Treat inbound processing and outbound email as separate questions to verify. What does the application need to receive or import, and what does it need to send? Check the application’s documentation for each requirement rather than assuming one configuration covers both.
Identify the mailbox, the messages you intend to include, the action the application should take, and the people who need access to the resulting records.
- What business process should the application support?
- Which messages should be included, and what documented rule determines that?
- Do staff need to reply from inside the application? If so, where is that capability documented?
- Who will own this workflow and its configuration?
Verify the documented delivery method
Check the documentation for the exact application and self-hosted deployment before selecting a delivery method. What methods does it document? What must be configured outside the application, and do the instructions apply to your deployment?
As a narrow product-specific example, Chatwoot’s [self-hosted ingress guide](https://developers.chatwoot.com/self-hosted/configuration/features/email-channel/ingress-providers) describes choosing and configuring an inbound email ingress provider, setting required environment variables, and using providers such as Mailgun or SendGrid. This example does not establish what other applications support or how they should be configured.
SMTP is the protocol email servers use to communicate to send and receive messages, as described in [this overview](https://blog.miguelgrinberg.com/post/how-to-host-your-own-email-server). That general definition does not tell you how a particular application receives or processes inbox messages. Check its documented inbound-email setup separately.
- Find the application’s self-hosted inbound-email documentation.
- What method, external services, configuration values and prerequisites does it specify?
- Where does it say to enter configuration, and how does it say to apply changes?
- If the documentation does not answer these questions, ask the application vendor or maintainer before connecting a business mailbox.
Ask what access and message handling involve
Before granting access, ask the application maintainer and mailbox provider what account, authentication method and permissions the documented integration requires. Do not assume a particular login method or permission scope.
Ask what the application stores, displays, indexes or otherwise uses from an incoming message. Verify the documented treatment of message bodies, sender and recipient details, headers, attachments and other metadata. If the documentation does not answer, treat the behavior as an open question rather than inferring it from a message appearing in the app.
Use those answers to decide whether the inbox is appropriate for the workflow. Consider who can access resulting records and whether the application should receive all message content or a narrower selection.
- Which account and permission scope does the documented integration require?
- What message fields, content and attachments does the application handle, and where is that behavior documented?
- Are attachment limits, storage location, retention and access controls specified?
- Who is authorized to access the resulting records?
Plan for ownership, failures and recovery
Before launch, ask how your team can recognize that the integration is not working as expected. Does the application or integration document a status view, logs, alerts or another way to investigate? Confirm what is actually available rather than assuming a particular monitoring feature exists.
Ask the maintainer what happens with duplicate delivery, delayed processing and failures, and what recovery steps are documented. If the documentation does not specify the behavior, record it as unresolved. Decide who will investigate a missing or repeated message and what staff should do if the expected record does not appear.
Keep the ownership and recovery information available to authorized administrators. Consider how your organization would transfer responsibility, replace or revoke access where appropriate, and restore the workflow if the person who configured it leaves. Avoid putting passwords, tokens or other secrets in the runbook.
- Who is the operational owner, and who is the backup contact?
- Where can administrators check status or investigate a failure, if those options are documented?
- What does the maintainer say about duplicates, delays, retries and recovery?
- How will responsibility and access be transferred if an owner leaves or changes roles?
Run a controlled test and record the decision
Before connecting a production inbox, ask the application maintainer whether a test setup is available and follow the documented instructions. Use messages that let you check the behavior relevant to your workflow without exposing unnecessary business data.
Verify whether the intended action or record appears and whether the message details and attachment behavior match what the documentation led you to expect. Ask how to test repeated delivery, delays or failures safely; do not assume the application provides a test procedure for every case.
If the observed behavior differs from the documentation or leaves an important question unanswered, pause before production use and ask the application maintainer or mailbox provider. Record the method used, the answers received, unresolved questions, responsible owners and recovery steps—without recording secrets.
- What controlled test setup does the application documentation recommend, if any?
- Does the expected record or action appear, and is the relevant message content handled as documented?
- What safe, documented checks are available for repeated delivery, delays or failures?
- Record the delivery method, data-handling answers, owners, recovery steps and unresolved questions.
Frequently asked questions
Is inbound email the same as outbound transactional email?
They are separate requirements to verify: one concerns receiving or importing messages, and the other concerns messages the application sends. Check the application’s documentation for each workflow rather than assuming one configuration covers both.
Should I use forwarding, mailbox polling or an ingress provider?
The supplied evidence does not establish one method as best for every self-hosted application. Check the application’s current self-hosted documentation for supported methods, prerequisites and configuration steps. Ask the maintainer if it does not resolve your use case.
Does configuring SMTP mean my application can process an inbox?
Not by itself. SMTP is a protocol email servers use to communicate to send and receive messages, but that general definition does not describe how a particular application ingests inbox messages. Verify the application’s documented inbound-email setup separately.
What should I verify before connecting a production mailbox?
Check the documented delivery route, expected application action, relevant message and attachment handling, required access, and available failure and recovery guidance. Ask the maintainer how to test these behaviors safely in your setup.
What should happen when the person who configured the inbox leaves?
Ask how your organization can identify the account and configuration, transfer responsibility, replace or revoke access where appropriate, and follow documented recovery steps. Keep ownership from depending on one person’s undocumented setup.
Sources and further reading
- Configuring inbound mails in Chatwoot — Chatwoot
- How to Host your Own Email Server — Miguel Grinberg