Customer replies are not showing up
Customers say they replied, but nothing landed in your inbox. The fix is almost always a domain record, a routing rule, or a stalled inbound event. Walk this checklist.
Symptom: A customer says they replied to your support email, but the message never appeared in the Ochre inbox. Or replies arrive late, or in the wrong conversation.
This is almost always one of five things. Walk the checklist top to bottom.
Checklist
1. Confirm the customer actually hit your address
Ask the customer to forward the original message they sent, including headers if possible. Check the To field. If they replied to a personal alias, an old Zendesk address, or an autoresponder, the message never made it to Ochre. The fastest way to confirm is to compare against the verified addresses in custom domain email.
2. Check the Inbound Email Events panel
Go to Settings → Domains and open the Inbound Email Events panel. This shows every recent receive attempt against your domain. Look for the customer's email address or message ID.
- If you see the event marked received but no conversation appears, you have a routing problem. Skip to step 4.
- If you see the event marked rejected, hover for the reason. Most rejections are SPF or DKIM failures. Step 3 covers that.
- If you do not see the event at all, the message never reached us. That points at DNS.
3. Verify DKIM, SPF, and MX
Still on Settings → Domains, look at the three status pills next to your sending domain. All three should be green.
- MX red or yellow means inbound mail is not being routed to Ochre. Reapply the records shown on the page and wait for propagation.
- SPF red can cause some providers, especially Microsoft 365, to silently drop messages.
- DKIM red affects outbound trust, which can cascade into customer replies bouncing on send. See custom domain email for record values.
4. Check routing rules
If the message arrived but did not show up where you expected, a routing rule probably moved it. Open the conversation list filter and clear all filters. Then look in Closed and Snoozed. Auto-close on reply is a common cause when an SLA policy is aggressive. See auto-close.
5. Confirm the email channel master toggle
Go to Settings → Channels and confirm the email channel master toggle is on. A toggle that was flipped off during a maintenance window will silently swallow inbound mail. See channel master toggles.
6. Check for aliases
If your team uses conversation aliases, the reply may have been threaded into the original conversation rather than creating a new one. Open the original ticket and scroll to the bottom.
7. Look at auto-replies
A misconfigured auto-reply can confuse customers into thinking their message was not delivered when it actually was. Send yourself a test message from an outside address and time the round trip.
Quick test you can run now
Send a test message from a personal Gmail to your support address. Watch the Inbound Email Events panel.
- Event appears, conversation opens. System is healthy. The original report is probably step 1, 4, or 6.
- Event appears, no conversation. Routing rule or master toggle. Steps 4 and 5.
- No event. DNS or upstream provider. Step 3.
When to contact support
If the Inbound Email Events panel shows the message as received but it never created a conversation, and your routing rules and master toggle look right, contact us. Include:
- The conversation ID (if one exists), the customer email, and the timestamp.
- A screenshot of the Inbound Email Events row.
- Whether DKIM, SPF and MX are all green.
Reach us via support contact.
Related reading
Was this article helpful?