Turn a customer-owned support domain into an AI-triaged ticket queue with managed email receiving.
Overview
answerLoops accepts inbound support email through a customer-owned domain configured for managed email receiving, not inbox polling. Every message that arrives is triaged, embedded against your knowledge base, and answered by the AI pipeline, then threaded back to the sender with proper RFC 5322 headers (Message-ID / In-Reply-To / References) so a customer's next reply lands in the same ticket instead of opening a new one.
Two things are independent and configured separately:
- Inbound mail — verify a domain you own in answerLoops and add the displayed DNS records. The managed email service sends a signed received-mail event to answerLoops, which retrieves and ingests the message for the matching organization. See Setup below.
- Outbound sending (the
From:address) — either the platform default, a domain you verify, or your own connected Gmail/Outlook mailbox. See Custom domain and Connect a mailbox below.
All email tickets appear in the unified ticket list with an Email source badge.
Automatic Deflections is off by default for every newly connected platform, email included. While it's off, even a high-confidence answer is held as a draft on the dashboard awaiting Approve/Edit/Dismiss — the customer gets a brief acknowledgment reply instead of the real answer. Turn it on in Integrations → Email → Edit sender filters & deflections once you've reviewed enough approved drafts to trust the AI's answers going out unsupervised.
Setup
1. Prerequisites
The platform email credentials and webhook signing secret must be set on the app service. They are used for sending, domain verification, retrieving received messages, and verifying signed events.
2. Configure in answerLoops
Go to Integrations → Email and fill in:
| Setting | Field | What it does |
|---|---|---|
| Allowed senders | allowedSenders | Comma-separated list of email addresses and/or domains (e.g. example.com, [email protected]). Only mail from a matching sender is accepted; everything else is silently filtered before it reaches the AI pipeline. Leave blank to accept all inbound mail. |
| Escalation email | escalationEmail | Referenced in the reply body when AI confidence comes back below your threshold or a ticket needs human review — email has no @mention concept, so this is surfaced as plain text ("This question has been flagged for human review. [email protected] will follow up."). |
| Confidence threshold | confidenceThreshold | 0–1, default 0.8. Answers scoring below this are routed to a human instead of posting automatically. |
| Automatic Deflections | autoDeflectEnabled | See the callout above. Off by default. |
Choose Use your own domain, enter the domain or support subdomain that should receive tickets, and submit it. answerLoops registers the domain for both sending and receiving and displays the DKIM, return-path/SPF, and inbound MX records required by the managed email service.
3. Add DNS records and verify
Add every record shown in the setup panel at the domain's DNS host. Keep any existing records that your company already uses; if the root domain's MX records belong to Google Workspace or Microsoft 365, use a support subdomain instead so customer mail is not redirected away from the company's mailbox.
Click Check verification status after DNS propagation. Once the domain is verified, customers can email:
The managed email service delivers signed received-mail events to POST https://yourapp.com/api/email/ingest. answerLoops verifies the event, resolves the organization from the recipient domain, retrieves the full message, and sends it through the normal ticket pipeline.
Full self-hosting details, including a deeper reliability writeup (loop detection, idempotency, spam handling) live on the Email Channel Setup page.
Custom domain (verified sending)
The professional option for outbound sending — replies go out with your own domain in the From: address instead of the platform default, and unlike connecting a personal mailbox, verification doesn't depend on any login staying active.
Without domain verification, a raw From: override is spoofing from the receiving mail server's perspective — Gmail/Outlook will flag or reject mail claiming a domain the sending infrastructure was never authorized (via SPF/DKIM) to send as. Verification proves ownership before answerLoops will send as that domain.
- Go to Integrations → Email and find Use your own domain.
- Enter the domain you want replies to come from (e.g.
yourcompany.com) and click Use your own domain. - answerLoops registers the domain with the managed email service and shows the required DKIM, return-path/SPF, and inbound MX records — add them at your domain's DNS host.
- Click Check verification status once the records have propagated (this can take a few minutes to a few hours depending on your DNS host).
- Once verified, customers can send to
support@<your-domain>and replies automatically send fromnoreply@<your-domain>— no separate toggle or mailbox login is needed.
Removing a verified domain reverts sending to the platform default (RESEND_FROM).
Connect a mailbox (Gmail or Outlook, send-only OAuth)
The quick option for outbound sending — connect your own Gmail or Outlook mailbox so replies go out through it directly and inherit its sender reputation, no DNS work required. Unlike the custom-domain path, this depends on the connection staying valid (a password change or long inactivity can revoke it). Only one mailbox connection can exist per org at a time — connecting Outlook while Gmail is connected (or vice versa) replaces the existing connection.
answerLoops only ever requests permission to send mail as you — it never reads your inbox.
- Go to Integrations → Email and find Connect a mailbox.
- Click Connect Gmail or Connect Outlook and approve answerLoops on the provider's consent screen.
- Once approved, replies automatically send from your connected mailbox — no separate toggle needed.
If the consent screen completes but the settings page does not show the mailbox as connected, make sure the OAuth callback URL and the deployment's app URL are configured for the same deployment. Hosted deployments that use a separate app subdomain must also share the authentication cookie across the apex domain so the callback can complete.
If the connection is ever revoked (password change, admin revocation, long inactivity), answerLoops detects it the next time it tries to send, emails your org's admins the same day with a reconnect link, and falls replies back to the platform default in the meantime — nothing is silently dropped. The Email card shows a distinct "connection lost — reconnect" state until you reconnect.
Removing the connection reverts sending to the platform default.
Outlook-sent replies thread slightly differently than platform- or Gmail-sent ones in the customer's own mail client — Microsoft Graph's sending API can't carry a References header the way the other paths can, so only partial thread context (In-Reply-To) comes through. answerLoops's own internal ticket-threading is unaffected either way.
Environment variables reference
| Variable | Required | Description |
|---|---|---|
RESEND_API_KEY | Yes | Required for every outbound reply |
RESEND_FROM | Yes | Default reply-from address (e.g. [email protected]); used when no custom domain or connected mailbox is set |
GMAIL_CLIENT_ID / GMAIL_CLIENT_SECRET | For Gmail connect | A Google Cloud OAuth client requesting only the gmail.send scope. Without these, the Connect Gmail button is unavailable but every other email path still works |
GMAIL_REDIRECT_URI | No | Overrides the derived callback URL (<app-url>/api/email/gmail/callback) if it differs from AUTH_URL/NEXTAUTH_URL |
OUTLOOK_CLIENT_ID / OUTLOOK_CLIENT_SECRET | For Outlook connect | A Microsoft Entra app registration requesting only the delegated Mail.Send scope. Without these, the Connect Outlook button is unavailable but every other email path still works |
OUTLOOK_REDIRECT_URI | No | Overrides the derived callback URL (<app-url>/api/email/outlook/callback) if it differs from AUTH_URL/NEXTAUTH_URL |
The webhook signing secret is used only by the platform endpoint. Customers do not need to know or configure it.