Email integration setup

1. Configure the Email Integration snap-in

1. Go to Settings > Snap-ins > Email Integration (listed under Featured).

2. Click Add in the top-right corner to install the snap-in in your workspace.

3. Click Configure in the top-right corner to open the email configuration modal.

4. Under the Connections section, click Search Connections > Add Connection.

If you use custom domains or other providers (even if you work through Gmail), follow the instructions under Email connection. If you use Google as the mail provider, refer to Gmail connection.

2. Configure the email connection

1. In the top-right corner, select + Connection, choose Email service, and enter your connection name and domain name. Click Next.

2. The Email Domain Configuration box opens, displaying the 6 DNS records you must add to your domain's DNS settings.

3. In the DNS settings of your domain provider, copy and paste the Name and the Value from the DevRev app, selecting the appropriate record Type. Set the TTL as required. Repeat for all 6 records and click Save. The steps to add DNS records vary by provider.

4. In the DevRev app, click Verify.

   📝 Note: The message "DNS records configuration verified successfully" indicates the connection is ready. Verification may take some time. If it does not succeed immediately, wait before retrying.

Custom Mail From address

Configuring a custom Mail From address ensures that outbound emails are sent from your own domain rather than a shared DevRev domain. This is an important step for SPF and DMARC alignment: without it, receiving mail servers may flag outbound messages as failing DMARC checks, which can affect deliverability and sender reputation.

To configure a custom Mail From address, open the connection settings under Settings > Snap-ins > Connections after creating your connection and enable the Custom Mail From option.

Whether Custom Mail From is enabled determines which SPF record DevRev checks:

• Custom Mail From not enabled: The SPF record of your domain (for example, example.com) must include either amazonses.com or mail-spf.devrev.ai.

• Custom Mail From enabled: DevRev does not read your domain's own SPF record. Instead, it reads the dvrv-mail.<domain> subdomain (for example, dvrv-mail.example.com), which must have both of the following:

  • An SPF record that includes either amazonses.com or mail-spf.devrev.ai.

  • The MX record shown in the connection settings.

DNS troubleshooting

When setting up DNS records, ensure the correct format to avoid issues.

• Issue: DNS provider appends the domain name automatically, creating a duplicate such as support@example.com.example.com instead of support@example.com.

  Solution: Confirm the DNS key is entered exactly as shown in DevRev without the extra domain suffix.

• Issue: DNS record validation fails after saving.

  Solution: Double-check that each record matches the type, name, and value provided by DevRev exactly. DNS changes may take time to propagate; allow sufficient time before retrying verification.

• Issue: Stale DNS cache causes conflicts with updated records.

  Solution: Clear your DNS cache on your servers or workstations, then retry verification.

Gmail connection

You must be a member of the group and have permission to send emails to the Google Group. This approach does not work with generic Google Groups ending with @googlegroups.com.

1. In the Connections section, choose Google and enter your connection name and domain name.

2. Toggle on Make public to make the connection available to your entire workspace and click Next (recommended).

3. Click Sign in with Google and add your organization's Gmail account. If you are already signed in with a different Gmail account, select Use another account and continue.

   If you use Google Groups, sign in with the Gmail account that has permission to send emails to the group and is a member of the group. Then, in your Gmail account, go to Settings > Accounts and Import > Send mail as and add your group address.

4. Grant DevRev additional access to your Google account. Refer to the privacy policy for more information.

3. Configure email forwarding for your email provider

For conversations or tickets to be created in DevRev, emails must be forwarded from your email provider. Forwarding instructions appear under the Installation section of the Email Integration snap-in page after the snap-in is successfully installed and verified.

Set the provided forwarding address on the account you want to forward from (for example, support@example.com).

In the DevRev app, under the Instructions tab, a forwarding email address is displayed as v___________@hooks.devrev.ai. This is the address where you forward your support email. Copy and paste this address into your email account's forwarding settings.

Mail-to-ticket: no ticket created

When a forwarded email does not create a ticket or conversation in DevRev, the cause is almost always in the forwarding setup rather than in DevRev itself. Work through the following in order.

• Issue: Forwarding was never confirmed.

  Solution: Provider forwarding stays inactive until the verification link is accepted. Locate the verification message that DevRev sent to the v___________@hooks.devrev.ai address (in Support > Tickets or Inbox, depending on the primary use case) and open the confirmation link. If the link expired, remove and re-add the forwarding rule to trigger a new message.

• Issue: Mail is forwarded from a Google Group instead of an individual member address.

  Solution: Google Groups do not forward natively to an external address. Add the v___________@hooks.devrev.ai address as a member of the group rather than setting a forwarding rule. Forward from an individual member address only when that address is the one configured on the connection.

• Issue: The sending domain is not allowed on the connection.

  Solution: The connection accepts mail only from the domains configured on it. When the events show "only emails forwarded from [domain] are allowed", add the sending domain to the connection or forward from an address on an allowed domain.

• Issue: Mail sorted into the spam folder is not forwarded.

  Solution: Most providers do not apply forwarding rules to messages that land in spam, so those messages never reach DevRev. Adjust the provider's spam filtering or add the sender to a safe-sender list, then resend the test message.

• Issue: An SMTP relay or sub-address strips or rewrites the recipient.

  Solution: When an upstream relay or a plus-style sub-address changes the envelope recipient, the message can arrive without the expected routing. Confirm the relay preserves the v___________@hooks.devrev.ai address and that the sending domain still passes SPF and DMARC after the relay. For relay-specific setup, refer to the SMTP relay and upstream relays guidance in this section.

Google

Google Groups and standard Gmail inboxes use different forwarding paths. A standard Gmail inbox supports native forwarding rules directly in Gmail settings. Google Groups (addresses ending in @googlegroups.com) do not support native email forwarding to external addresses; instead, you add the DevRev hooks address as a member of the group. Note that generic Google Groups ending with @googlegroups.com are not supported for the Gmail connection type—use a Google Workspace group or a standard Gmail inbox instead.

1. If you use Google Groups, add your support address as a member of the Google Group. You must be a member of the group and have permission to send emails to it.

2. Go to your support Gmail account Settings > Forwarding and POP/IMAP and add the forwarding email address v___________@hooks.devrev.ai.

3. Click Next then Proceed when redirected to a new webpage. A confirmation code is sent to the forwarding address.

4. If the Primary Use Case is Tickets, go to Support > Tickets in the DevRev app. If the Primary Use Case is Conversation, go to Inbox. Find and open the verification message.

5. Open the confirmation link in the message. Ensure you click the link that authorizes your support address to forward to v___________@hooks.devrev.ai.

6. Return to your Gmail forwarding settings, select Forward a copy of incoming mail, and click Save Changes.

Gmail delegation for shared inboxes

For a Google Workspace shared mailbox (for example, support@company.com), Gmail delegation lets another user in the same organization read and send mail as that address without sharing its password. In Google Workspace Admin, ensure Mail delegation is enabled under Gmail settings.

In the shared mailbox, open Gmail settings > Accounts and Import > Grant access to your account, add the delegate's address, and send the invitation. The delegate accepts from their inbox; access may take up to 24 hours. When Gmail prompts for preferences, select Mark conversation as read when opened by others and Show this address and the person who sent it ("sent by…") so multiple agents see a consistent thread and sender attribution.

O365

You must be an Exchange administrator or Global administrator in Microsoft 365 to forward emails.

1. In the admin center, go to Users > Active users.

2. Select the user whose email you want to forward, then open the Properties page.

3. On the Mail tab, select Manage email forwarding. On the email forwarding page, select Forward all emails sent to this mailbox, enter the forwarding address v___________@hooks.devrev.ai, and choose whether to keep a copy of forwarded emails. If you do not see this option, ensure a license is assigned to the user account. Click Save changes.

Once saved, Microsoft sends an invitation to the hooks address. The invitation appears as a conversation in your DevRev inbox. The conversation comment may not render correctly as HTML, so the invite button may be inaccessible directly.

To accept the invitation:

1. Open the conversation in your DevRev inbox and locate the email.eml attachment on the message.

2. Download the .eml file and open it in your preferred mail client (such as Outlook or Apple Mail).

3. In the rendered email, click Accept invite to confirm the forwarding relationship.

SMTP relay and upstream relays

Some organizations route inbound mail through an SMTP relay or a third-party security gateway (for example, Mimecast or Proofpoint) before it reaches the mailbox. In these setups, the relay delivers to the DevRev hooks address, and the sending domain must still pass authentication after the relay rewrites the envelope.

O365 and Exchange with a connector and relay

1. In the Exchange admin center, create or identify the connector that routes outbound mail to the DevRev hooks address.

2. On the mailbox or transport rule that handles support mail, forward to v___________@hooks.devrev.ai through the connector rather than as a direct mailbox forward.

3. Accept the forwarding invitation as described in the O365 steps above.

Upstream relays and security gateways

When mail passes through an upstream relay that rewrites the envelope sender, receiving checks are applied to the rewritten domain. Ensure the domain that presents the message to DevRev publishes SPF and DMARC records that pass, and that the relay is authorized to send on behalf of that domain.

4. Set primary email address

In the email snap-in configuration modal, complete the following steps to start using email in DevRev.

Add a primary email address

Use the format Name <email@domain.com> — this is what appears in the customer's inbox. For example: Maple Support <support@maplesoftware.net>.

This email address becomes the primary channel for incoming support mail.

Alias email addresses

If you route mail through alias addresses (for example, billing@maplesoftware.net or help@maplesoftware.net in addition to the primary support@maplesoftware.net), each alias must be explicitly listed in the snap-in configuration. Aliases that are not listed default to the primary use case defined for the snap-in and do not create separate conversation types. This is a common source of confusion when different teams share a single snap-in but expect alias-specific routing behavior.

Define the primary use case

Choose how DevRev interprets emails sent to the primary address:

• Ticket: Each incoming email creates a new ticket.

• Conversation: Each incoming email creates a new conversation in your inbox.

Toggle on Set email as the default channel for tickets to ensure that customer replies are sent via email in addition to the original channel source. When this toggle is off, replies are sent only through the channel where the conversation originated (for example, Plug chat), and email is not used as a fallback. For tickets created from the portal or Plug, the behavior also depends on whether a notification sender email is configured in the snap-in: if a notification sender email is set, outbound replies use that address regardless of this toggle; if none is configured and the toggle is off, email replies are not sent for portal- or Plug-sourced tickets.

Prevent email loops and excessive automated emails

Automated mail (auto-replies, reminders, and out-of-office messages) can create tickets or trigger reply cycles that generate a large volume of email. DevRev checks the Auto-Submitted header to suppress recognized automated messages, and the following controls limit the remaining cases.

• Create accounts for new domains: When disabled, DevRev does not create accounts and contacts for senders on unrecognized domains, which prevents automated senders from generating new records for each message.

• Allow automations to send emails: Controls whether workflows send outbound email. Disable it to stop workflow-driven replies while investigating a loop, and re-enable it once the cause is resolved.

• Auto-reply recipient restriction: Restrict which recipients receive automated replies so that machine addresses (for example, no-reply@ or notification senders) do not receive replies that could bounce back and re-enter the queue.

• Rate-limit tagging: Apply tagging to high-volume or automated senders so their mail is throttled or held rather than creating a ticket for every message. Apply the power-user tag to legitimate high-volume senders to keep them from being flagged.

5. Verify

To verify the configuration:

1. Send an email to the configured support email address.

2. Confirm that a ticket or conversation is created in the DevRev app.

3. Add a comment to the ticket or conversation and verify that the reply is received at the email address that sent the original message.

4. Open the Events Panel from the top-right corner of the Email Integration snap-in screen to review delivery status and any errors. For a detailed explanation of Events Panel fields and event types, refer to Email integration overview.

While DevRev ensures that emails are sent, deliverability to end customers depends on the email client and the SPF and DMARC policies configured for the sending domain.

To verify deliverability:

1. Send a test email to your configured address from a deliverability tool (such as dmarctester.com, Redsift Investigate, or MXToolbox) and confirm that a conversation or ticket is created.

2. Respond from the test conversation or ticket in DevRev to the address specified by the deliverability tool. To add the address as a contact, open the email composer, click Add contact, and enter the address provided by the tool.

3. Return to the chosen tool and check the status of the sent email.

If the DMARC compliance checks pass, DevRev email is deliverable.

Troubleshooting

• Issue: Email connection shows as invalid or disconnected after setup.

  Solution: Re-authenticate the connection in the email snap-in configuration. If you use OAuth (such as Google or Microsoft), ensure the token has not expired and that the connected account still has the required permissions. Check the Events Panel for specific error messages.

• Issue: An email connection has expired and needs to be reauthorized.

  Solution: Go to Settings > Snap-ins > Connections > Other connections, locate the affected connection, and select Reauthorize. After reauthorization, confirm that any workflows referencing this connection are still functioning correctly.

• Issue: Outgoing emails are not delivered to customers.

  Solution: Verify SPF and DMARC records for the sending domain using a deliverability tool. Confirm that Allow automations to send emails is enabled in the snap-in settings if workflows trigger the messages. Check that the connection referenced in your email workflows has not been deleted or modified without updating the workflow.

  📝 Note: If you update or delete a connection used in email workflows, update the connection reference in those workflows as well to avoid outgoing email failures.

• Issue: A legitimate user is flagged as a spammer and stops receiving replies.

  Solution: Navigate to the contact record in DevRev and remove the spammer or blocked tag. To prevent future false positives for high-volume senders, apply the power-user tag to their contact.

• Issue: Forwarded emails are auto-assigned to the forwarding agent instead of the original sender.

  Solution: Disable the Assign to first responder setting in the email snap-in configuration. Then create a workflow that assigns the ticket only when an agent comments on an unassigned ticket, which allows forwarded tickets to be routed based on the original sender or other ticket attributes rather than the forwarding agent.

• Issue: Events Panel shows delivery failures or bounce events.

  Solution: Open the Events Panel from the top right of the Email Integration page. Review the specific event details, including bounce codes and timestamps. Common causes include invalid recipient addresses, full mailboxes, or DNS misconfiguration. Resolve the underlying issue and resend the email.