Approved Senders

By default, when a user connects Gmail or Microsoft 365, any agent authorized to use that connection can send email from it. For most personal deployments that's fine — the user decides what their agents can do.

For organizational deployments, the Approved Senders allowlist adds a stricter gate: emails sent by agents must originate from an explicitly approved from address. Any agent attempt to send from an unlisted address is rejected before the SMTP call.

When to use this

• Compliance-heavy environments — prevent agents from spoofing executives or other users.
• Shared service accounts — you want ops-bot@example.com to send, not an employee's personal Gmail.
• Phishing prevention — even if an agent is compromised, it can't impersonate arbitrary addresses.
• Brand consistency — all outbound automation from Sophon uses a curated set of addresses.

Scope

Approved Senders applies to:

• Gmail — sends through the email.send tool against connected Gmail accounts
• Microsoft 365 — microsoft.send_mail via Graph API
• SMTP connections — direct SMTP sends
• Workflow "Send email" nodes — all of the above

It does not apply to:

• Outbound channel messages (Telegram, Slack, WhatsApp) — those are governed by channel adapter config
• Webhook outbound — governed by the webhook's target URL
• Responses on channels that Sophon received email on — replies go back to the sender automatically

Configuration

Admin → Settings → Approved Senders.

Add entries as either:

• Exact address — ops-bot@example.com
• Domain wildcard — *@example.com (any address at this domain)
• Per-user restriction — jane@example.com can only send as jane@example.com

Save. Changes take effect immediately; in-flight email sends that don't match the updated list fail the next time they're invoked.

Example configuration:

ops-bot@example.com                     [domain-wide]
support@example.com                     [domain-wide]
*@acme-internal.example.com             [wildcard]
jane@example.com                        [user: jane@example.com only]
noreply@marketing.example.com           [domain-wide]

Enforcement

When an agent tries to send:

1. Tool executor collects the from address from:
   • Explicit from parameter (if specified)
   • Default from address of the connection
   • User's email identity as a last resort
2. Checks against the allowlist.
3. If no match → reject with "Sender not in approved list" and log the attempt to audit.
4. If match → send proceeds; audit logs both the approved match and the sent message.

The check happens pre-send, so no email goes out on failure. The agent sees the error and can either ask the user for a different address or abort the flow.

Bypass — by approval

If an agent needs to send from a not-yet-approved address (one-off circumstance), it can request approval:

"I'd like to send from jane-personal@gmail.com. This is not in the approved sender list. Do you want to approve this one-time send?"

The approval card shows the draft email body, the requested from-address, and the approval rationale. The approver can:

• Approve once — allow this single send
• Approve and add — allow this send and add the address to the allowlist
• Reject — deny

Audit

Every send attempt is logged:

• Action: email.send.approved / email.send.denied
• Details: from, to (hashed for PII), subject (if not redacted), reason

Filter in Admin → Audit with category email.

Interaction with RBAC

ManageApprovedSenders is the permission required to edit the list. Typically granted to:

• Admin — all of it
• Operator — list read, one-off approvals
• Custom compliance role — list management, audit review

Regular users don't see or edit the list.

Domain verification

For domain-wildcard entries (*@example.com), Sophon optionally verifies you own the domain:

• SPF check — verify the SPF record authorizes Sophon's sending infrastructure (if using SMTP relay)
• DKIM check — verify DKIM signing is configured
• DMARC alignment — at least p=none to avoid bounces

These checks are informational; they don't block the allowlist entry but surface warnings.

Configuration via API

GET  /api/admin/approved-senders
POST /api/admin/approved-senders
  { "entry": "ops-bot@example.com", "scope": "global" }
DELETE /api/admin/approved-senders/{id}

Limits

• Maximum entries: 500 per tenant (tune with ApprovedSenders.MaxEntries).
• Wildcard entries count as one. Don't nest (*@*.example.com isn't supported — use one wildcard per entry).
• Per-user restrictions require that the user's identity is resolvable; if the agent is running without a user context (e.g., some cron jobs), per-user entries are ignored and only global entries apply.

Where to go next

• RBAC — who can manage the list
• Audit Logging — reviewing send history
• Approval Gates — one-off approval flow