Email Services: Troubleshooting
When REDA Email Services is set up correctly, inbound email flows in quietly — logging onto Contacts, opening Inquiries and Service Requests, and staging anything ambiguous for triage. When something's off, the symptoms are usually one of a handful: nothing arrives, everything lands in the Unmatched queue, or attachments go missing. This guide walks each common problem back to its cause and points you at the fix, which almost always lives in Email Services: Setup.
Nothing arrives — no records at all
You expect inbound emails to log or to open records, and nothing happens. Work through these causes in order.
| Problem | Likely cause | Fix |
|---|---|---|
| No emails log or create records at all. | The email service is inactive. | Confirm the REDA inbound email service is set to Active. An inactive service accepts nothing. See Setup. |
| Emails to the mailbox never reach REDA. | Mail isn't being routed to the REDA email-service address. | The REDA email-service address is generated per org and isn't shipped with the package. Your IT team must set up a server-side copy (or redirect) of the monitored mailboxes to that address. If that rule is missing, REDA never sees the mail. See Setup. |
| Some senders' mail never appears. | The email service is restricting who it accepts from. | Leave the email service's Accept Email From open (blank) unless you have a specific reason to restrict it. A too-narrow list quietly drops everyone else. |
| An email meant to open an Inquiry or Service Request does nothing. | The recipient address doesn't match an active intake configuration. | Each intake address needs one active configuration row mapping it to Inquiry or Service Request. If the address is wrong, misspelled, or the row is inactive, no intake record is created. See Email-to-Inquiry / Email-to-Service-Request. |
| Users can't see anything even when mail flows. | Missing permission set. | Assign REDA - Email Integration to the run-as (context) user and to every triage admin or agent. Without it, the object, tab, and fields are invisible. |
Everything lands in the Unmatched queue
Mail is clearly arriving — the Unmatched Email tab keeps filling — but almost nothing matches to a Contact or record automatically. That points to how the mail is being delivered or how internal senders are being identified.
| Problem | Likely cause | Fix |
|---|---|---|
| Every item shows your own mailbox as the sender, not the customer. | Mail is being forwarded rather than copied. | A forward rewrites the sender to your mailbox, so REDA can't match the real customer. Replace any client-side Forward with a server-side copy ("also deliver to" / Bcc) or redirect that preserves the original sender. This is the single most common cause of a flooded queue. |
| Genuine customer emails are treated as internal and pile up unmatched. | The internal-domains setting still holds the placeholder value. | REDA uses an internal-domains list to tell your staff apart from customers. New installs may ship a placeholder rather than your real domain. Set the internal-domains value to your organization's actual domain(s) so customer mail is recognized as external. See Setup. |
| Emails from brand-new prospects go unmatched. | There's no existing Contact and no intake configuration to catch them. | This is expected for pure auto-sync: an unknown sender with no matching record is staged for triage by design. If these should instead open records, configure an intake address for Inquiry or Service Request. |
What happens to email REDA can't accept
Beyond matching, the email service has edge-case behaviors that decide what happens when it genuinely can't take a message — for example if the service or its address has been deactivated, or a load limit is hit. Two settings matter here, and REDA recommends setting them deliberately at install because the package doesn't force them:
| Situation | Recommended action | Why |
|---|---|---|
| The service hits its processing limit for the period. | Requeue (over-limit action). | Requeuing holds the message and retries it rather than dropping it. Never set this to Discard — discarded mail is gone with no trace. |
| The service or address is deactivated, or a message fails authentication/authorization. | Bounce. | Bouncing returns the mail to the sender so they know it wasn't received, instead of silently swallowing it. Set these edge-case actions to Bounce explicitly during setup. |
Attachments are missing
An email logged onto a record, but the file the customer attached isn't there.
| Problem | Likely cause | Fix |
|---|---|---|
| Inbound emails log, but their attachments never appear. | The email service isn't accepting attachments. | Set Accept Attachments to All on the email service. This is the required setting for REDA Email Services. See Setup. |
| The attachment isn't in the email body view. | You're looking in the wrong place. | REDA stores inbound attachments as Files. Check the record's Files related list rather than the email itself. |
Permission and access gaps
If email is flowing but people can't see or act on it, the problem is almost always access.
| Problem | Likely cause | Fix |
|---|---|---|
| A user can't see the Unmatched Email tab. | The permission set isn't assigned. | Assign REDA - Email Integration. It makes the tab visible and grants the create/read/edit access triage needs. |
| A user can open records but can't edit fields during triage. | Field-level access is missing. | The same REDA - Email Integration permission set grants field access on the Unmatched Email record. Confirm it's assigned to the specific user, not just the context user. |
| Inbound processing itself seems to fail for everyone. | The run-as (context) user lacks the permission set. | The email service runs as a designated context user. That user must also hold REDA - Email Integration for processing to work end to end. See Setup. |
Where to go next
- Email Services: Setup — the enablement runbook every fix on this page refers back to.
- The Unmatched Email Queue (Triage) — clearing what's already been staged.
- Email Auto-Sync — how matching works, so you know what "should" have matched.
- REDA Email Services Overview — the big picture across all three capabilities.
Frequently asked questions
Check three things in order: that the email service is Active, that mail is actually being copied to the REDA email-service address (not forwarded), and that the recipient address matches an active intake configuration if you expect an Inquiry or Service Request. Most no-record problems trace to one of these.
Two common causes: mail is being forwarded rather than copied, so the sender looks like your own mailbox instead of the customer; or the internal-domains setting still holds the placeholder value and hasn't been set to your real domains. Both stop REDA from matching to the true sender.
Attachments arrive only if the email service is set to accept them. Confirm Accept Attachments is set to All, then look in the record's Files related list rather than the email body — REDA stores inbound attachments as Files.
No. Discard drops mail with no trace. Use Requeue for the over-limit action and Bounce for deactivation and authentication failures, so nothing is ever silently lost.
Was this article helpful?