Design the return path before sending
A message that asks a customer to reply needs somewhere for that reply to go. For a support request, it might be a ticket. For an approval workflow, it might be an existing task. Decide that destination before sending the original email.
Sending-domain verification and receiving configuration solve different problems. Verification authorizes a sender; an active receiving address and the appropriate MX records route replies into an inbox. Verifying a sending domain does not automatically create a receiving route.
Set up an address that can receive replies
In InboxIt, create an inbox and wait for it to become active. For a custom address, follow the domain and MX requirements in the receiving guide, then assign the address to that inbox.
Use a dedicated subdomain when appropriate, such as mail.example.com. Do not replace the root domain’s existing MX records without understanding which employee or customer mailboxes depend on them.
Send from the receiving address, or set reply_to to it. Perform one manual round trip: send to a mailbox you control, reply from that mailbox and confirm the response appears in InboxIt. That separates routing problems from application-processing problems.
Store the right message identifiers
A subject such as “Re: Your request” is not a reliable conversation identifier. Two unrelated messages can share a subject, and users can edit it. Keep your application’s conversation ID associated with the email’s Message-ID.
InboxIt’s outgoing email UUID and the RFC Message-ID are different values. Incoming messages also have mailbox UIDs used for retrieval. Store the inbox ID, UID validity and UID together when recording a received message; do not substitute an outbound UUID into an incoming-message URL.
The Internet Message Format standard defines Message-ID, In-Reply-To and References. These headers describe relationships between messages. They help with threading but do not prove that the sender is authorized to change an account or approve a transaction.
Send a reply with its original context
When your app responds to a received message, set in_reply_to to that message’s RFC Message-ID, including its angle brackets. Keep your internal conversation association too. InboxIt’s replies and threads guide explains the header behavior.
{
"from": "hello@mail.example.com",
"to": "customer@example.com",
"subject": "Re: Your request",
"text": "Thanks for the details. We have updated your request.",
"in_reply_to": "<original-message@example.com>"
}This is an illustrative JSON body, not a complete request. Replace the addresses and Message-ID with your own values and supply authentication and an idempotency key as described in the send API reference. There is no separate InboxIt threads endpoint; your app maintains its conversation model.
Process incoming events safely
An email.received webhook contains identifiers rather than the complete message body. Verify the webhook signature, accept the event durably, and retrieve the message separately. Deduplicate events by their event ID so a retry cannot create two tickets.
Do not assume events arrive in order. If your processing depends on an earlier record, reconcile against stored state. Retrieve content before the applicable retention period expires, and store only what your workflow needs.
Validate who is allowed to act on the conversation. Email text and headers are input to your application, not permission to perform an action. For agent-driven processing, see how to give an AI agent an inbox.
Troubleshoot a missing or disconnected reply
- No message arrives: check the reply address, receiving status and MX records.
- The message arrives but no task updates: inspect webhook delivery and application processing.
- A new conversation appears: compare Message-ID and reply headers with your stored mapping.
- Two tickets appear: check event deduplication and retry behavior.
Start with a visible round trip before adding automation. Once that works, follow the webhook guide to make processing reliable.
