What Incoming Emails Does
Incoming Emails is a knowledge capture path, not a mailbox for auto replies and not an auto train pipeline. Your team sends or forwards mail to a unique FAQ Ally address. FAQ Ally checks who sent it and whether email authentication passed, then holds accepted messages in an inventory for human review.
From Knowledge → Emails, reviewers can Include, Exclude, or Merge each part of a message (body segments and eligible attachments). Include creates a draft File or Snippet in the normal Knowledge workflow. Agents only use that content after it is marked Training Ready and included in a training run.
Prerequisites
- A FAQ Ally company on a plan that includes Integrations (Small, Medium, Large, or Enterprise).
- A FAQ Ally user with the admin role to configure the integration.
- At least one company email domain your employees send from (for example
company.com). Personal providers such as Gmail, Outlook.com, and Yahoo cannot be added as allowed sender domains. - Ability to send or forward mail from that company domain so SPF or DKIM can pass for your domain.
Step 1: Configure Allowed Sender Domains
1 Open Incoming Emails
In FAQ Ally, go to Integrations → Incoming Emails.
2 Add a sender domain
Enter a domain only (for example acme.com), not a full email address. Wildcards and IP addresses are not allowed. Click Add Domain & Generate Address the first time, or Add Domain for additional domains later.
3 Copy the incoming address and enable intake
FAQ Ally generates a unique address shaped like in-…@…. Copy it for your team. Turn intake on when you are ready to accept messages. While intake is off, deliveries are rejected and recorded as rejected attempts.
Treat the address as a secret. Anyone who knows it can attempt delivery. Acceptance still requires an allowlisted From domain plus aligned SPF or DKIM (see below). If the address is exposed, regenerate it from Integrations → Incoming Emails (confirmation required). The previous address stops working.
Step 2: Send or Forward Mail
From an email account on an allowed sender domain, send or forward useful content to your Incoming Emails address. Common sources: invoices, receipts, policy clarifications, support resolutions, and internal how-tos.
Who authorizes the message: FAQ Ally evaluates the outer submitter (the mailbox that delivered the message to FAQ Ally), not a nested "original author" inside a forward alone. If Alice at acme.com forwards Bob's mail from a vendor, Alice's domain must be allowlisted and Alice's delivery must satisfy SPF or DKIM. Bob's domain does not authorize the intake by itself.
Authentication Requirements (SPF or DKIM)
After the webhook signature is verified, FAQ Ally authorizes the submitter against your allowlist and email authentication results. A message is accepted only when all of the following hold:
- The submitter’s domain (from the From header, or envelope if From is missing) is on your Allowed Sender Domains list and that entry is enabled.
- SPF is not a hard
fail, and DMARC is not a hardfail. - At least one aligned pass is present:
- SPF pass where the envelope domain matches the allowlisted submitter domain (or, if envelope is missing, the From domain matches), or
- DKIM pass where the DKIM signing domain matches the allowlisted submitter domain.
Softfail, none, or neutral results alone are not enough. FAQ Ally requires a positive, domain-aligned SPF pass or DKIM pass for the allowlisted submitter domain.
What this means in practice
Send from your company’s normal mail system so SPF and/or DKIM are published and pass for your domain. Spoofed From headers that lack an aligned SPF or DKIM pass are rejected, even if someone knows your inbound address.
Message never appears in Knowledge → Emails
Check Integrations → Incoming Emails for rejected attempts and activity. Common causes: intake disabled, sender domain not allowlisted, SPF or DMARC hard fail, or no aligned SPF/DKIM pass.
Step 3: Review Inventory
1 Open Knowledge → Emails
Accepted mail appears in the email inventory with subject, submitter, and review status. Admins and managers can review. Only admins configure the integration.
2 Open a message and inspect components
Each message is split into reviewable components (for example forwarding notes, original body text, quoted replies, and attachments). Preview uses sanitized HTML for display only. Plain text is the authoritative content for training decisions.
3 Include, Exclude, or Merge
Include creates a draft Snippet for text components, or a draft File for eligible attachments, linked back to the email component. Exclude marks a component as not for training. Merge links content into an existing knowledge artifact when that fits your workflow.
Attachment safety: FAQ Ally applies type and size policy before a component can be previewed for training or Included. Executables, macro-enabled Office files, and unsupported types are quarantined and cannot be Included. Quarantined items remain visible for audit, not for training.
Step 4: Train as Usual
Included drafts appear under Knowledge → Files or Knowledge → Snippets. Edit if needed, mark them Training Ready, assign document tags that match your agents, and run training. Incoming Emails does not train agents by itself.
Authorization Model
Security Controls
Unique inbound address
Each company receives a randomly generated local part. Lookup uses a digest of that token, not a guessable company id in the address.
Provider webhook verification
Deliveries are accepted only after the email provider’s webhook signature checks pass, with freshness and replay protection.
Allowlist plus aligned SPF or DKIM
Both the allowlisted sender domain and at least one aligned SPF or DKIM pass are required. Hard SPF or DMARC failures are rejected.
Human review before training
Accepted mail stays in inventory until a reviewer Includes it. There is no automatic promotion into agent training.
Managing the Integration
Pause intake
Disable Incoming Emails from the integration page. The address remains, but new messages are rejected until you enable again.
Regenerate the address
Use regenerate (with confirmation) if the address may have leaked. The old address stops accepting mail. Share the new address with your team.
Activity and rejections
The integration page shows recent activity and rejected attempts so you can diagnose allowlist or authentication failures without opening each message.
Troubleshooting
Sender domain not approved
Add the exact domain employees send from (for example acme.com). Subdomains are not implied. If people send from mail.acme.com as the From domain, that domain must be allowlisted separately unless your From domain is already acme.com with aligned authentication.
Authentication failed
Confirm SPF and DKIM are correctly published for your sending system. Softfail or missing auth is not enough. You need an SPF pass aligned to the allowlisted domain, or a DKIM pass whose signing domain matches that domain.
Cannot add Gmail or similar
Public consumer mail domains are blocked as allowed sender domains by design. Use your company domain.
Attachment cannot be Included
The component may be quarantined (blocked type, macros, or size). Use a supported knowledge file type, or Include the text body as a Snippet instead.
Plan upgrade message
Incoming Emails is part of Integrations. If your company is on a plan without Integrations, upgrade to Small or higher.
Best Practices
- Allowlist only domains you control. Prefer your primary corporate domain and verified sending domains.
- Forward from company accounts. That keeps the outer submitter on your allowlist with aligned SPF or DKIM.
- Review before Include. Strip noise, keep policies and answers that should train agents.
- Tag Included drafts. Match document tags to the agents that should learn from that content.
- Regenerate if shared broadly. Distribution lists and public docs are a common way addresses leak.
Learn More
For draft Snippet workflow after Include, see Knowledge Snippets. For widget DNS Domain Verification (a different feature), see Domain Verification. For training after content is Training Ready, see AI Agent Training.