Falaah Falaah AI

Custom email ingestion domain

Use a branded forwarding address like documents@your-org.com for inbound mail. Available on Scale and Enterprise; provisioned by Muin within two business days.

Every Muin tenant gets a working forwarding address out of the box — something like your-tenant-slug@inbound.falaah.ai. Scale and Enterprise customers can swap that for a branded address on their own domain, e.g. documents@your-org.com, that lands in the same Muin inbox.

This is an admin-managed feature. You request it from inside Muin; our ops team provisions the email infrastructure and emails you the DNS records to add. End-to-end takes about two business days.

What it is

Default (every tier) Custom (Scale + Enterprise)
your-tenant-slug@inbound.falaah.ai documents.your-org.com (or any subdomain you choose)
Shared SES MX, Muin manages reputation Dedicated SES domain identity for your domain
Zero setup DNS records you add at your domain provider
Identical inbox experience Identical inbox experience

Both addresses live side-by-side. If you set up a custom domain you keep the default address too — anything sent to either lands in the same unified inbox.

How to request

  1. In Muin, go to Settings → Email Forwarding.
  2. Click Request custom forwarding domain →. (Lower tiers see this button disabled, with a link to talk to us about upgrading.)
  3. Fill in:
    • Your domain (e.g. your-org.com).
    • A subdomain preference (e.g. documents).
    • A short reason — what kind of mail will route here.
    • A confirmation that you (or your IT team) have admin access to the domain’s DNS records.
  4. Submit. The form opens a categorized support ticket; our ops team typically responds within one business day.

What happens behind the scenes

You submit form              ──▶ Muin creates a categorized support ticket
   │                                       │
   │                                       ▼
   │                          Muin admin verifies your tier (Scale/Enterprise)
   │                                       │
   │                                       ▼
   │                          Muin provisions an AWS SES domain identity for
   │                          documents.your-org.com (us-east-1)
   │                                       │
   │                                       ▼
You receive DNS records  ◀──    Muin emails you the TXT + MX records to add
   │                                       │
   ▼                                       │
You add records at your DNS                │
   │                                       │
   ▼                                       ▼
You reply done           ──▶  Muin runs the verification script


                              Verified → confirmation email → live

The full Phase 3 admin workflow is documented in our internal runbook (muin.server/docs/runbooks/email-ingestion-custom-domain-request.md).

Privacy + security

  • Same encryption + retention as the default ingestion address.
  • The custom domain identity is not shared with other tenants — your inbound stream is isolated to your tenant.
  • We never ask for or store your DNS provider credentials. Records are added by you at your provider.
  • On a tier downgrade or account closure, your custom domain is automatically deprovisioned — the SES identity is deleted, our receipt rule is updated, and you can remove the DNS records at your end. The default inbound.falaah.ai address stays.

Pricing

Plan Custom forwarding domain
Free / Starter
Growth
Scale ✓ Included
Enterprise ✓ Included

There is no setup fee and no per-message premium. The custom domain is a plan feature, not an add-on.

Why a request flow rather than self-serve?

Two reasons:

  1. DNS verification is high-touch — we send you records, you add them, we verify. A self-serve wizard for this would mostly be waiting; a 2-business-day promise from a real human gives you a timeline you can plan around.
  2. Quality bar on inbound infrastructure — admin-managed provisioning lets us catch domain conflicts, suspect requests, and abuse patterns before they hit production receipt rules.

Troubleshooting

If your DNS records are correct but verification stalls past 30 minutes, reply on the support ticket and we will escalate. The most common cause is DNS propagation latency at your provider.

Next steps