Skip to main content
Each team in Serval can have its own email intake address (e.g., support@yourcompany.com). When someone sends an email to that address, Serval creates a ticket, threads replies into the right conversation, and can automatically respond — depending on your team’s settings and whether the sender is trusted. This guide covers how email intake works, when Serval responds, how to compose email replies, how subscribers and CC recipients are managed, and how external users are handled.

​
How email intake works

When someone sends an email to your team’s intake address, Serval processes it as follows:
  1. The email is received and scanned for viruses.
  2. Serval checks whether this is a new request or a reply to an existing ticket. It uses standard email threading headers (References, In-Reply-To) to match replies to the correct ticket.
  3. If it’s a new email, a ticket is created and the sender becomes the ticket requester.
  4. If it’s a reply, the message is added to the existing ticket conversation.
  5. An auto-response is sent to the sender confirming the ticket was created (if enabled).
Serval intelligently threads email replies — including replies from CC’d users — back to the correct ticket. No duplicate tickets are created from replies. On messages linked to email (inbound or outbound), Serval shows inline From, To, and Cc routing in the thread. Matched org users and your intake address are labeled; other addresses show as email. Long lists can expand and collapse.

​
When Serval responds

How Serval responds to an inbound email depends on two things: whether the sender is trusted and whether the email is a new request or a reply to an existing ticket.

​
Sender trust

A sender is considered trusted when both of these are true:
  1. Their email domain is in your team’s domain allowlist.
  2. The email passes DKIM verification (proving it actually came from that domain).
If either condition fails — or if the sender’s domain is not allowlisted but your team has Allow all domains enabled — the sender is treated as untrusted. Optionally, a team can also trust organization members from any domain. When that setting is on, an email from the address of an active member or admin of your organization counts as trusted even if the domain isn’t allowlisted. The message must still pass DKIM or DMARC verification. Guests never qualify, and the sending address must match the member’s Serval email exactly.

​
Response behavior by scenario

​
What “AI active” means

Each ticket has an AI active flag that controls whether Serval’s AI agent processes new messages and generates responses.
  • Trusted sender tickets start with AI active.
  • Untrusted sender tickets start with AI inactive and escalated to a human.
  • When a team member escalates a ticket, AI is deactivated.
  • A team member can re-enable AI on any escalated ticket by mentioning @Serval in the conversation, or by manually toggling it.
When AI is inactive, Serval still delivers messages to connected channels and notifies subscribers — it just does not generate an AI response.

​
Email settings

Each team’s email channel has its own configuration. Navigate to Team Settings > Channels > Email to manage these settings.

​
Trust and domain settings

These settings control who can send emails to your team and how Serval treats those senders.
If you enable “Allow all domains”, senders from non-allowlisted domains will not get AI responses. Their tickets go straight to your team’s queue for a human to handle. Only senders from allowlisted domains with valid DKIM get AI responses. If your team relies on Serval to respond to email requests, make sure the sender’s domain is on your allowlist.

​
Reply and auto-response settings

These settings control how Serval sends emails back to requesters. For the custom auto-response and the email footer, switch between Rich text and HTML authoring per channel. Rich text is a simple formatted editor. HTML mode keeps tables, inline styles, images, and links, so you can reproduce a formatted signature block. The footer isn’t added to campaign or workflow emails, which compose their own body. In HTML mode, select Preview to check the rendered auto-response or footer. The preview displays the HTML after Serval processes it for email. Links and forms are inactive in the preview; check their destinations in a test email. The custom auto-response can include variables that Serval fills in per ticket. Insert them from the variable menu in the editor rather than typing them. Serval rejects a save that contains any other {{...}} token, so a mistyped variable is caught before it reaches a requester. From the email footer settings, add a logo image to appear in the footer of the emails Serval sends on this channel. Your team has one logo, shared across all its email addresses. Each address sets its own layout, width, and alt text, and can show or hide it. A preview shows how the footer will send.
If your footer text already embeds an image, remove it there so recipients don’t see two logos.

​
Subscriber settings

These settings control how subscribers are managed based on email CC headers.

​
Subscribers

A subscriber is anyone who receives notifications about activity on a ticket. There are several ways someone becomes a subscriber:
  • Requester: The person who created the ticket via email is automatically subscribed.
  • Assignee: The team member assigned to the ticket is automatically subscribed. Assignees cannot unsubscribe.
  • Email To/Cc: When Auto-subscribe email recipients is enabled, anyone in the To or Cc headers of an inbound email is automatically subscribed.
  • Reply Cc: When an agent sends a public reply on an email ticket, people added to the composer Cc line are subscribed and copied on the outbound reply; people removed from the prefilled Cc line are unsubscribed. Team agents and managers who can post a public reply can also copy someone outside your organization: type the address and select Add <email> as guest. Serval adds them as an organization guest and subscribes them, with no invitation email sent.
  • Manual: Use the ticket’s Change subscribers control to add existing org members, or type an external email to add them as a guest subscriber. Guests added this way are not sent an invitation email.

​
Subscriber notifications

Adding someone as a subscriber does not notify them or tag them. They are not alerted about being added, and they do not see past messages unless they open the ticket. They will only start receiving notifications on future activity on the ticket.

​
Removing subscribers

Any subscriber can be removed from a ticket, which stops all future notifications for that ticket. This removes all subscription reasons at once (requester, commenter, mentioned, etc.). The one exception: assignees cannot be unsubscribed. If someone is both the assignee and a subscriber for other reasons, removing them as a subscriber has no effect while they remain assigned. A removed subscriber can always be re-added later.

​
CC handling

​
Composing replies

On email tickets, public replies show To and Cc above the message body (hidden for internal notes). To is the ticket requester (or the last inbound sender if the requester has no email). Cc is prefilled from subscribers except the requester and you. Editing Cc adds or removes subscribers relative to that prefilled list when you send; editing To changes the requester. The composer also shows which inbox the reply is sent from: its label and address, with the reply-to address on hover. A ticket connected to more than one intake inbox lists each. Outbound email goes to To. With Auto-subscribe email recipients enabled, all other subscribers are CC’d (except you and the To recipient). The composer Cc field controls who is subscribed; it does not override which subscribers receive the email.

​
Auto-subscribe email recipients

This setting changes behavior in both directions: Outbound emails (Serval to external):
  • All ticket subscribers are CC’d, except the To recipient and the reply sender.
  • Deactivated users are excluded. Addresses that do not resolve to an org user are skipped.
Inbound emails (external to Serval):
  • Anyone in the To or Cc headers of an incoming email is automatically added as a subscriber.
  • Recipients from untrusted domains are provisioned as guests before subscribing (see External users and guests below).
When Auto-unsubscribe removed recipients is enabled, subscribers not in the latest inbound To or Cc are removed on reply.

​
Replies that leave off the requester

If an inbound email reply leaves the ticket requester off both To and Cc, Serval ingests it as an internal note instead of a public reply. Only team members can see it, it isn’t emailed to the requester, and their subscription stays unchanged. This keeps side conversations between agents off the requester-facing thread, much like private comments in tools such as Zendesk.

​
BCC handling

BCC recipients on inbound emails are not added as subscribers and are not visible to Serval. This is standard email behavior — BCC headers are stripped by the sending mail server before delivery.

​
External users and guests

When an email arrives from someone outside your organization, Serval handles them based on your domain allowlist:

​
Trusted domains (allowlisted)

If the sender’s domain is in your allowlist and passes DKIM verification, they are created as a regular organization member. They have the same access as any other user in your org.

​
Untrusted domains

If the sender’s domain is not allowlisted (and “Allow all domains” is on), they are created as an organization guest. Guests have limited access:
  • They can only see and interact with tickets they are associated with.
  • They cannot browse other tickets, teams, or internal data.
  • Their access is scoped to the specific conversations they are part of.
This also applies to Cc’d recipients. If Auto-subscribe email recipients is enabled and an inbound email Cc’s someone from an untrusted domain, that person is created as a guest and subscribed to the ticket.

​
Mailing lists and forwarded email

When emails arrive through mailing lists (e.g., Google Groups) that rewrite the From header, Serval looks for X-Original-From and X-Original-Sender headers to identify the actual sender. This ensures the ticket is attributed to the right person, not the mailing list address.

​
Custom From Address (White-Labeled Email)

By default, outbound emails from Serval show a sender address like your-team@intake.serval.com. You can configure Serval to send emails that appear to come from your own branded address — for example, it@yourcompany.com — so that end users see a familiar sender and your organization’s domain. Verify your domain at the organization level in Settings → Sender Domains, then choose a Custom From address in each team’s email channel settings. You need access to your domain’s DNS provider to complete verification.

​
Verify a sender domain

  1. As an organization admin, open Settings → Sender Domains.
  2. Enter the domain you want to send from, such as yourcompany.com, and select Add domain.
  3. Expand the domain to see its DNS records. Copy the displayed names and values into your DNS provider.
  4. Wait for the domain status to become Verified. Serval checks the records automatically; verification usually completes within an hour after you add them.
Sender domain verification applies to your organization. Once verified, the domain is available to teams when they configure an email channel’s From address. If you cannot access Sender Domains, ask your organization admin or Serval support for help.

​
How it works

Serval sends email through AWS SES. Every email has two “from” addresses:
  • The visible From — what your recipients see (e.g., it@yourcompany.com). This is what you’re customizing.
  • A hidden envelope sender — used by mail servers for SPF checks and bounce routing. Without custom DNS records, this defaults to an Amazon SES address, which means your mail authenticates against Amazon’s domain rather than yours. Under a strict DMARC policy, this can cause messages to be quarantined if a forwarder breaks the DKIM signature in transit.
The DNS records below enable DKIM signing for your domain and SPF authentication for the serval subdomain used as the envelope sender.

​
DNS records to add

Copy the exact record names and values shown in Sender Domains. Serval generates two sets of records:
Add the DKIM records to the domain you registered, not to its serval subdomain. For example, registering yourcompany.com requires records at <token>._domainkey.yourcompany.com, not <token>._domainkey.serval.yourcompany.com. Check how your DNS provider handles the domain suffix before saving.
The serval subdomain is used for the envelope sender and bounce routing. Recipients still see your chosen address, such as it@yourcompany.com, in the From field.

​
Inbound email forwarding

The DNS records above only affect outbound email. For inbound email — so that replies from end users reach Serval — you need to configure forwarding in your mail provider (e.g., Google Workspace):
  • Forward it@yourcompany.com → your team’s Serval intake address (e.g., your-team@intake.serval.com)
Your organization’s existing MX record (pointing to Google Workspace or Exchange) handles delivery of inbound mail to your domain. The Serval intake address receives it via the forwarding rule you configure there.

​
Enabling custom From in Serval

After the domain is Verified:
  1. Open the team’s Settings → Channels and select its Email channel.
  2. Edit Custom From address and enter an address on a verified domain, such as it@yourcompany.com.
  3. Save the address and test an outbound email and an inbound reply.
You need permission to manage the team’s channels. If no verified domains are available, ask an organization admin to complete verification in Sender Domains. If the address is marked Managed by Serval, contact Serval support to change it. If your organization does not have the custom From controls, contact Serval support for setup help. We recommend testing in a sandbox team before enabling on your production team.

​
Notification sender address

Automated notification emails, such as approval requests and access confirmations, come from Serval’s default notification address. Your help desk’s custom From doesn’t change that. To send a team’s notifications from your own address instead, turn on Use custom notification sender address in Team Settings → Notifications → Email, enter the address, and click Save. Each team has its own setting, so teams in one organization can use different addresses on the same domain, such as hr-noreply@ and it-noreply@. It’s off until you set it, and a team doesn’t need an email intake address to use it. The setting appears once Serval has enabled sender domains for your organization; contact Serval to set this up. Use a no-reply address on one of your organization’s verified sender domains. The Sender name still sets the display name.
  • It only affects the team’s automated notifications. Help desk replies and campaigns keep their own From and Reply-To.
  • Adding, removing or changing the team’s email intake addresses doesn’t change it.
  • Replies to notifications still go to Serval’s default notification address, so they don’t open tickets.
  • If one of these notifications is forwarded back into a help desk, it doesn’t open a ticket. Other email sent from the address is handled as usual.
  • Turn off Use custom notification sender address and click Save to go back to Serval’s default address. Cancel discards unsaved changes.
  • If your domain stops verifying, notifications come from Serval’s default address instead, so they still arrive.
  • A sender domain can’t be removed while a notification sender address uses it.

​
Best practices

With Auto-subscribe email recipients off, outbound replies go only to the To address. Enable it only when your workflow needs other subscribers CC’d automatically. You can still adjust the audience per reply with the composer Cc line.
Rather than allowing all domains, maintain an explicit allowlist of trusted domains. This prevents spam and ensures only legitimate senders can create tickets. Add partner or vendor domains as needed.
Before replying with sensitive information, check the composer Cc line and the subscriber list. With Auto-subscribe email recipients enabled, every subscriber is CC’d on the email—not only the addresses shown in Cc. Remove anyone who should not receive it before sending.
External users from untrusted domains become guests with limited access. However, they can still see messages on tickets they are subscribed to. If a ticket contains internal-only information, remove external guests from the subscriber list before discussing it, or use internal notes instead of email replies.
Configure Serval to send from your organization’s email address (e.g., it@yourcompany.com) so recipients see a familiar sender. See Custom From Address above for the setup steps.