Inbound email and how receiving works

The path of an inbound email

When a customer emails your support address, here's what happens:

1. Their mail server looks up the MX record for your inbound subdomain.
2. The MX points at our receiving infrastructure (Resend). Their server delivers the message.
3. Resend posts the message to Ochre's /api/email/inbound webhook.
4. We verify the webhook signature so we know the message came from our trusted relay.
5. We check the sender against the workspace's email blocklist. Blocked senders are dropped fast — no ingest, no AI spend. See Email blocklist.
6. We dedupe by message ID. If we've seen it before, we drop the duplicate.
7. We look at the In-Reply-To and References headers to figure out whether this is a reply to an existing conversation or a new one.
8. We match the sender to an end user (or create one) and link or create the conversation.
9. The conversation surfaces in the inbox with status open, ready for routing or AI dispatch.

End to end, this is usually a couple of seconds.

Threading

We thread conversations using the standard email headers In-Reply-To and References. When a customer replies to one of our outbound emails, their mail client sets these headers to the message ID of our message, and we match it back to the original conversation.

This means:

• Direct replies always land on the existing conversation.
• Replies that change the subject still thread correctly, because we use message IDs, not the subject.
• A customer starting a new email (rather than replying) creates a new conversation, even if the subject is similar. This is correct: they meant to start something new.
• Forwarded mail (where the customer forwards an old thread to your support address) typically creates a new conversation, since the original headers are usually stripped or replaced.

Deduplication

We dedupe inbound mail by message ID. This handles the case where a sender's mail server retries delivery, or where a webhook is delivered twice.

Auto-responders and out-of-office

Most well-formed auto-responders set the Auto-Submitted: auto-replied header or X-Autoreply: yes. The post-ingest pipeline detects these and skips them so they don't pollute the inbox or trigger an AI reply.

Less well-formed auto-replies (subject prefixed with "Out of office:" but no header) sometimes slip through. If you see one creating noise, add the sender to the email blocklist.

Diagnostic event log

Every webhook hit lands a row in the inbound event log so you can see exactly what happened. Visit Settings → Domains → Inbound diagnostics to see the most recent events with their result: received, signature_failed, unrouted, auto_responder, ingested, ingest_failed, wrong_event_type, channel_disabled, or blocklisted.

This is the first place to look when "email isn't arriving" — most of the time the answer is in the diagnostic log.

What's next

• See Email channel for the broader feature set.
• For DNS setup, see Custom domain email.
• For sender blocking, see Email blocklist.