Email integration

DevRev's Email snap-in handles incoming emails, creates conversations and tickets, and manages threading—all within the DevRev app. It works with a range of email providers.

Conversation and ticket creation for emails

When an email is received, DevRev checks whether the sender is linked to your workspace and creates a conversation or ticket accordingly. If a sender is not recognized, DevRev creates a new user profile to track interactions (Support > Inbox for conversations and Support > Tickets for tickets). All replies are sent from your organization's own email addresses, which builds trust with mailbox providers, reduces spam flags, and adheres to DMARC standards.

You can configure a given email address to create either a conversation or a ticket, but not both simultaneously. The choice depends on the nature of the emails received at that address.

Read more about conversations and tickets to decide which is more suitable for your use case.

When needed, you can link a conversation to a ticket—useful when you use conversations for all communication but need to escalate specific threads.

Ticket visibility and roles

The visibility and interaction capabilities for a ticket in DevRev are determined by the user's role and how they were added to the email thread.

• Original sender: Added to the Reported by or Email members field. Can view the ticket on the portal and reply via email.

• End user in the same organization: Added via the To or CC fields in the email thread, the Reported by field, the Email members field, or @mentioned in the DevRev app. Can view the ticket on the portal and reply via email as an email member.

• Customer admin for the same workspace: Added to the Customer Admins group. Can view the ticket on the portal once their workspace is updated on the ticket.

• End user outside the original sender's organization: Added via the To or CC fields in the email thread, or mentioned in the DevRev app (which adds them to CC). Can reply to the ticket via email. Cannot view the ticket on the portal, because they are added to the Email members field but not to the Reported by field.

• User with a DevRev account (added to email thread): Added to the To, CC, or Email members field. Can view the ticket on DevRev, reply via email, and receive in-app notifications. If they make changes to ticket attributes, they remain subscribers.

• Manually added subscribers: Added to the Subscribers field. Can view the ticket on DevRev and receive in-app notifications.

• User without a DevRev account: Added to the Email members field as a subscriber. Can reply to the ticket via email.

Conversation visibility and roles

Conversations follow a similar model to tickets, with visibility determined by how a participant was added to the thread.

• Original sender: Added to the conversation as the primary contact. Can view the conversation in the portal and reply via email.

• CC'd participants: Added to the conversation as email members. Can reply via email; portal visibility depends on whether they belong to the same workspace as the original sender.

• Support agents: Can view and reply to the conversation from Support > Inbox. Agents assigned to the conversation receive in-app and email notifications based on their notification settings.

• Subscribers: Added manually or automatically. Receive in-app notifications but do not participate in the email thread unless they reply directly.

Email status states

The sender of an email can view the delivery status of each outbound message, including bounce details when applicable.

• In Transit: The email is queued for outbound delivery. DevRev is attempting to send it.

• Sent: DevRev has successfully sent the email; it is on its way to the intended recipient.

• Delivered: DevRev has successfully delivered the email to the recipient's email server.

  📝 Note: Even after a Delivered status, the recipient's email server may quarantine the message or route it to a junk or spam folder. DevRev registers Delivered as soon as the message reaches the recipient's server.

• Bounce: The recipient's email server rejected the message. Reasons can include a non-existent email address, a typo in the address, or the message failing the recipient server's security policies. The specific reason is detailed in the bounce event, and the sender is notified.

End user email experience

Customers can initiate communication in two ways:

• By emailing your support address: Automatically creates a ticket or conversation in DevRev.

• By submitting a ticket via the DevRev Customer Portal: Generates email notifications for replies.

Depending on the source channel (email or portal), email behaves slightly differently:

Support agent email experience

Support agents can handle email conversations within the support interface—replying to customer messages, managing threads, and configuring personal email settings.

Email notifications

Agents can configure how and when they receive email notifications through Settings > Notifications.

Each notification type—such as being assigned, mentioned, or receiving a customer reply—can be toggled independently for in-app and email delivery.

The email composer in Tickets

Inside every ticket, under the Customer Messages tab, agents can access a fully featured email composer for direct email communication with customers from within DevRev.

Capture customer details from forwarded emails

When an email is forwarded to your support address, DevRev can extract the original sender's details—such as name and email address—from the forwarded message body and use them to populate the customer record on the resulting ticket or conversation. This setting is configurable in the Email snap-in settings.

Email bounce prevention

If an email fails to deliver, common causes include:

• A deleted user listed as a reporter.

• Invalid or unverified recipients in the To or Cc fields—for example, addresses that do not exist or have not been verified with your email provider.

Threading

Email integration preserves threading by using the References and In-Reply-To email headers and by correlating the email subject field and the ticket title. If either the ticket title or the email subject is changed at any point after ticket creation, follow-up emails may cause a new ticket to be created.

Threading breaks when the order of words in the subject is changed, when words are replaced, or when words or symbols are inserted in the middle or appended. Threading is maintained if the subject change is limited to the addition of words before :, words between [], words between ##, or common prefixes such as Re or Fwd.

Threading logic

Threading relies on two standard email headers that email clients attach to every reply.

References contains the full chain of Message-ID values from every prior message in the conversation, starting with the original. This allows DevRev to reconstruct the entire thread, order messages correctly, and group related messages even when they are not direct replies to each other.

In-Reply-To contains the single Message-ID of the email being directly replied to. Together with References, it establishes the parent–child relationship between messages and determines where a new reply belongs in the thread.

Threading workflow

Original emails lack both headers. Significant subject-line changes cause DevRev to treat the incoming message as a new conversation and open a new ticket.

Events panel

The Events Panel is located in the top-right corner of the Email Integration page. It serves as the primary tool for verifying configuration and diagnosing delivery issues.

The panel displays:

• Key email events, including delivery failures (bounces) and spam flagging (rate-limit violations).

• Internal discussion, where collaborators can comment on specific events for shared visibility and coordinated debugging.

Review the Events Panel after any configuration change and whenever email delivery appears to stop or behave unexpectedly. It typically surfaces the root cause before other diagnostic methods.

Monitor error messages

To investigate delivery errors using the Events Panel:

1. Open the Email Integration page and select the Events Panel in the top-right corner.

2. Filter the snap-in logs to isolate error-level entries, then group them by event ID to assess how many emails are affected.

3. Select an individual event to open the transaction log and review the full detail for that event, including the sender, recipient, timestamp, and failure reason.

4. If the error indicates a rate-limit violation, check whether the sender has been tagged as spammer or blocked and take the appropriate action described in Rate limiting.

5. (Optional) Add an internal comment on the event to share findings with other collaborators.

Rate limiting

To protect your support system from spam attacks and mail loops, the email integration lets you specify user-specific email limits:

• Maximum emails per 10 minutes: Default is 30. Users exceeding this limit are automatically tagged as spammer.

• Maximum spam emails per 24 hours: Default is 100. Users exceeding this threshold are tagged as blocked.

Once marked as spammer, the user can only send 100 emails in a 24-hour period, all of which the system marks as spam. Any emails beyond the 100-email default are dropped, and the blocked tag is added to the user.

To restore normal email delivery, remove the spammer or blocked tag from the contact record in DevRev. If a legitimate high-volume sender—such as an integration or a VIP account—is being rate-limited, apply the power-user tag to their contact record to exempt them from these limits.