Overview
To send and receive emails through Pilot's Inbox, your lab needs to connect a custom email domain. This involves registering your domain with Pilot's email infrastructure (powered by Mailgun), verifying DNS records so your emails are trusted by recipients' email providers, and setting up email forwarding so that incoming customer emails are routed into Pilot.
Without a custom domain, Pilot sends emails from a shared platform address - [email protected]. With a custom domain, your emails come from your own address (e.g., [email protected]), which looks more professional, builds trust with your customers, and improves deliverability.
How Email Works in Pilot
Pilot's email system has two sides:
Outbound (sending) — when a lab user replies to a conversation or starts a new email conversation, Pilot sends the email through Mailgun using your custom domain. The "From" address is your configured email address, and the sender name is the lab user's name. This means customers see emails from "Jane Smith <[email protected]>" rather than a generic platform address.
Inbound (receiving) — when a customer sends an email to your lab, it needs to reach Pilot. This is accomplished by setting up automatic email forwarding in your existing email provider (Google Workspace, Outlook/Exchange, etc.) to forward a copy of incoming emails to a Pilot-managed address. Pilot processes the email, identifies the sender, threads it into the right conversation (or creates a new one), and it appears in your Inbox.
Setting Up a Custom Domain
Setting up a custom domain involves three steps: registering the domain in Pilot, adding DNS records at your domain provider, and verifying the records.
Step 1: Register Your Domain by Adding an Email
In Pilot's settings, navigate to the Domains and Emails configuration section and add your domain email
When you register the domain, Pilot creates it in Mailgun and returns a set of DNS records that need to be added to your domain's DNS configuration.
Step 2: Add DNS Records
You'll need to add several DNS records at your domain registrar or DNS provider (GoDaddy, Cloudflare, Namecheap, Route 53, etc.). These records serve different purposes:
Sending records authenticate your domain so email providers trust that Pilot is allowed to send email on your behalf:
SPF record (TXT) — tells receiving email servers that Mailgun is authorized to send email for your domain. Without this, your emails may be marked as spam or rejected.
DKIM records (TXT or CNAME) — adds a cryptographic signature to every email Pilot sends, proving the email hasn't been tampered with and genuinely came from your domain. DKIM is critical for deliverability.
Receiving records route incoming email to Pilot:
MX records — tell the internet where to deliver email sent to your domain. These point to Mailgun's servers so that email sent to your Pilot-managed subdomain is received by Mailgun and forwarded to Pilot via webhook.
The exact records and values are provided by Pilot when you register your domain. Copy them exactly as shown.
Step 3: Verify the Domain
After adding the DNS records, return to Pilot and click Verify. Pilot checks with Mailgun to confirm that all DNS records are correctly configured. DNS changes can take anywhere from a few minutes to 48 hours to propagate, so if verification fails immediately, wait and try again.
Once verified, the domain status changes to "Authenticated" and Pilot will use it for sending outbound emails.
Setting Up Email Addresses
After your domain is verified, you configure one or more email addresses under that domain. An email address represents a specific mailbox identity your lab uses to communicate with customers.
For example, you might set up [email protected] as your primary outbound address. When a lab user replies to a conversation, the email is sent from this address.
You can mark one email address as the default. The default address is used whenever Pilot sends an email on behalf of your organization — conversation replies, notifications, and any other outbound communication.
An email address must have outbound enabled and be on an authenticated domain to be used for sending.
Setting Up Inbound Email Forwarding
For Pilot to receive customer emails, you need to configure forwarding in your existing email provider. The exact steps depend on which provider you use.
Google Workspace
In Google Workspace Admin, set up auto-forwarding to forward incoming emails to your Pilot workspace address. This can be configured at the user level or as an organization-wide routing rule.
When a customer emails your main address (e.g., [email protected]), Google Workspace delivers it to your Gmail inbox forwards it to Pilot. Pilot processes the email, extracts the original sender's information, and creates or updates a conversation in your Inbox.
Microsoft Outlook / Exchange
In Exchange Admin or Outlook, set up a mail flow rule or inbox rule to forward incoming emails to your Pilot inbound address. Exchange supports two types of forwarding:
Redirect — preserves the original email headers, including the Message-ID. This is the preferred method as it maintains perfect email threading.
Forward — creates a new message with a new Message-ID. Pilot handles this correctly by extracting the original sender and Message-ID from the forwarded email's headers, but redirect is cleaner when available.
Note that some Exchange/Office 365 environments have policies that block external forwarding. Your IT administrator may need to allow forwarding to the Pilot inbound address.
Other Providers
For any email provider that supports auto-forwarding or mail rules, the setup is the same: configure a rule to forward incoming emails to your Pilot inbound address. Pilot extracts the original sender from the forwarded email body and headers regardless of which provider performed the forwarding.
How Inbound Routing Works
When Pilot receives an inbound email, it goes through several steps:
Sender identification — Pilot parses the email headers and body to determine who the original sender is, even when the email was forwarded by Google or Exchange. It looks at the forwarded message headers (From, Reply-To, X-Forwarded-From) and the forwarded message body to extract the real sender's name and email address.
Customer resolution — Pilot matches the sender's email address against your customer records. If a match is found, the conversation is automatically linked to that customer and their billing account. If no match is found, the conversation is created without a customer link and can be manually assigned later.
Thread matching — Pilot determines whether this email is a reply to an existing conversation or a new conversation. It checks the In-Reply-To and References headers against Message-IDs stored on existing conversation messages. If no header match is found, it falls back to matching by email subject against open conversations. If no match is found at all, a new conversation is created.
Content extraction — Pilot strips the forwarding metadata, quoted reply content, and signatures from the email body, storing only the new message content. This keeps conversations clean — you see the customer's actual message, not the entire forwarded email chain.
How Outbound Sending Works
When a lab user sends a reply from the Inbox, Pilot:
Resolves the "From" address by checking for a default outbound email address on an authenticated domain for your organization. If none is configured, it falls back to the platform default.
Sets the sender display name to the lab user's first and last name, so the customer sees a personal reply rather than a generic address.
Includes email threading headers (In-Reply-To and References) pointing to previous messages in the conversation, so the reply threads correctly in the customer's email client.
Sends the email through Mailgun using your authenticated domain, which ensures the SPF and DKIM records validate and the email lands in the customer's inbox rather than their spam folder.
Fallback Behavior
If your organization hasn't set up a custom domain, or if your domain's authentication lapses, Pilot falls back to sending from the platform's shared domain and default email address. Emails will still be delivered, but they won't come from your lab's address, which may look less professional to customers and could have lower deliverability.